software engineering: are we agile enough? · agile non-agile dsdm dsdm philosophy scrum extreme...

AgileNon-Agile

Software Engineering:Are we Agile enough?

Michał Okulewicz

Wydział Matematyki i Nauk InformacyjnychPolitechnika Warszawska

Michał Okulewicz Software Engineering

AgileNon-Agile

DSDMDSDM philosophyScrumeXtreme ProgrammingBack to DSDM - verifying agility

DSDM / AgilePM

AgileNon-Agile

DSDM philosophy

Best business value emerges when projects are aligned to clear business goals, deliverfrequently and involve the collaboration of motivated and empowered people.

This is achieved when all stakeholders:

• Understand and buy into the business vision and objectives

• Are empowered to make decisions within their area of expertise

• Collaborate to deliver a fit for purpose business solution

• Collaborate to deliver to agreed timescales in accordance with business priorities

• Accept that change is inevitable as the understanding of the solution grows overtime

AgileNon-Agile

DSDM philosophy

AgileNon-Agile

DSDM philosophy

AgileNon-Agile

DSDM philosophy

AgileNon-Agile

DSDM philosophy

AgileNon-Agile

DSDM philosophy

AgileNon-Agile

DSDM principles

1 Focus on the business need

2 Deliver on time

3 Collaborate

4 Never compromise quality

5 Build incrementally from firm foundations

6 Develop iteratively

7 Communicate continuously and clearly

8 Demonstrate control (over the SCOPE of the project)

AgileNon-Agile

DSDM principles

2 Deliver on time

3 Collaborate

AgileNon-Agile

DSDM principles

2 Deliver on time

3 Collaborate

AgileNon-Agile

DSDM principles

2 Deliver on time

3 Collaborate

AgileNon-Agile

DSDM principles

2 Deliver on time

3 Collaborate

AgileNon-Agile

DSDM principles

2 Deliver on time

3 Collaborate

AgileNon-Agile

DSDM principles

2 Deliver on time

3 Collaborate

AgileNon-Agile

DSDM principles

2 Deliver on time

3 Collaborate

AgileNon-Agile

DSDM principles

2 Deliver on time

3 Collaborate

AgileNon-Agile

DSDM: Fixed constraints

AgileNon-Agile

DSDM: MoSCoW

AgileNon-Agile

DSDM: Team model

AgileNon-Agile

DSDM: Process

AgileNon-Agile

• Initial ideas by Hirotaka Takeuchi and Ikujiro Nonaka in The New ProductDevelopment Game. (1986)

• Cleaned up by Jeff Sutherland, John Scumniotales, and Jeff McKenna (1993)

• Presented on OOPSLA conference by Jeff Sutherland and Ken Schweber (1995)

• Described by Ken Schweber and Mike Beedle in Agile Software Development withScrum (2001)

Source:

https://www.techwell.com/techwell-insights/2012/10/brief-history-scrum

AgileNon-Agile

Scrum:It’s like playing chess: you learn the rules and

then you play.

AgileNon-Agile

Scrum roles

Product Owner - Defines client’s priorities, maintains medium-level productrequirements (i.e. Project Backlog), empowered to make decisions onbehalf of the client

Scrum Master - Expert on Scrum processes, helps to facilitate (not conduct!) DailyScrum Meetings

Team - Interdisciplinary (analysis, development, deployment, testing skills),self-organizing, motivated group consisting of 5-9 people, committed tothe project at least for a duration of a Sprint

AgileNon-Agile

Scrum processes

Sprint - a single 1-4 weeks long work period concentrated on delivering avaluable and working product

Daily stand-up - A short meeting for a whole Team for answering 3 questions:• What have I done yesterday?• What am I planning to do today?• Do I have any problems?

Stand-up meeting should provide sufficient background for furtherface-to-face interactions and overall knowledge of sprint progress.

Sprint kick-off meeting - a meeting for planning the next sprint, breaking-downproduct backlog items into smaller tasks for sprint backlog, and makingtime estimations of them

Sprint review and retrospective - a meeting(s) concluding the Sprint, and measuringTeam’s velocity

AgileNon-Agile

Scrum processes

Product Backlog - a set of mid-level prioritized tasks

Sprint Backlog - a set of low-level tasks, which the Team chose to complete duringparticular Sprint. Tasks are based on the Product Backlog

Burndown chart - a tool for measuring Team’s performance (aka velocity) during theSprint

AgileNon-Agile

Scrum rules

• Client should be constantly involved

• Team should partake in tasks estimation

• Team commits, as a whole, to delivering a new product within a single sprint

• Individuals are responsible for the quality of their work (code ownership)

AgileNon-Agile

Product backlog

Id Priority Description Est. Compl. Resp.

1 M Create database structure 6h 8h NS2 M Present the data 2h 1h IN5 M Fill in the database 4h 3h AB

3 S Analyze processes involving DB 5h - -

4 C Online data update mechanism 8h - CD

AgileNon-Agile

eXtreme Programming

• Chrysler Comprehensive Compensation System developement initiated (a payrollsystem supposed to support 87 000 employers, written in SmallTalk) (1994)

• System does not printout a single paycheck (1996)

• Kent Beck hired, Extreme Programming invented (1996)

• System deployed (1997)

• System closed after processing payrolls of around 10 000 people due totechnological and business change (1999)

Sources:https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System

Kent Beck’s book on Extreme Programming

AgileNon-Agile

eXtreme Programming

XP:Take well-known best practices of codedevelopment and testing to the extreme.

AgileNon-Agile

eXtreme Programming

AgileNon-Agile

XP rules

1 Planning2 Small releases3 System metaphor4 Simple design5 Continuous testing6 Refactoring7 Pair Programming8 Collective ownership9 Continuous integration

10 40-hour work week11 Continuous client interaction12 Coding standards

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

XP rules

AgileNon-Agile

Project Approach Questionnaire I

Strongly Agree Agree Neutral Disagree Strongly Disagree

• All members of the project understand and accept the DSDM approach(Philosophy, Principles and Practices)

• The Business Sponsor and the Business Visionary demonstrate clear and proactiveownership of the project.

• The business vision driving the project is clearly stated and understood by allmembers of the project team

• All project participants understand and accept that on-time delivery of anacceptable solution is the primary measure of success for the project

AgileNon-Agile

Project Approach Questionnaire II

• The requirements can be prioritized and there is confidence that cost and timecommitments can be met by flexing the scope of what’s delivered.

• All members of the project team accept that requirements should only be definedat a high level in the early phases of the project and that detail will emerge asdevelopment progresses.

• All members of the project team accept that change in requirements is inevitableand that it is only by embracing change that the right solution will be delivered.

AgileNon-Agile

Project Approach Questionnaire III

• The Business Sponsor and Business Visionary understand that active businessinvolvement is essential and have the willingness and authority to commitappropriate business resources to the project.

• It is possible for the business and solution development members of the SolutionDevelopment Team to work collaboratively throughout the project.

• Empowerment of all members of the Solution Development Team is appropriateand sufficient to support the day-to-day decision-making needed to rapidly evolvethe solution in short, focussed Timeboxes

AgileNon-Agile

Project Approach Questionnaire IV

• The DSDM roles and responsibilities are appropriately allocated and all roleholders understand and accept the responsibilities associated with their role.

• The Solution Development team has the appropriate collective knowledge andskills (soft skills and technical skills) to collaboratively evolve an optimal businesssolution.

• Solution Development Team members are allocated to the project at anappropriate and consistent level sufficient to fully support the DSDM timeboxingpractice

AgileNon-Agile

Project Approach Questionnaire V

• Tools and collaborative working practices within the Solution Development Teamare sufficient to allow effective Iterative Development of the solution.

• All necessary review and testing activity is fully integrated within the IterativeDevelopment practice.

• Project progress is measured primarily through the incremental, demonstrabledelivery of business value.

• There are no mandatory standards or other constraints in place that will preventthe application of the DSDM Philosophy and Practices on this project.

AgileNon-Agile

Rational Unified ProcessFurther reading

Alternatives

What if Agile is not an option?

AgileNon-Agile

Rational Unified Process

AgileNon-Agile

Why RUP is not an Agile framework?

• Does not involve whole team in the analysis phase

• Plans products in all the phases up-front, instead of choosing particular work atthe beginning of each iteration

• Explicitly orders the use-case flows (i.e. functions of the product) to be deliveredby their risk (starting with those with higher risk assessment)

• Measures project progress by completed use-case flows

• Answers common management and development problems by creating variousartifacts: use cases, use-case flows, Software Development Plan, Risk ManagementPlan

AgileNon-Agile

RUP phases

• Inception

• Elaboration

• Construction

• Transition

AgileNon-Agile

Inception

• Express clearly project scope: to capture context, as well requirements, constraintsand key features for acceptance criterias.

• Plan and prepare business case: to assess alternatives for risk management, teamorganization and project plan.

• Architecture draft: draft architecture through some PoC development.

• Prepare environment: assess project and organizations, select tools and whichparts should be improved.

AgileNon-Agile

Elaboration

• Create baseline architecture: create an executable architecture

• Refine vision

• Create detailed iteration plans and baselines for construction

• Refine use case and prepare construction phase: at the end of the phase 80% ofuse case descriptions should be complete.

AgileNon-Agile

Construction

• Manage resources, control and process optimization.

• Component development and acceptance criteria test development.

• Product release assessment based on acceptance criteria.

AgileNon-Agile

Transition

• Execute implanting plans.

• Finish support material.

• Test released product in development environment.

• Create product release.

• Get user feedback.

• Adjust product based on user feedback.

• Make software available to end user.

AgileNon-Agile

Take away message

Agile practices may be applied without Agileproject management,

but not the other way round

AgileNon-Agile

Take away message

Agile practices may be applied without Agileproject management,

but not the other way round

AgileNon-Agile

software engineering: are we agile enough? · agile non-agile dsdm dsdm philosophy scrum extreme...

Documents