As I write this sat at my keyboard, I have The Ride of the Valkyries tune in my head with the image of helicopters coming towards me not full of soldiers from Vietnam but of Scrum Masters and self-proclaimed Agile Guru’s rising up in defence of a methodology. I pause nervous of what I am about to type and then I give a sigh of relief as I remember that I’ve seen this before.
It was called Six Sigma. Six Sigma was the answer to life, the universe, to everything and to say it was not was akin to signing your own death warrant. I know because I was a Black Belt who rose to its defence at the slightest signs of questioning. I came out of that helicopter gunship armed to the death, to defend my new amazing method but I noticed that for every victory I saw, I noticed that there were also battlefields strewn with the bodies of failed initiatives.
Phew, I think I got this article off to a great, happy and cheerful start. I was afraid it might sound a little negative for a moment. Anyway, onward with the cavalry charge. (That’s enough of the cheesy movie cliché’s for now.)
I’ll clarify by declaring that as well as a traditional Project Manager I’m also a Scrum-Master, Agile Coach, and I’ve previously used XP, TSP, CMMI and Six Sigma but I’m not a devout evangelist. I’m not an evangelist because I don’t think it’s the golden bullet, the lost ark of the covenant, nirvana or anything else. It’s a great tool, in the right places, at the right times and within the right teams and organisations. Agile, Like Six Sigma, is a great methodology but isn’t one that should be used in every situation.
To make this article easier to digest I’m going to adopt the perspective that all projects are Agile projects and then highlight situations where my argument is flawed and where Agile should not be used at this point in time.
1. Traditional hierarchies or command structures – Agile is about empowerment and not reporting lines. There is a job to do, iterations are to be delivered and sprints to be delivered. Traditional hierarchies or top-down management conflicts with the idea that there are three roles, Product Owner, Scrum Master and Team Member, that’s it, no line management, the team manages itself and its performance. This presents a cultural clash as the organisation isn’t geared towards an Agile delivery format and the desire to control and manage can drastically interfere with the process. If this is the case for you then your organisation is not yet ready to adopt Agile.
2. The Customer doesn’t want Agile Products – There are many reasons why a customer isn’t geared towards Agile delivery. It may be that they want to work with the traditional scope, schedule, budget approach where they agree what they will get and for how much. It’s about the end delivery only. They want to tell you what they want through a (at times questionable) set of requirements and then they want to go away and do other things whilst the supplier is building the product. We can of course argue that very few products are delivered to scope, schedule or budget however until the customer is on-board and ready to work with Agile, don’t do it. The clash will be unproductive as they will not commit to the Product Owner role.
3. It’s a major organisational change – Agile isn’t just for the product development teams, it has organisational wide impacts from sales, through product management and to customer support and all these teams need to be on-board and ready to work in an Agile framework. This requires training, restructuring, and a shift in what and how a company ultimately works. If the organisation is resistant to change, has team performance issues or a high turnover of staff then Agile may exacerbate these issues so the better approach may be to start with smaller steps as these issues are first addressed.
4. No one will invest in training – Without investing in training you will have an organisation that will at best stagger its way through delivery iterations, conflict and disarray will take hold and nothing meaningful will get delivered. Agile cannot be the actions of a well-meaning manager or team leader, it must be undertaken in a supportive environment where estimating, planning and team roles are clear. This takes an investment in training throughout the organisation and not just with developers, project managers or QA staff. If the team cannot be effectively trained before you start, don’t do it.
5. The team want requirements first – This is perhaps one of the most common mistakes, where some of the team insist that they can develop the requirements and then deliver them in an iterative manner, and it will work as planned. This is often seen in situations where one of the above limitations are at play or it’s seen as an IT only approach in order to accommodate the rest of the organisation’s reluctance. An example I’ve seen many times is that of a ‘trial’ run where a team is attempting persuade or demonstrate that Agile is the answer without the involvement of any external players.
6. People just aren’t interested – Yep, it happens and quite frequently. The organisation may have a history of following the more traditional waterfall approach and are quite happy with the results. The current approach is familiar, comfortable, it works in the organisation, scope, schedule or budget variations are unusual and no one sees the value in stepping away from the current model. Implementing Agile may be met with passive resistance, staff turnover, confusion or general apathy and will likely turn a performing team into a non-performing team. If it’s not broken, don’t fix it.
7. It’s yet another change, hang on, another is coming – This is a real risk and not one to be ignored. Six Sigma is a prime example of this. It came along, was sold as the golden bullet and everything changed, then we have reorganisations, lean, SPC and Agile. The volume of change can be seen to be high by some and not an evolution in an organisation’s growth patterns. Agile itself is facing a head-on challenge with Devops taking the attention away. Whilst they can and should work alongside each other, yet another change in the eyes of the delivery teams can be de-motivational. Let one change bed in, become the ‘norm’ and then look at where to go next. Don’t overlap two or more approaches as apathy over too much change will set in.
8. When quality is lost to delivery – Agile if managed loosely can result in a metrics set where success is managed on building something and delivering it. Sounds reasonable doesn’t it? No, not if delivery of a story matters more than the quality of the deliverable. If we deliver poor quality stories, we add to the product backlog to the point where whole sprints become focused on fixes and not on new functionality. If quality is already an issue, then Agile may possibly make things worse. It’s better to focus on the quality issue first before implementing Agile.
9. When staff turnover is high – Some organisations suffer a high level if churn for several at times, unknown reasons. It may be lack of management support, unattached to, or the lack of product vision, cultural or career objectives are misaligned, or let’s face it, sometimes the management is just weak. A high level of turnover can create lots of challenges for a team due to missing cohesion, new members lacking Agile experience or product knowledge, the list goes on. If you have a high level of churn, then implementing Agile may not be right until this stabilises.
For all the above items I am absolutely certain that there are some Agile gurus who will argue how Agile is the best fix for these problems, they may be right. In some circumstances Agile is a great fix but the point of this article is that Agile, whilst a good solution, is not the solution for everything. Agile is as much a cultural shift as it is a procedural or product build methodology. One without the other can result in a mess of confusion, poor quality, missed customer deliverables or de-motivated teams. Be careful, make sure that it’s approached properly, that the foundations that Agile aims to build upon are right
I can hear the helicopters circling ahead, the gurus are coming in for the attack but there’s no need. You see, this isn’t a combat situation. The goal is to make sure that we use the right methods at the right point in time and to share that there are times when Agile is not the ideal solution. I’m not advocating that we ignore Agile, far from it, I want to see it succeed when it is implemented. Instead of having The Ride of the Valkyries as the theme tune for this article, I’m going to advocate a different tune, Tina Turner’s Simply the Best. By cleverly picking what we use from our arsenal and when to use it, we can deliver the best solution for our customers.
Hopefully if you’ve made it this far into the article, we’re pretty much at the end, you might have some insights into how you tackled the issues above or where you suffered from not considering them. If so, please share your observations, please don’t just tell me I’m wrong without offering a why and what to do instead, you’ve of missed the point of the article if you do. It’s about opening debate and sharing experiences so that we continue to improve.
Thanks for reading.