In my previous article I described the most common problems affecting IT performance. In this article I'll describe ScruXBan, a methodology that I defined while writing my book on <ALT+F>.
I'll start looking at the most common Agile methodologies currently in use today, identifying pros and cons. I'll then describe ScruXBan as a possible alternative to those methodologies; an alternative that can help us improve the value we deliver the business with.
When faced with the problems I described in my previous article, the IT community moved from pre-emptive methodologies such as Waterfall to Agile first and, most recently, Lean.
Agile and Lean certainly helped solving the majority of the problems faced by IT teams, e.g. delayed Time To Market, early commitment, lack of communication between the business and IT and lack of quality. They did so by placing the business at the centre of the software development lifecycle, by applying iterative and incremental deliveries (what Craig Larman in his book Agile & Iterative Development defines as IID), by shortening the feedback lifecycle thus allowing IT decision makers to delay their commitment and finally by increasing attention to quality. The Toyota Production System or TPS, brought to the table an even more aggressive approaches to business value delivery, by defining Lean manufacturing and the concept of waste. In Lean, waste is considered as any activity for which customers wouldn't pay and as such, it could (and should) be eliminated without affecting the value delivered to the business. Lean manufacturing was eventually not only exported to the US, revolutionising the car manufacturing industry (especially Ford), but eventually was exported to other disciplines as well, amongst which software engineering.
Lean methodologies applied to software engineering go under the name Kanban, whereas the two most popular Agile methodologies currently in use are Scrum and XP. Taken in isolation, each of these methodologies have pros and cons, however it's the cons that I'm concerned with. If you talk to a Scrum Master, they'll tell you that in order for Scrum to work, one should apply Scrum by the book. However, having used Scrum in a number of projects, I came to realise that there are quite few aspects of Scrum that get in the way of maximise business value delivery whereas others are useful.
Let's start with Scrum. I think that Scrum is great in providing project management cadence. It defines the team structure (with the PO, the Scrum Master and the team), Sprint and Release Planning meetings and metrics (with velocity, burnups and burndowns). You want to do Agile? Well, if you go with Scrum you can certainly perform all classic project management activities while moving within an Agile methodology. However, in my view, Scrum presents some internal contradictions, especially when it comes to early commitment. It also implies some activities considered wasteful, e.g. sprint planning meeting. In fact I believe that the only thing that really doesn't work in Scrum are Sprints. Let's see why.
One of the cornerstones of Agile methodologies is that as Agile practitioners, we don't have a crystal ball when it comes to estimates. For this reason, in Scrum we're not asked to provide the business with an exact delivery date (or rather we're asked, but we push back). Instead we're asked to provide estimates of when, given what we know today, we think we'll be able to deliver the business with what they want. In Agile we refine the estimates as the project progresses and as our knowledge of the domain, the risks and our team mates increases. Additionally, as the teams work together and get to know each other, estimates become more and more accurate.
One of the project ceremonies in Scrum is to have a Sprint Planning meeting at the beginning of each iteration. The ceremony dictates that the team members commit to deliver all stories picked up from the backlog by the end of the upcoming Sprint. There are techniques aiming at reducing the risks of such approach, such as chosing a certain number of must have (high priority) stories, a smaller number of should have ones and finally a very small number of could have ones. The team is asked to commit to the delivery of all must have stories. I don't know if you've ever worked with Scrum, but my personal experience is that, no matter from which angle one looks at it, it's impossible to commit to the delivery of a certain number of stories by a certain date, simply because the future is unknown.
This is not, however, the worrying bit. What is really worrying is that by asking the team to commit effectively to a Fixed Date, Fixed Scope project, Scrum goes against its very foundating principles, i.e. that it's not possible to commit to a delivery date as uncertainty reigns our lives.
This is, in my modest opinion, the biggest pitfall and the biggest contradiction of Scrum. When applying Lean concepts to Scrum, the pitfalls become even more evident. The ceremonies surrounding Scrum are something a client wouldn't pay for, therefore can be considered waste and should, whenever possible, be eliminated.
OK, so from Scrum we don't like early commitment and process ceremonies.
What about XP? XP is an Agile methodology that represents a set of Principles and Practices. There is nothing wrong with that, in fact I like XP's Principles and Practices. All XP lacks is, for my requirements, project management cadence, i.e. XP tells us how to apply best development practices to our projects, how to promote a trust and grassroot culture, but it doesn't give us project management structure and I believe that this is a requirement for any project, be the methodology being used more or less pre-emptive.
Similarly, Kanban lacks project management structure, although in my opinion it's more structured than XP. This methodology in fact suggests to start with the current flow visualisation to expose and therefore eliminate waste and to continue with a smooth flow of activities aimed at maximising business value by reducing Work In Progress (WIP). Kanban makes also an attempt to help us be more precise when it comes to estimates, by introducing concepts such as Classes Of Service (COS). However, I can't see in Kanban the elements of project cadence.
I like Scrum's concepts such as team structure, velocity, burnups and burndowns, Release Planning Meetings and the Backlog.
So what to do? It would appear that if one was to choose one of the above methodologies in isolation would get and loose something.
I decided to use the most useful parts of all three methodologies by defining a new one called ScruXBan which, by now, I believe you'll have guessed where it gets its name from.
Scru(m) - X(P) - (Kan)Ban
From Scrum, I'm adopting the following concepts:
- Team structure and roles (PO, SM and the team)
- Backlog
- Release Planning meeting
- Burnups and burndowns
- Velocity (although combined with COS just as a metric tool)
- Stories
From Kanban, I'm adopting process management, i.e. the art of streamlining the workflow by visualising the process, identifying and remove waste, empowering and coaching the teams, seeing the big picture, doing the right thing right from the start.
If you want to know more about ScruXBan, I'd suggest to read my book on <ALT+F> where I introduce how to use this new methodology in an actual project.
Recent Comments