Waterfall,Scrum, Kanban or None!
As if one morning everyone woke up and said, “Let’s do an Agile Transformation!”
Software development teams have been developing their software with waterfall model, which we call traditional method for many years. In this method, the requirements are collected in the early stages of the project, finalized and the design and development processes are carried out based on the completed requirements. However, as the internet became widespread and the consumption rate increased excessively, companies had to increase speed their time to market.
This led the project teams away from traditional methods to Agile methods.
At this point, 17 software gurus came together in the US state of Utah in 2001 and had a two-day brainstorming on software development.
The aim of the meeting was to increase software development productivity and to evaluate different experiences and approaches in this direction.
At the end of the meeting, they agreed and published the Agile Manifesto.
• “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. “
What if we improve this 4 items like;
• Team work over individuals and their interactions
• Value over working software
• Partnership over customer colloboration
• Embrace change over responding change
On this manifesto, Ken Schwaber and Jeff Sutherland, part of this visionary team, created the Scrum method.
Some teams fell in love with Scrum while others said it would never happen without Kanban. Some have tried other methods like Scrumban or XP.
But which method is fit for you? Sticking to a method or taking advantage of all of them and developing your own method? Or none of them? Let’s check the video below first to understand the chaos (1) ;
Now let’s find out how can we avoid from this chaos;
SCRUM
Briefly Scrum;
- Split your organization into small, cross-functional, selforganizing teams.
- Split your work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item.
- Split time into short fixed-length iterations (usually 1–4 weeks),with potentially shippable code demonstrated after each iteration.
- Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.
- Optimize the process by having a retrospective after each iteration
- So instead of a large group spending a long time building a big thing, we have a small team spending a short time building a small thing. But integrating regularly to see the whole! (3)
Scrum stands on 3 Pillars. These are;
• Transparency
• Inspection
- Adaptation
Scrum has roles,events and tools In order to realize these 3 pillars;
Roles;
· Product Owner;
· Defines the features of the product
· Decides on release date and content
· Prioritizes features according to market value
· Accepts or rejects work results
· Scrum Master;
· Responsible for enacting Scrum values and practices
· Removes impediments
· Ensures productivity of the team
· Protects the team from external influences
· Development Team;
· Cross-functional;Development,test, analysis
· Members must be fully dedicated
· No one has superiority
· No one can leave the team before Sprint is finished
· Max 9 people
· Roles in scrum;
Events;
· Sprint;
· One month or less
· No gap between sprints.
· Potentially releasable increment on behalf of the definition of Done
· Sprint Planning, Daily Scrums, development work, Sprint Review and Sprint Retrospective are part of the Sprints.
· Sprint Planning Meeting;
· Max 8 hours before sprints
· All team must be participated
· Looks for answers for these questions about deliveries; What and How
· Outputs; Sprint Goal and Sprint Plan
· Daily Scrum;
· Everyday
· 15 minutes
· No sitting
· Not for problem solving
· Development team are responsible
· Prevents other meetings
· 3 questions;What did you do yesterday? What are you going to do today? Everyting is ok?
· Sprint Review;
· Team presents what it accomplished during the sprint
· Everybody invited
· Max 4 hours
· Product owner tells which backlog items are done
· Output; Updated Product Backlog
· Sprint Retrospective;
· Only for team
· Max 3 hours
· At the end of the sprint
· Team discusses what went well, how can be improved.
Tools;
· Product Backlog;
· Defines all features of the product
· Prioritized by Product Owner
· Re-prioritized by Product Owner before sprints
· Owned by Product Owner
· Sprint Backlog;
· A subset of product backlog for current sprint
· Owned by Development Team
· Increment;
· Done backlog items which was integrated previous developments
You can easily reach the information given above. So is Scrum the right method for you? For this, I’m sharing a dialogue from Henrik Kniberg & Mattias Skarin’s “Kanban and Scrum making the most of both” book .Let’s have a look at it(4);
•Jim: “Now we’ve finally gone all-out Scrum!”
• Fred: “So how’s it going?”
• Jim: “Well, it’s a lot better than what we had before…”
• Fred: “…but?”
• Jim: “… but you see we are a support & maintenance team.”
• Fred: “yes, and?”
• Jim: “Well, we love the whole thing about sorting priorities in a product backlog, self-organizing teams, daily scrums, retrospectives, etc….”
• Fred: “So what’s the problem?”
• Jim: “We keep failing our sprints”
• Fred: “Why?”
• Jim: “Because we find it hard to commit to a 2 week plan. Iterations don’t make to much sense to us, we just work on whatever is most urgent for today. Should we do 1 week iterations perhaps?”
• Fred: “Could you commit to 1 week of work? Will you be allowed to focus and work in peace for 1 week?”
• Jim: “Not really, we get issues popping up on a daily basis. Maybe if we did 1 day sprints…”
• Fred: “Do your issues take less than a day to fix?”
• Jim: “No, they sometimes take several days”
• Fred: “So 1-day sprints wouldn’t work either. Have you considered ditching sprints entirely?”
• Jim: “Well, frankly, we would like that. But isn’t that against Scrum?”
• Fred: “Scrum is just a tool. You choose when and how to use it. Don’t be a slave to it!”
• Jim: “So what should we do then?”
• Fred: “Have you heard of Kanban?”
• Jim:…..
Now Kanban’s turn;
KANBAN
Kanban, is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks. Work items are visualized to give participants a view of progress and process, from start to finish — usually via a Kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested.
In knowledge work and in software development, the aim is to provide a visual process management system which aids decision-making about what, when, and how much to produce. The underlying Kanban method originated in lean manufacturing, which was inspired by the Toyota Production System.Kanban is commonly used in software development in combination with other methods and frameworks such as Scrum (5)
How can we use this method in software development?
The following 4 items are critical to Kanban;
· Visualize workflow; Split the work into pieces, write each item on a card and put on the wall. Use named columns to illustrate where each item is in the workflow
· Limit Work In Progress (WIP); assign explicit limits to how many items may be in progress at each workflow state.
· Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.
· Continuous Improvement; make continuous improvement by uncovering bottlenecks in your production and development line with this method.
Let’s more clear this;
One day in Kanban-land (6)
As you saw above team created a Kanban Board,defined a WIP limit and started development.While production they got a feedback and changed the WIP limit as continuous improvement
Scrum is great,Kanban also. So what is the difference between them?
All the informations given above is enough to choose a method?
The answer is in your way to do your business.You have to define your development life cycle.Can you use sprints and tell the customer “We cannot take any task they are not in Sprint Backlog? Can you reach time-to market by this way? All your features are well defined and no need to change during sprint? Are you developing fully new projects or developing daily maintenance task or both?
If I give an example of the method I use;
The organizations where i worked for, they were developing well defined features as well as daily features. For this purpose; I am using both of these methods like 1 of my teams using Scrum method and other one using Kanban method.
In this way, i can respond(or embrace) to my customers more quicker than the others. If i have a well defined project;I am giving them to Scrum Team, if the requirements can be changed on the way; I am giving them to Kanban Team.
The matter is using different boards. Because you are going to track your tasks by sprints in Scrum and by WIP limits in Kanban.
With this flexibility, when applying Scrum, you can transfer an urgent development item to the Kanban team, catching the time to market and keeping customer satisfaction at the highest level.
In short, If you say “Let’s use Scrum or Kanban” without fully understand the needs of your team, your company, your customer, your industry , it will be caused team and customer unsatisfaction.
If you wake up one morning and say, “Let’s Make Agile Transformation!”, do not interrupt your sleep at all. This is better for your organization. 😉
References;
1. https://www.youtube.com/watch?v=Jm1VEO9C4VQ
2. https://www.scruminc.com/the-3-5-3-of-scrum/
3. www.mountaingoatsoftware.com/scrum
5. https://en.wikipedia.org/wiki/Kanban_(development)
6. http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html
