Ability to turn on a dime for a dime
This is how Craig Larman sometimes describes what agile is. There are many definitions, and since it is a very deep and broad term it is hard to describe, but I think this captures what we intend to achieve when we are are trying to become more agile.
In a large organization with dependencies between products, teams and businesses it can be very hard to achieve. In smaller organizations it is usually not that hard as long as people are highly motivated to improve.
Personally, I find that the easiest way to define what agile is, is to describe what it is not.
It is not an approach where you plan everything upfront and then execute on the plan, expecting that everything will go according to plan. This traditional approach is often called the Waterfall approach. It has been shown over and over that this approach most of the time is very unfit for software development.
The reason why the seemingly logical waterfall approach is so unfit for software development (almost always) is uncertainty. When uncertainty is very low the waterfall approach can work well. But this is almost never the case with software. Uncertainty is often present in for example understanding of the actual user needs, in a solution that will fit the needs, in technical aspects, in how much work it will take and in how high the demand is for the solution.
Some of the issues that are build in to the waterfall model are:
- Long leadtime leading to long time to market and long time for meaningful feedback
- Handovers between different people often resulting in misunderstanding
- Handling change usually comes with a lot of overhead since it will mean changes to a plan that many people might have agreed to
In companies subscribing to a waterfall approach it is common that it becomes heavier and heavier over time. The reason for this is that most projects will fail and the most common reasons for failure is misunderstanding of user needs and how to translate those to proper solutions. The logical fix for this seems to be to add more time to getting the requirements right and to add more rigor to the change management process. Unfortunately this is a vicious circle that makes the problems and challenges bigger and bigger.
Agile is hard to describe and hard to understand. This is another way of looking at it:
Agile transformations can be very challenging. One of the reasons are that agile might be at odds with the existing culture and mindset of an organisation and it’s leaders. And changing culture and mindsets is very hard and takes a lot of time.
So what is an agile mindset? It is closely related to the agile values. I believe that an agile mindset is essentially about embracing life-long learning and the belief that everything can and should improve continuously. On all levels in the organization, the products and the people.
The organization and it’s leaders need to wholeheartedly subscribe to the following:
- Accept that uncertainty makes it necessary to decentralize control as much as possible
- Trust and respect strongly collaborating teams to continuously improve and deliver
Organizations and leaders that do not believe in this will not become very agile. In my over 10 years helping out with agile transformations I have met many managers that do not believe in the above. They have believed in some of the practices and been taken in by the hype. But doing a handful of practices will not bring a lot of value if the mindset, values and principles are not in place.
Essentially it comes down to how you view other people. If you have a strong belief that you are better than others and you are more interested in control than helping people grow you will not be able to support an agile organization. This mindset can be extremely hard to change. People with this mindset is generally much better suited for individual contributions rather than as leaders in an agile organization. They are often intelligent high performers, but people that care more about control than growth can do tremendous damage to an organization trying to become more agile.
The matter is complicated due to the complex nature of leadership. If you have tightly managed and controlled a person or a team for a long time, you can’t just stop doing that and say you trust them to run the show from now. Such a transformation needs a proper transition and teams and people needs to be supported to gradually build the skills and tools needed to make it work. Doing it at large scale is even more challenging. And even though you should decentralize as much as possible you need to balance that with the need to align business and products over multiple teams.
There are many, many practices that will help the trusted teams deliver in an agile way. And one thing strongly helps managers who are uncomfortable with the high level of trust that is needed is the extreme transparency that is present in agile ways of working.
The core agile values comes from the agile manifesto.
On top of this we have values from different agile frameworks, like for example Scrum:
The core agile principles comes from the agile manifesto.
On top of this nowadays lean and agile are merged and principles from lean are part of agile. For example by the Poppendiecks:
- Focus on customers
- Optimize the whole
- Energize workers
- Reduce friction
- Enhance learning
- Increase flow
- Build quality in
- Keep getting better
There are many, many agile practices and more keeps getting added as we learn more. Some examples are:
- Test driven development
- Daily stand-up
- Planning poker
- Sprint planning
Back in the days we used to talk about best practices. It might be more helpful to consider proven practices. Some practices work really well in some context. But the best practice to use can vary with the context. And the context can change as an organization changes and becomes more mature.
These are some of the most important aspects of agile from a product management perspective:
- Different style of leadership is needed
- Self-organizing teams and different ways of collaborating
- How agile supports rapid innovation and feedback
- How to constantly prioritize the right things
- How to achieve a continuous flow of value
- High level understanding of technical practices
- High level understanding of continuous improvement
- Agile at scale