In Which best practice to implement first? I said that agile best practices are really answers to problems. The best way to identify the correct agile practice to implement first is to work out the root causes of your biggest software development problems. Let’s take an example that is common complaint from many business customers: how come our IT department delivers so little? Rather than just complain about this, let’s keep on asking ‘why’. We can list some of the products that our IT department produces:
- Project plans
- Project charters
- Test plans
- Software working in production
- Change requests
- Status reports
Of these, what is most important to us? In fact, there is only one product which we really care about: software working in production. The others are simply products that we have been led to believe are required to deliver software on time and budget. From a lean point of view, these other products are ‘waste‘: they do not directly add value to the customer.
In my research I found that most of the time, it was not just a project manager delivering these management deliverables, it was the whole team: programmers, application development managers, testers, etc. So, why is IT spending so much time doing everything but what is essential to producing software?
The following is a snippet of a ‘Current Reality Tree’, a Theory of Constraints approach to describing how things work right now.
A Current Reality Tree (CRT) can be read ‘A causes B’ or ‘A means B’, e.g. “Lots of time updating plans & estimates means less time for delivering software”. We can create a CRT by asking ‘why’ repeatedly. For instance, why do we spend less time delivering software? Because we spend lots of time updating plans & estimates. Why do we spend so much time updating plans & estimates? Because changes happen more frequently than we had planned. The power of a CRT comes from being able to identify some of the root causes to business issues. Some of the answers are more implicit assumptions than direct answers. e.g. Why do changes happen more frequently than planned? Not only because we keep on changing our list of priorities, but also because the business demands that IT produce a new set of plans, status reports and estimates of new delivery dates every time the priorities are changed.
So, how can we turn these problems into solutions? We need to tackle one or both of the two root causes identified in the CRT:
- The business demands a plan-based approach
- Multiple changing priorities
In my experience, changing either one of these brings a lot of great results very quickly.
At first glance, either of these seem to permeate most business environments. Can there be an alternative to a plan-based approach to building software? It’s to this type of question that agile best practices provide such great answers. For instance, a time-boxed deployment schedule where the schedule is fixed, but scope is allowed to vary is a non-plan based approach. If a feature takes an unexpected amount of time to deliver, it can slip to the next iteration. The impact of the change is small and the product that requires updating is the software itself. In contrast, in a plan-based approach, the team delivering the software needs to update plans, estimates and delivery schedules. The next steps are to identify how this time-boxed approach will work in practice. This is to ensure that it does not create additional business issues and to ensure that we have everything required for a successful implementation. In a way, this is just another way of continuing to ask ‘why’. Luckily, as we get deeper into the implementation, there will be other agile practices to help us, such as continuous integration and test driven development.
Technorati Tags: agile, development, lean, software, toc