The first few steps in an agile transformation are critical to success. Lay a good foundation and what follows will be easier to build on.
So what is a good way to start an agile transformation?
Know your reasons
In the scientific method you first create a hypothesis, then you measure your results and finally you make adjustments based on those measurements.
Before you even start on an agile transformation you need to list your reasons for wanting to change. If the agile transformation is a success, what do you expect to happen? What is your hypothesis?
It is just as important to decide how you will measure your success. If you can't measure progress, how will you know that you are making any? How will you defend the changes you are making if there is no evidence for the benefits it has brought?
Engineering practice - easier to do in isolation, great for productivity
Many aspects of an agile transformation impact across an organisation. This presents serious challenges, both in facilitation and in coordination.
Software engineering practice changes can, however, often be implemented with limited dependency on those outside of the technology team. This makes them a great place to start in your agile transformation.
An agile framework like XP includes many working practices that can be implemented quickly and that can often pay for themselves. As an example, time invested in test driven development can often be paid back in a reduction in the time spent fixing defects.
There are several other reasons why agile engineering practices are a good place to start:
- It is likely that some technology workers will have already had exposure to agile
- Improved engineering practices often excite technology workers and can lead to a boost in morale
- Some agile engineering practices can produce quick, measurable results
Retrospectives can help right now
The idea of retrospectives, reviewing what has happened and looking for potential improvements, is hardly a monopoly of agile. Many organisations hold ad-hoc retrospectives and get value from them.
Why not focus more attention on how you do your retrospectives? Are there steps that you can take to make them more effective? What is the most effective frequency to hold these types of discussions?
Often the way to make retrospectives more effective is to empower those present to fix the problems they encounter. This reduces the cycle time between identifying an impediment and implementing an improvement.
Retrospectives can improve morale and can offer real productivity gains.
Prioritisation is the key to moving the whole organisation forward
While the technical teams are focusing on engineering practices the business side of the organisation can be focusing on prioritisation.
Most organisations already prioritise. But they tend to prioritise in several places at once. Perhaps different departments will have different priorities. In international organisations it is also common for offshoots in different countries to have different priorities.
A real challenge is to establish a strategic prioritisation. This kind of prioritisation is very powerful and it can drive the agile transformation. Focusing on delivering what the organisation views as its highest priorities is a great way to move forward. This suits the agile iterative approach to development and the agile principle of early and continuous delivery.
With the foundations in place, start to bring people together
Prioritisation, continual improvement and good engineering practices are important. Equally important is the focus on people. How do your teams work together? How do you break down silos and build trust? People and interaction is key to agile and is at the heart of a transformation.
Structuring your organisation to be agile is going to require some significant changes. This is often the most difficult aspect of an agile transformation as it impacts on roles and responsibilities.
With a good foundation in place and measurable improvements already seen, you have a better chance of success.
Image by Kimberly Vohsen
Tags: agileTarget Audience: DeveloperProduct OwnerScrum Master
