There are some tell-tale signs that an organization is not ready to be agile. There may be lots of discussion about Scrum, Kanban, XP, Lean or some other agile development variation but the organizational commitment is lacking.
Adopting an agile approach to software development is not easy or quick. Doing so while protecting and preserving the current environment and culture is a recipe for stagnation. Don’t even think about it.
If you see any of the ten antipatterns that follow, you’re in trouble.
- Protecting the organizational structure over the team structure
- Preserving the command and control hierarchy rather than letting the team self-organize
- Insisting that every decision be documented in writing
- Adherence to strict feature-set goals per iteration even if extra time is needed
- Expecting the software to be built better, faster AND cheaper
- Postponing refactoring until later, usually after a release
- Cramming as much as possible into every iteration to ensure that the team is kept busy
- Unwillingness to invest in training and coaching
- Emphasizing process metrics over actual project outcomes
- Believing that agile is strictly a software development issue, not a business one
In a series of posts, I’ll offer suggestions for dealing with all these impediments, starting with the first three antipatterns on the list.
1. Protecting the organizational structure over the team structure
Agile teams should include all the skills needed to build and deliver the software. That typically includes experts in the business domain, user experience, software design, software construction, software testing and system packaging. Outside experts can be brought in to help but the challenge is often one of timing. The experts may not be available when the team needs them and that wrecks havoc with project timing. For that reason, the use of experts outside the team is discouraged.
While many managers will agree on the need for multi-disciplined teams in principle, they insist on maintaining administrative control over their people. So for example, the test engineers work on the project team but they must report status to their manager. They are also held accountable for following corporate procedures and reporting standard corporate metrics.
This means that team members must serve two masters. Administratively, they report to an organizational structure. Project-wise, they report to the team (including the Scrum Master and the Product Owner on a Scrum project). This can create an awkward situation and place team members under stress.
Comments