When Agile, isn't agile
In today’s article, we talk about the common pitfalls that teams make when using an agile framework such as Scrum or Kanban, and what to do about it.
Today what' we’re going to be talking about is when agile, isn’t agile.
If you’ve been in the industry a while, you’ll have probably heard phrases like
‘That’s not Scrum’
‘We’re being Agile’
‘That’s not Agile’
*whispers* Like it really bloody matters.
Okay, well it matters a bit, but often there ends up being a lot of talk about the process on how to do something, and not enough of the actual doing.
And you end up in a bit of a pickle where the process stops progress.
In today’s article, we talk about the common pitfalls that teams make when using an agile framework such as Scrum or Kanban, and what to do about it.
That’s not agile
If we go back to the point I made above, this is a common argument used by people who take the agile manifesto and use it to fit their agenda.
The use phrases like:
Working software over comprehensive documentation - as a reason to not do documentation at all
Responding to change over following a plan - as a reason to never have a plan in the first place.
This just fundamentally isn’t true and is a bad justification.
Documentation, plans, process and tools are still needed, it’s important to write enough that you can keep them maintained and up to date.
It doesn’t mean you should neglect them.
It doesn’t mean you should have no plan or documentation at all.
However, we should should be aiming to deliver value continuously.
Wagile
A common sight to see, a mixture between waterfall and agile.
Typically this happens when working with companies that are used the waterfall methodology, but want their teams to work in an agile way.
Examples of this are Government and NHS contracts, where you would typically bid for them and agree to deliver the requirements in a tender.
The reality of this type of work is that teams need to deliver at least what is in the contacts, and try to reduce scope creep, unless agreed with the companies that they’re working with.
I have often heard complaints from teams over the years complaining about how this isn’t truly agile, and they’re right, it’s not.
But again does it really matter?
It’s what the business has contractually agreed to. Suck it up buttercup.
It doesn’t meant that you can’t deliver the work in an iterative and continuous way.
The benefit of still working in this way means that you don’t get to the end of a project and find you can’t deploy it, you also make sure that it’s been tested throughout delivery.
Basically, continuous delivery and communication still allows you gain feedback quickly and ensure you’re delivering what has been agreed.
Metrics
Facilitators of the team can sometimes focus too much on trying to get the team to produce metrics over value.
Or they end up wanting the metrics to be produced in a certain way.
Typically metrics should be to facilitate the team delivery and capacity planning and forecast effort.
But forcing a team to estimate work in a way the facilitator prefers rather than the team prefer is a symptom that somethings gone wrong.
It’s hard to pinpoint what exactly, but it could be one of the following things:
It could be that the facilitator just prefers these metrics.
It could be the business is convinced they need these metrics.
It could be the facilitator doesn’t have the ability to translate the teams preferred way into a way the business needs.
It could be that the team are unreliable and any metrics they give aren’t accurate.
Usually when the team are being forced to do something like this, there’s likely a problem with the teams health, or there’s a communication issue between the team and rest of the business.
Focusing too much on the process
When facilitators of a team have become very familiar with following a particular process, there can be a resistant to change.
And this can hinder the teams ability to adjust the process to fit their natural flow of work.
For example, they may be used to working in Scrum, or Waterfall, and because they’re focused so much on the theory of that, they don’t know how to deviate when needed.
Does it really matter how you deliver it?
Yes and no.
These frameworks are designed to facilitate you, and it should facilitate the flow of work. We should be able to adapt.
If your team have frequent changes in priority, a Kanban approach works well.
If you’re team are delivering product features, then Scrum or Kanban work well.
If you’re team are delivering a previously delivered project for a new customer, which is very common with implementation teams both Scrum and Waterfall (Wagile) can work.
A product and the various teams that work on the product will typically go through different stages throughout the products lifecycle, and the teams need to be able to adapt to that.
Business Value
Ultimately, it’s all about the business value. If you’re using an agile framework and it’s getting in the way of that, then you need to do something about it.
I will end on this, the teams’ priorities should be fed from the business.
If your business is telling you that a new delivery is more important than BAU defect fixes and you only have one team to do this, then the business needs to support that decision and make sure that the deliveries are prioritised effectively.
If the business constantly makes the decision to override the communicated priorities, then what they’re actually saying is that the priority is different, or they can’t decide on the priority.
If this happens frequently, the leadership probably needs support to identify and define their priorities.
Until they get to a point where they are clear what their priorities are, chaos will continue to ensue.
This requires the support from the rest of the business by providing the appropriate data for them to make informed decisions.
And that’s all from me today!
If you liked this article, please give it a like, restack and subscribe, and don’t forget to check out my YouTube video:
Articles I liked this week:
In some organization which have some compliance requirements due to certification (e.g. ISO27001, etc.) able to be process-compliant and getting stuff done need to be accomplished at the same time, isn't that the case? So work with what makes sense applies.
There will always be people who try to interpret some practice the way they want
- Interactions over documentation -> No docs!
- Bias for action -> Do things without thinking!
Much better to focus on the end goal, not on being compliant with a process.