At my training classes the students get actually a bit disappointed when I tell them that Scrum does not solve many of their problems. Most of the students expect that Scrum will solve most of their problems and quality, productivity, predictability and value will be greatly improved. Well unfortunately Scrum does none of that!
Introducing Scrum in your organization does a lot of other things. The main thing it does is that it gives you a lot of very valuable insights. In fact what often happens is that you embark on the Scrum roller coaster and after a few sprints you realize that Scrum does not work in your organization for various reasons.
Scrum is very very hard and it just does not work here because we are special.
You are for example just not able to:
- Create small cross functional teams;
- Deliver tested, integrated and accepted software in short sprints;
- Handle all those disturbances that pop up from the outside during sprints;
- Have specialized people help each other on different specialization areas in a team;
- Deploy to production frequently;
- Produce code according to your well known quality standards every sprint
- Have teams dedicated to a product for longer time periods;
- Create real improvement actions during retrospectives;
- Find a good Product Owner to lead Scrum Teams;
- Steer development on value;
- Produce reliable forecasts and plans;
- Detail your requirements Just In Time;
- Get developers involved in visioning activities;
- Have performance testing be part of a sprint;
- Have architects that know how co write code;
- Have developers understand the domain;
- and so on
There are so many reasons why Scrum just does not work in your organization.
Well if you have so many reasons why Scrum does not work in your organization then Scrum is in fact working perfectly at your organization!
When you introduce Scrum you can suddenly see, if you are willing to face it, numerous dysfunctions or as I want to call them potential improvements everywhere.
Now the question becomes “What are you going to do about them?”. If you are not willing to do anything about them then there is no use in adopting Scrum!
Management, as always, plays a very important role. Is management continuing to work around the problems, that is doing a lot of rework and firefighting? or is management going to work on improving the processes and focus on problem solving?
That is the main question!
In a continuous improvement culture, management sets challenging goals. Once those goals are met and things stabilize and teams become happy and feel there is nothing worth improving, management changes something and creates unstableness upholding the same goals or even setting more demanding goals to achieve. That is what Scrum gives you, challenging goals you can use for continuous improvement. The goals must be very challenging as described in The New New Product Development Game.
The thinking behind this is that you need to create product to beat your competition today but that you need to improve to beat your competition tomorrow!
So there is no point in taking on a easier approach because Scrum is hard. Scrum challenges you to be perfect and that is, although you will never be perfect, exactly what you need for improvement.
In agile we say that we do value driven development. We try to work on the most valuable items first so that when the time comes when there is either no more money to spend or no more time left we have the most valuable stuff done and deployed to production.
From all the projects and product development teams I worked with over the years I have seen only a few that measure and track value across time.
The challenges with measuring value are that value is defined different depending on your perspective and that there are numerous possibilities to measure it.
There is value in doing the right thing, that is value measured on outcomes. And there is value in doing things right, that is values measured as output. There is a big and important difference. Output is the stuff you produce like e.g. stories. How much stuff are you making, how fast and at what costs.
Outcomes is the difference it makes. Why are we making this stuff? and why should anyone care? You could measure things like economic value, product quality, strategic alignment and innovation rate just to name a few.
In this post a simple example of how you could work with economic value.
Lets say you are a project team and are delivering your project in 3 month release cycles. The objective of the project is to be able to increase online sales by 10% from 10M to 11M. Great, how do you measure that while you are developing? you can’t as you will only get feedback after shipping the functionality!
What you can do is to let the product/sales/marketing people make an impact estimate on how much sales increase they can achieve with the proposed epics of functionality.
Lets say they estimate that the new functionality impacts sales increase as follows
|Epic 1||Epic 2||Epic 3||Epic 4|
|Increase from 10M -> 11M||30%||10%||10%||50%|
Don’t worry, product managers, sales and marketing actually studied for making these estimates. It was when a VP once told me
…getting value estimates is easy, that is what our product managers and our sales people have been doing long before you came in…
that I started to realise that it is nothing special at all.
Once you have these impact estimates you can use them to assign economic value points to your stories. The impact estimates limit the amount of value the epic and its stories can create. Without such a limit the value points would be meaningless because you would not able to see progress towards the objective. One way to assign economic value points is to first do a relative value point estimation on your stories. Once that is done you can just distribute the estimated impact.
Lets say Epic 1 consists of 8 stories.
|Epic 1||Story 1||Story 2||Story 3||Story 4||Story 5||Story 6||Story 7||Story 8|
With this data you can easily measure value delivered each sprint. You can use this data as one out of many of the attributes for ordering your backlog. Another benefit is that you can take action when the rate of added value starts decreasing. It will as value added most of the times follow an s-curve.
After your first release you can start measuring real progress towards your objective of 10% online sales increase.
You can easily extend the impact table with other objectives and estimate impact for those. You could add for example strategic alignment, innovation rate, costs and so on.
Oh yes, of course you have no time to spend on estimating and planning as there is never enough time to do it right, but always enough time to do it over?
This post is inspired by my favorite systems thinker prof Russel Ackoff.
In development we have lots of uncertainties. Uncertainties in technology, scope, costs and schedule just to name a few. We face the challenge of staying in control in a uncertain environment. We face the challenge of dealing with the uncertain future.
There are two things you can do to deal with the future. You can use assumptions and you can use forecasts. Forecasts are about probabilities of events happening and assumptions are about possibilities of events happening!
A thermostat controls the temparature of a room by frequent measuring temperatures and adjusting the heating-cooling system. The thermostat does not need to predict or forecast the future ‘weather’ in the room in order to control it. The thermostat does not need probabilities. It only needs assumptions! The thermostat assumes that the temperature will change in the room and therefore it is made in such a way that it can respond rapidly and effectively to whatever the temperature turns out to be.
There are two nonexclusive ways of dealing with possibilities; contingency planning and developing responsiveness.
We do contingency planning for the cases we see as an exceptional risk. You identify the small set of possibilities and come up with a plan or measure to tackle each possibility. I carry a Jerrycan in my car not because I forecast that I will run out of fuel in the middle of nowhere but because I assume it is possible that I do. When the set of possibilities is to large and therefore to complex to handle we develop responsiveness.
In agile teams there is a lot of attention for developing responsiveness. We have short iterations and increments, various quick feedback loops, work in order of value and keep quality high so we are ready to change direction every iteration. There is also a lot of attention on forecasts. We have release burndowns, avg cycle times, work in progress, defects trends and so on. There is nothing wrong with forecasts about the future except for the unpleasant fact that they are usually wrong.
In Scrum we used to say that a team committed to a sprint goal. The use of the word commit made lots of people think that a team should be able to predict the future after it was sprinting for a while. Nowadays in Scrum, in order to make things clearer, the Development Team is said to give a forecast of what it thinks it can do within a sprint. So a Development Team actually makes a statement about how probable it is that they can accomplish the selected product backlog. It’s a forecast based on the Yesterdays Weather XP rule.
In agile teams there is little attention for contingency planning. Agile Risk management just does not seem to be interesting enough and set based development seems to be regarded as to expensive by most teams! So lots of agile team focus on their forecasts although the best way to handle the future is not by trying to predict it but by the possibilities we have of adapting to it! An Agile team should therefore assume certain possibilities will materialize and have options ready so they can adapt quickly to what the future might bring. An agile team should therefore value assumptions over forecasts.
Complex system theory and especially social complex systems are getting a lot of attention the last few years in the Agile community.
Complexity remains a ‘complex’ topic as there are so many views and perspectives from e.g. neurobiology, anthropology, social sciences, mathematics, molecular biology, philosphy, economic studies and computing science just to name a few 🙂
Scrum is build around empirical process theory, but also around complexity theory in general and Complex Adaptive Systems (CAS) in particular. See Jeff Sutherland on this.
In a CAS something spectacular can happen! Without any centralized control and with very simple rules the most amazing results can be obtained. Termites for example make these great hills full of chambers and complex tunnels and groups of people are able so solve problems they do not know upfront how to solve. Individuals self organize, the right results emerge and the CAS adapts to a changing environment to stay successful. Wow… this is to good to be true!
See Beats 2006, Complexity, learning and organizations for details.
Interesting to notice is that a CAS naturally moves towards operating in a region called the edge of chaos. This is interesting because research shows that groups of people operating in the edge of chaos are maximal creative and productive.
Put more formally “there is maximum capacity for information computation”
– R. Lewin 1999. Complexity: Life at the Edge of Chaos.
Hmmm so what? why should I care?
Most of the time when you are developing software you are cracking a problem which you do not know how to solve upfront. Usually there is a lot of uncertainty on what to build exactly and on exactly how to build it.
A situation like this can be handled by moving your team towards the edge of chaos! The exciting part is that Scrum helps you set up the conditions for doing so and also providing all the inspection and adaptation points necessary not to fall over into chaos.
On 16 and 17 Januari 2012 I’ll be giving the Professional Scrum Product Owner training of Scrum.org. The training will be in Utrecht and will be in Dutch.
You can register and find more information here.
Back in March 2011 I came up with the idea for a Bathtub conference in the ALE community. See original thread here on the ALE Linked In group. The ALE Bathub was the first successful project that came from the ALE community that was being put together at that point in time. See ALE Network for the Bathtub and other ALE projects.
At the first ALE conference in Berlin we came together and discussed my idea to move the Bathtub conference organization around Europe. The first team including Oana, Pascal, Carlo, Guntram and Cesario did a fantastic job for the first 3 Bathtubs but now it is time to pass the bucket and foster fresh ideas from other ALE members across the world.
The idea is that every Bathtub will be organized by different ALE people so that it becomes a real ALE event by the ALE people and for the ALE people.
For Bathtub IV we passed the bucket to Catia Oliveira and Michael Leber. They will be working on the organization and probably invite other to help out and make Bathtub IV even better the the first three.
Bathtub III is on October 20th from 21:00 until 22:40 CEST.
21:00 – 21:15 CEST | Esther Derby – Re-thinking Management
21:20 – 21:35 CEST | Scott Barber – An overview of Performance Testing for Agile/Lean teams
21:40 – 21:55 CEST |Cesario Ramos – Lean Agile Sandwich
22:00 – 22:15 CEST | Olav Maassen – ‘Surprise surprise’
22:20 – 22:35 CEST | Filippo De Santis – Xkanban
Goto Bathtub III for more info and registration.