I don't like to talk about agile.
“Agile” - a word I try to avoid like fire when talking to our customers.
I try to avoid it because it’s a tainted word and hearing it makes people anxious. The lack of a long-term, detailed plan can be scary. But having a long-term plan gives rise to a false sense that we know exactly what is going to happen in three-six months or a year. I’m yet to see a long term detailed software development plan to result in a successful release on time and on budget.
Understanding the principles and practices of agile methodology will give you tools to let go of long-term detailed plans, and innovate with unprecedented speed, staying ahead of the curve. It doesn’t mean you need to change everything you’re doing today. One step at a time. Allow yourself and your team to choose one of the agile principles and try it out in practice.
While all our clients had stand-ups or daily scrums, retrospective meetings, and sprints, they often missed the point behind agile software development principles and practices.
The key points I will discuss in this article are:
- Changes happen in real life all the time.
- Knowing what the problem is, requires different expertise than being able to design the correct solution for the problem.
- Fast, simple iterations and measuring impact allow you to deliver the most value.
Waterfall methodology is a sequential software development approach. Each phase (planning, design, development, testing, etc) follows the previous one. This can mean that months or years pass before the initial conception is put in front of the customers. Who, by that time, probably want or need something different.
In agile processes we make the smallest changes that might lead to additional business value. Then we verify that our assumptions were correct through measurements. Software is released every couple of weeks, or more often. Emphasis is on measurable business value.
Change
Embracing the fact that change is unavoidable at every level of a software project, is key. Let me illustrate this through two real examples.
The first example
Our client informed us that they were working on designing a new feature. Planning and design would take around 3 months. Development would take roughly the same.
At that time, I failed to explain to our clients what the potential pitfalls of this approach would have been. The world around us is changing, so the more complex our requirements are today, the more likely the requirements will change.
In fact, a couple of months after we released the feature, one of the external dependencies of the feature had changed. The business stakeholders did their best to devise a solution to a problem they thought they had, but the result was wasted time and money.
Today in a similar situation I would suggest to consider the following, more agile approach:
- identify the problem we should be solving, and how we could measure success;
- work together to find the smallest possible part of the feature we could release;
- test how it performs;
- and iterate.
Think of all the work combined before an end-user sees your new feature as an investment - because that is exactly what it is. The more we plan, design, and develop, the more we invest in the new feature. The more we invest in a new feature, the more we risk. If there is even a small chance that the feature won't result in the business value we designed it for, our investment will be vain.
With the agile approach, we minimise the risk to the smallest possible investment at each iteration. If we find out after two or four weeks that our feature is not creating the business value we thought it would have, we save a lot of money, which we can invest in creating features that do create business value.
A couple of weeks after we released the feature, one of the dependencies changed, and we needed to start the planning process again.
This is an example where agile practices could have saved time and money, and the waterfall methodology failed to deliver the right solution.
The second example
On a different project with the same client, we were given five days to solve a problem: record details of complaint calls. We were not given designs, there was no plan on how the solution would work, just the problem to be solved.
We chose to use existing frameworks for both the architecture, and the look-and-feel of the new tool. These choices allowed us to focus on the business logic of the application. We delivered a simple version within the week. This application has been live for several years, and new features were added to it in small iterations. Complaints are being tracked and followed up on. We created value with our client.
This was an agile success. Our client was happy, they realised a large business value return on their initial small investment. As an added bonus, developers were also happy, because they were allowed to do what was needed, no more, no less.
Simplicity, measuring and testing
By making the decision of following agile practices when it comes to software development, you are making the choice to maximise the amount of work not done.
Why? You have limited resources, and you want to add business value. You might end up using your resources to develop something that turns out to generate less business value than you expected. The simpler the change you make at any one time, the smaller your risk of wasting your budget on something ultimately unimportant.
The best way to test what your customers need is to get feedback from real users. First, define the business value you are expecting to gain from a new feature. What will be the benefit for you and your customers? Then, come up with a way you can measure this value. Your entire team should be aware of both the proposed business value, and the way it will be measured, so they can cooperate to achieve the goal.
You are now thinking like an investor who wants to maximise the return on investment. Your investment is the time your team puts into the development process, your return on investment is business value. If you can shift your team’s mindset to this way of thinking, you can create a breeding ground for quick and successful innovation.
Moving in small steps doesn’t mean that you cannot have complex features. It doesn’t even mean you cannot have large changes in one go. Some features only make sense when all their pieces are ready to go and that is fine, but the vast majority of features can be broken down to simpler features, allowing you to be more agile.
In summary
Reduce risk by embracing constant change. Instead of using your resources to plan and design rigid and brittle solutions, simplify. Define exactly how you will measure the business value you aim to create. Work in small steps to allow for change and response to the measurements.
These are the first steps away from waterfall methodology towards agile principles. More importantly, the steps towards more business value.
You see? It’s not scary. And if it still is, I’m always happy to chat with you about how to adopt agile practices step-by-step. Send me a message on LinkedIn.
Also, why not read (or re-read) the original Manifesto for Agile Software Development, and especially the often overlooked Agile Principles? They’re short and worth your time, I promise.