Agile has been around for a while now, and most companies have realized that agile development is indeed better than the traditional waterfall model as it provides a couple of benefits:
- The product is closer to the needs of the customer as he is involved in every step along the way.
- Less bugs are introduced as continuous integration guards over this, leading to a more reliable product that cost less to maintain.
- There is no large up-front cost.
- Because the product is build incrementally, the chance the project fails to deliver something of value is much smaller.
Despite this, I experience every day how a company wants to be ‘agile’, but is stuck with the idea that being agile is only a development thing.
Why do we believe that agile is limited to the development team in the first place? Well, we do call it agile development, don’t we. So it makes sense that the place for agile development is the development team. Yet, the development team is supported by the rest of the company during development, but since this is more implicit and hidden it is harder to notice.
What exactly are the effects of having an agile development team inside a non-agile company? There are two possibilities. Either you have a company that still believes in the old waterfall model or you have a company that has a wrong understanding of how agile works.
In the first case you end up with:
- Fixed price, fixed scope and fixed time projects.
- A development team that gets all the requirements in the beginning.
- Customers are not involved in the early releases.
In the other case you have problems such as:
- Customers asking changes all the time, and excepting all of them to be done.
- People don’t understand why something their request has to wait.
- People don’t understand why their fix/feature is not in the next release.
To meet these requirements, or handle the situation the agile practices of the development team are often cut short. They become hollow to meet the needs of the company.
- There is no time to create a lot of tests, as there are too many new features to deliver in a short amount of time.
- This leads to more bugs, annoyed people as things are breaking and more work for the development team.
- It is not possible to think things through due to a lack of time and a lack of information.
- There is a lot of scope creep. User stories are not declared clear enough, or more stories are added to the sprint.
- The definition of done is meaningless as not every sprint ends with an actual release, the sprints will resemble this.
How can we fix this? It takes a change of mind from everyone in the company. They need to know how the development team works, and what the consequences are of it. Both the advantages and disadvantages need to be communicated to them. Make them responsible for their own behaviour, if they request a feature for which they can not wait, there has to be consequences for them as the development team has to turn things around, and assign a good product manager to shield of the development team.