This is the tenth and final post in a series dealing with the impediments raised in “Agile Antipatterns Are Easy to Spot, Hard to Change”. The tenth antipattern discussed in the original post is…
10. Believing that agile is strictly a software development issue, not a business one
It’s usually the software development team that decides to try an agile approach like Scrum, Kanban, XP or Lean. On the surface, these approaches seem easy to learn and use — daily stand-ups, short cycles, frequent deliveries — with some adaptation, the development team can rock!
And so it begins — the agile highway to project failure.
Let’s start by examining what we mean by ‘team’. A group of software developers doesn’t constitute a complete agile development team. Firstly, software testing needs to be an integral part of the development effort. A small project may be able to minimize the focus on testing, particularly if the team consists of experienced developers. However, a large project will need people who know how to test and more importantly, how to automate the testing.
If you skimp on testing, those short cycles will result in an ever growing defect backlog and the team may not even be aware of it. Eventually, the defects will be discovered and the stress level will rocket into the stratosphere.
Another key element on an agile development team is active involvement by the business stakeholders usually represented by a Product Owner. The stakeholders are the ultimate decision-makers. They know what the software must do. They know what features are mission-critical versus those that are merely important.
If the business stakeholders are not fully engaged in the development process, those daily stand-ups will turn into mindless status updates. Eventually, everyone will grow tired of reporting useless information.
Lastly, what about the real people that will use the software on a regular basis? They need to be part of the team as well. The developers and stakeholders can deliver useful software but if it doesn’t meet the needs of real people, it will quickly turn into shelfware — if you’re lucky. If you’re not so lucky, all hell will break loose.
Real people need to try out the software on a regular basis to provide feedback on what they like and what they don’t. The earlier this feedback is delivered, the better the final outcome will be.
Software development groups can be agile internally. That is, they can meet daily, establish short cycles, and produce regular builds. I strongly encourage that behavior. However, the only way to fully leverage the Agile Manifesto is to engage every group that will define, develop, build, market, sell, package or use the software.
A software development team can make itself agile but only a complete team can make the business agile. Which route will your company follow?