1. You are completing sprints but each sprint backlog is full of failure demand
(Failure.. what? )
| Value demand |
|
Failure demand |
| Demand for service from customers
|
|
Demand caused by failure to do something right for the customer
|
| |
|
A demand from where there is no hope of making money
|
| Example |
|
Example |
| I need.. |
|
.. you didn’t..
.. where is my order |
A team I worked with was considered doing ok. Team was happy with Scrum. At a closer look 60% of all stories where failure demand and over 19% of all stories returned at a later sprint. The cries from the Product owner of problem keeping commitments turned very real..
2. Sprints are completed but software rarely reach the market, if ever, it is late
The development team completes stories, tests them and move on to next sprint. The result is passed on to a team in charge of integration and acceptance testing. They pass it on to a customer integration team. There is a product owner prioritizing each step. From business side the deliverables are few, random and if ever occuring – late.
The evil side of this is that the problems are unseen by the teams themselves. Each team can rightly point to out they are delivering and indeed at a higher velocity.. Therefore it is not unlikely they will resist when someone arrives pointing out they need to change. This this is a situation of sub optimizing goals, in my case this was solved by simply aligning the sprint goals of the teams.
3. Sprints completed, software delivered – a team somewhere else is getting thrashed..
A component team is delivering with high quality, on time,. They are the A team of the IT organization, always delivering on time. Unseen at another department, team B uses their components. But they run at a slower release cycle which makes them constantly readjusting to the frequent releases from the A team. On top if it all, they get blamed for not delivering "why are you not delivering? We have this top notch process called Scrum.."
In a real case we solved this by aligning the release cycles of the teams.
4. A low but regular percentage of stories committed by the team never gets done
So? – you might argue.."It is in fact Scrum that saves them since it enabling them to work with a clear prioritization…." Yes a gifted product owner will save you any day. But what is causing this remains hidden. A broken architecture, unreadable code, coding from incomplete stories, developers untrained in the technology… it’s all hidden in the sprints.
A team I worked with blew sprint after sprint but did not see this. After all, they continuously met the main business goals. How do you know you can spot this? This requires rich flow transparency (Kanban) or numeric measurements to become visible.
4. Scrum is working, team runs it by the book, quality is good, business is happy.. just that we get no improvements
If we accept status que we are not likely to implement new ideas. And so the continuous improvement process is broken before we even start.
A team I worked with lacked visibility into their results. This made it hard to tell if they were heading in the right direction or not. Once visibility into quality, velocity was put in place up, they immediately questioned the benefit of velocity "this is too linked to customers release cycle, we can’t see our own improvements" (and rightly so!)
Scrum is easy to implement, but hard to interpret.
Lean teaches situations like these are unacceptable. We cannot accept poor quality, sub optimization or not improving.
My point is:
- We can improve a well functioning Scrum if we know what we are looking for
- Lean helps us see areas to improve on
- Kanban can increase transparency so team can see the Lean things visually
- Knowing what to look for – is hard. We need to mastering a wide range of techniques well beyond Scrum before we can enjoy the fruits of real continuous improvement
