Agile is not a silver bullet – despite what many claim. Agile doesn’t magically improve delivery, but it can bring significant improvements if approached in the right way. Let’s take a look at how not to introduce Agile into your organisation.
Beware of Waterfall in Agile clothing
I’ve found on many occasions that when a business issues a diktat that they will now implement Agile, it can be difficult for them to make the conceptual shift. Sometimes they’ll (unintentionally) keep their existing structure and processes and simply go through a renaming exercise instead. However, as we well know:
- The Scrum Master is not a project manager
- The Scrum Team are not all developers
- The Product Owner should not be a business analyst
So, if you have simply filled new Agile roles with the nearest equivalent traditional job title, there’s a strong chance you haven’t changed much about the way you work – instead you have simply renamed your current methodology to sound more “Agile”.
You’ll also see projects become “epics”, requirements may become “stories”, meetings are suddenly “stand-ups” and planning is now called “grooming” – but has any of this your improved your output?
Evangelists cause issues
Once a decision has been made to become “Agile”, an early step embarked upon for many businesses will be to recruit an Agile specialist. There are a two important issues with this approach:
First, these specialists are often aligned to one specific methodology (we’ll discuss that later). At worst, they will apply it dogmatically, without the pragmatism required to effect change in some larger or more traditional organisations.
Second, the criteria for recruiting these specialists is often that they have a relevant Agile certification, as that is the only way they have of assessing a candidate’s Agile credentials. For any methodology to be successful, sufficient practical experience is required. This doesn’t come from books or (one-day) courses.
Don’t default to Scrum
Scrum is Agile, but Agile is not Scrum. Scrum isn’t the only Agile methodology in town (even as I often default to using Scrum terminology…), yet it’s often adopted without any consideration about what it actually provides and what limitations it may have.
Scrum may be the best-fit for your needs, but you should always perform some analysis based on the specific situation you’ll be working in. Furthermore, don’t fall into the environment / scalability trap. All too often, I’ve seen Scrum trialled isolation, with a small independent team, then it gets rolled out across a much larger organisation with several teams (and their complex dependencies) thinking that it will just work. It very often doesn’t.
Each software methodology has its pros and cons – what looks good in theory may not be as successful in the real world. Try some out.
Narrow scope limits change
The most common mistake when trying to become more Agile, is that changed practices are only applied to the technical phases (usually just build). Requirements are still gathered up front, then there is a design phase. After the now “Agile” build phase, a test and release phase follows and so on. This is a red flag that you’re actually using a sequential methodology (like Waterfall…) instead of an agile methodology.
This is a problem because you’re going to be severely limiting the potential benefits that can be realised by adopting a more Agile approach by constraining the scope of change in this way. As many businesses eventually discover, the build phase is often the least of their problems when it comes to successful project management.
Sometimes other phases are actually included in the “Agile” scope, but they will occur in an isolation fashion instead of collaboratively. The scope of a Sprint is dictated by the business and Scrum Master (in private), rather than agreed by the team.
Divorced responsibility
Another pseudo Agile anti-pattern is “pushing (problems) over the fence”. This will typically take the form of the business expecting the Agile team to deliver requirements that haven’t been articulated or even formed yet – and then not being involved in the activities designed to find them out.
Issuing requirements akin to “whatever it does now” also demonstrates a distinct lack of stakeholder engagement. The business needs to take responsibility for ensuring their team has a complete understanding of their expectations if that is what they hope to deliver. Collaboration is one of the most important aspects of Agile and can be the most difficult culture to change.
Setchu - Agile at Scale 