InterVenture Best Practises: If It Ain’t Simple, It Ain’t Agile
Writing software is amazingly simple when it comes to processes. Don’t let the complexity of the software itself sneak into the process of producing code. Understanding and modeling the domain, testing and packaging, all of those are one side of the coin. Managing the process is the other side.
Who is Managing Whom?
In our industry there are three poles, each lead by a mindset significantly different than the others. There are clients, management and development. They all gather their strengths to produce software that works. But their means are different. Clients specify requirements, development produces code, and managers mediate so that the working software is deployed.
And the devil hides in this last detail. Management is responsible to deliver software. Management is signing contracts and giving promises. Then management feels the desire to manage developers more directly and to see that all that was promised is delivered in due time.
That is the point where management can take too many responsibilities in own hands and actually cause damage to the end product.
Principles of Agile Development
Only a few of the most prominent elements have found their place in the Manifesto for Agile Software Development. And that is not the coincidence. Agile development promotes straightforward management model. Here are the principles:
- We value individuals and interactions over processes and tools.
- We value working software over comprehensive documentation.
- We value customer collaboration over contract negotiation.
- We value responding to change over following a plan.
That is all there is in it. No place for endless meetings, management reports, charts and pies, plans that span weeks or even months of development time. There is no room for managers who like strict progress following. Such practices distract development and their overall effect is that the product gets to production later.
Esther Derby, agile practitioner and speaker, recently gave a brief but well placed comment on the way agile development is managed in some companies. “Many managers in organizations with traditional functional hierarchies want the benefits of agile without disrupting the status quo. Not going to happen.”
We will conclude this article in the same spirit. While practicing agile development for years, we have become convinced that the company management should manage company, rather than to manage the way in which developers are writing code.