For many people, one of the biggest challenges in transitioning to agile from a more traditional waterfall or iterative approach is learning to think differently about how work is done.
In a traditional project environment, you aim to produce a defined set of business outcomes by creating a set of deliverables. To fund these activities, you create a business case that justifies the expenditure by setting out exactly what resources will be required to accomplish those outcomes and demonstrating that there’s a net benefit from that work. Once the business case is approved, the project team will work to build a product within those time, budget, ans scope constraints.
With agile, many of these concepts go away or even become counter-productive. Instead, you start thinking as the development team as being capable of delivering a set amount of work over a period of time. The goal becomes to keep that team working on whatever is most valuable at any given time. The cost of the team’s work is fixed, and you’re aiming to elevate the level of benefit that they deliver.
Once you start thinking of value as something that flows continuously through the work of an agile team, then some of the other practices take on a new light. For instance, why is it important to build software regularly? Even if you don’t release it to production constantly, the frequent cadence of delivery actually forces you to get better at what you do.
Why? Well, I remember working on a project where we were delivering a new version every 3-6 months. One of the problems we ran into every time was that when the development team went to build a new release, it wouldn’t work. Every single time, we ended up spending up a week or more just getting the system to build, and that was work that only a few of the key team members could perform, leaving the rest of us not doing that much.
If you are doing these builds on a regular basis, writing requirements on a regular basis, testing on a regular basis, you have a strong incentive to improve how those activities are done. Even better, you will actually remember what you did last time when you’re thinking about how to do it better. If you only do something every six months, like we did with the software builds, it’s hard to apply lessons learned effectively. This is why retrospectives are sometimes referred to as the most critical agile practice.
Being truly agile isn’t about adopting a set of practices. Those practices may help you, but the real key is a mindset shift to:
- A continuous flow of value to the customer, and
- A focus on continually improving how you work.
If you can’t make that shift, it’s going to be hard to really change to agile delivery. If you can, though, you are already most of the way there.
