Agile and friends

Agile and Friends

Radan Skorić

Waterfall method

BRUF
Distinct phases:
1. Requirements
2. Design
3. Implementation
4. Verification
5. Maintenance

Change!

Unexpected Change!

Unexpected Late Change!

2001, Snowbird, Utah

17 Software development experts

The birth of the Agile Manifesto

The Agile Manifesto

agilemanifesto.org

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Scrum

Sprint - timeboxed effort Image of a sprint on a timeline

Sprint planning

Select Product Backlog items
Breakdown to create the Sprint Backlog

Sprint Review

Sprint Retrospective

Sprint is the basic unit of Scrum. It is a timeboxed effort that aims to deliver the next iteration of the working software at the end of it. It is usually between 1 week and 1 month long with 2 weeks being the most common. It starts with Sprint planning which consists of two phases. In the first timeboxed phase the whole team works to identify items from the higher level product backlog that could be delivered in this sprint. In the second phase the team works to break it down into smaller tickets that are then estimated and form the Sprint backlog. At the end of the sprint working, and only working, features are demoed for the stakeholders during the Sprint Review. After the Review the team holds a restrospective where they discuss what went wall and what went wrong during the sprint and how they can improve.

Scrum & Agile values

Everyone creates the sprint together
Working software at the end of each sprint
Customers are involved in between sprints
The product backlog can change for the next sprint

Values to principles

Welcome change

=> Discover the need for it early

=> Remove ambiguity

=> Show working software often

Other agile methodologies

Kanban
Scrumban
Extreme programming

Kanban is a method that focuses on the continuous flow and elimination of bottlenecks. There are no sprints, the team focuses on the things that are in progress and when done it pulls from the top of the backlog which the product owner is free to reprioritise to keep the most important items on the top. A key component is WIP limit prevent accumulation of partially finished work. Scrumban, as the name suggest tries to borrow from both Scrum and Kanban and then adds a bit of its own into the mix. Roughly speaking, from Scrum it takes sprints but has them in variable length and sprint planning is triggered when number of planned tickets becomes too low. From Kanban it takes WIP limits to ensure an efficient flow. Extreme programming is on the surface very similar to Scrum, it also has planned sprints. It is different is a number of subtle ways which I won't get into now. Perhaps the biggest difference is that XP prescribes engineering practices like TDD and Pair programming while Scrum doesn't. However XP practices are usable in almost any Agile methodology.

Importance of culture

All together
Shared success
Chicken vs Pig
Valuable work

Quite often you might hear that people tried to implement Agile, followed the practices to the letter but failed. The first place to look for a culprit is the culture. Company and team culture. The most important thing to adopt is the notion that everyone is working together. Great team work is of paramount importance to get Agile right. That implies that there has to be a notion of shared success. If one developer finishes their tasks on time but the feature is not finished because another didn't finish his then there is no value delivered. It might have been better if the first developer first helped the other finish their task. An extreme example is how a CEO, if he can't help in any other way than by bringing coffee to the developers then the best thing he can do for the project is to go make some coffee. The concept of a Chicken and a Pig is sometimes used. It comes from an anecdote about Chicken telling a Pig that they should open a restaurant together. Pig asks what would it be called. "Ham and eggs" says the chicken. The pig answers "No thanks, I'd be committed but you'd be only invested." It is important for all of the team members to feel like Pigs, committed into the project. People on the outside that provide valuable insight, like users or beta testers, are chickens, invested but not committed. And the only way for people to get that sense intrinsically is to draw pleasure from their work and the best way for it is to see clearly the value you create from your work. That is another reason why all Agile methodologies put so much emphasis on Value, their rapid delivery and putting developers in contact with the stakeholders who's lives they improve.

Thank you!

Questions?