Google “agile software development” (and by the way, any company that gets their name turned into a universally-used verb has seriously ‘made it’) and you will find literally hundreds of thousands of articles and blogs telling you exactly how to be “truly” agile. Read a bunch of them and it is perfectly possible to get confused by it all. So many different opinions exist (and some are in this blog too) as to the ‘right’ way to run a stand-up or write user stories or improve your team’s velocity…. it is all too easy to conclude that there must be a right way if only you knew what it was. And why that advice doesn’t quite seem to fit the project you’re working on.
There are a lot of people out there – you may be one of them – who are struggling to make agile work the way the ‘experts’ say it should. And through a lot of reading, a bit of speaking to people – a number of whom work in the same company as me – and a lot of thinking about it, I can offer at least one good reason why this is so.
To quote Wikipedia:
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change
The underlying concept behind agile is built on two beliefs:
From this we can reasonably conclude that there is (at least) one essential ingredient that determines your ability to be agile, the degree of agility that can be achieved on your project. That ingredient? Active business involvement.
In an environment where you have someone from the business area/s affected who has the desire, authority and the knowledge to accurately represent the end-users and strongly influence the priorities and the direction the project takes, you can be very agile. In this environment you can write user stories that describe a discrete business need while omitting the detail of how that need should be fulfilled, in the knowledge that the Business Ambassador (Product Owner in Scrum) will be around to help evolve the solution through a series of iterative development cycles. There is a lot of exploration of requirements going on in each timebox. There is much less certainty about what will be developed until the last minute. But, in this environment, the right solution will evolve.
Now consider a situation in which you either have no Business Ambassador / Product Owner or that person is not always available. This is often because business representatives have ‘business as usual’ work to do as well, and there is a common perception that seconding someone to a project team for three, six, nine months will erode their business knowledge. In this situation, requirements definition and decisions on solution options and prioritisation are left to someone else. Someone less qualified to make such decisions. The development team are forced to get more detailed requirements up front and specify the solution a lot earlier and in more detail, because the business guys won’t always be around to discuss options and review the evolving solution with the developers and testers. The lifecycle becomes more specification-led, rather than exploration-led. It becomes more ‘iterative waterfall’. This is a natural reaction to the situation, and is not ‘wrong’.
The thing to remember, though, is not to get into this situation by accident.
It is important for the project manager to identify at a very early stage whether she can get sufficient active involvement from the right business people or not. Yes, do everything in your power to secure the right people to allow your team to be as agile as possible, but recognise that if that is not feasible, you have to plan accordingly.
Less active business involvement means you need to make at least the following changes:
See how this works? I am not saying you cannot be agile if you don’t have continuous active business involvement in your project team. I am saying your degree of agility is compromised. But plan accordingly. In some projects, multiple business areas are affected, and you may get total involvement from one of those areas and very little from others. If that is the case, I would advise doing some stakeholder management by working out, during the Foundations stage, how you plan to work with each business area; how much agility is possible with each and plan your requirements gathering and the development approaches accordingly.