The obvious purpose for an agile process tool is to help the team follow the process. This isn't enough, though. There must be a higher purpose, but what is it? This article gives you some ideas.
Almost every non-trivial agile software development project uses one or another agile process tool. Microsoft's Azure DevOps Services (ex. VSTS), Azure DevOps Server (ex. TFS), or Atlassian's Jira are some good examples.
On the surface, the purpose of these is to help the team follow its development process. But is that the real purpose, or is it just the means for fulfilling a higher purpose?
Since most agile developers use these products on a daily basis, it should be worthwhile to know. What is it these products should do for me, and how well are they doing it? We decided to have a look into it.
What should an agile process tool do for you?
What do vendors have to say about it? Sadly, most vendors only list such features that support the superficial idea mentioned above. Microsoft is an exception. An Azure DevOps site has this approach to the idea:
"Plan smarter, collaborate better and ship faster with a set of modern dev services."
This statement is different. It gives as much as three reasons for following the process. It promises that, if you take the tool's help to follow the process, you'll ...
- ... be able to plan smarter,
- ... collaborate better,
- ... and ship faster.
The last item on the list gives even a business reason for doing it. You'll be able to ship faster, which should make your customer happier. Provided that you ship a product that the customer likes. One that meets his or her reasons for the investment.
Shipping faster has not much value if you ship the wrong product. A product that doesn't do what it's supposed to do. Or a product with a lot of bugs in it. Or one that isn't easy to use the way users want to us it. This raises another question. Is it possible that an agile process tool could help us with that as well?
To answer that question, we must first ask ourseves this: What is planning? Is it just planning the process? The actions to take? When to take them? In what order to take them? Who should be responsible for them? Or is it also to make sure the product will do what the customer wants it to do?
We believe it MUST be the latter, and we know that you agree with us on that. Someone is paying for having the product developed. And there's a business reason for that investment. An investment that the investor expects to pay off in business results.
This takes us to the collaborate better argument from the Azure DevOps web site cited above. Planning for a better product requires efficient collaboration with business stakeholders. So that should be another purpose of agile process tools. Helping you with that.
The customer agrees! Going from waterfall to agile processes has been wonderful. It has been so good that today, almost every modern development project is agile. But there has been a backside as well. Architecture was important in waterfall processes, but is less so in agile processes. Well thought-out business-driven architecture is the key to development of business-aligned software. That, in turn, is the key to long-term benefits of investments in software.
Customers has felt this and reacted. As a group, they have reacted so much that they have developed the Business Agility Manifesto. We want to cite some important statements in that manifesto. Understanding these quotes can be helpful for us in software development. That's because they represent a high-level view of the paying customer:
"Business agility is the ability of an organisation to sense changes internally or externally and respond accordingly in order to deliver value to its customers."
"Developing software faster is not sufficient, in and of itself, for survival and growth, because once operational, such software is likely to continuously and rapidly change with unintended consequences."
"This leads to a new conclusion. The software developed must be adaptable to future changes to the business. It must be possible to rapidly change the software as needed, without unintended consequences. A good Agile Process Tool should help a good agile team with that."
"When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function. You want to isolate your modules from the complexities of the organization as a whole, and design your system such that each module is responsible (responds to) the needs of just that one business function."
Our conclusion is this: Our job is to make customers happy with what we deliver to them. The quotes above show that this is not just a short-term but much more a long-term issue. Business change more often and faster than ever. They will change even faster and even more often in the future. When their business activities change, they need their software to change with them. And fast! Fast adaption to business changes is important! It's even more important than fast delivery of the software's first version.
One enabler for this is improved collaboration with business stakeholders. Another is close software-to-business alignment. And these two stick together like glue. Our agile process tools should be able to help us with that. That should be the true purpose of these tools!
We have a lot to say in this area, and you should expect us to deliver on that promise soon. With further articles, and in other ways.
