As you may know most of my clients so far have been large Oil and Gas companies here in Calgary. A lot promote Agile as their methodology of choice, but is it really? Pretty much every interview you go to they ask about your Agile experience and tout their fast paced, dynamic environment. Unfortunately there is a lot of smoke and mirrors and when you actually hit the ground on your project and start working you realise that things are not really as advertised. Most times what you find is a very ceremonious process that is more concerned with producing various documents and appeasing people in certain roles than delivering working software.
I’ve been thinking about compiling a list of things that make delivery difficult in some of these organisations and here the top 5 that come to mind. Here are some of these issues. I though it would be funny-ish to have a “Top 10” like list but I’m starting to believe my kids when they tell my I’m just not that funny.
This is an older post I finally got around to publishing
Reason 5 - Planning waterfall style (or not planing at all)
A lot of the time I see things planned in excruciating detail - stories broken down in small crumbs and tasked out with development tasks and QA tasks, etc. Yet the meat of the stories is weak, with barely any acceptance criteria to speak of. Most of the focus is on the minute details of how we will do something and not the expected outcome.
At the other end of the spectrum is not planing at all because after all we are agile and don’t need to plan. This is equally bad. You need to have a fairly clear direction for your iterations with clear and well stated goals. The level of detail in the stories should be proportional to how close the story is to being played. If you’re going to play a story in the current iteration it should be pretty well fleshed out and if it’s still a few iterations away you should only have enough detail to support prioritising the back log and get some rough estimates.
Obsessive tracking of progress also doesn’t help. I’ve seen people try to track hours and points at the same and it’s never really clear how hours relate to points and vice versa.
My advice would be to keep things simple: focus on you deliverables and write acceptance criteria around that. If you can leverage tools to write some executable specifications for your stories that’s awesome! Track one thing - either hours or points - and focus more on expected outcomes than minute implementation details.
Reason 4 - silly terminology that is overly abstract
Using silly words like ‘impeded’ instead of blocked. This is part of a broader tendency to mellow down the language. I mean we don’t want to hurt anybody’s feelings or anything, right? And I’m not saying we should be rude to one another but we should certainly be comfortable articulating when things are not progressing as we want and assign some folks to deal with the various issues that arise during the iteration. If things really are blocked than call them that. If you’re worried about “the business” being offended at every turn that’s a smell. Perhaps the business is not that confortable with and Agile delivery model after all?
Reason 3 - not sharing responsibility for deliverables
A red flag is when your project manager uses words like you when talking about the team. When your boss starts to distance himself from the project outcome that’s usually not a great sign. Other team members begin disengage from for the project outcome and before you know it you have a huge morale problem on your hands. It should be clear to everyone a well functioning agile team succeeds or fails as a unit. Unfortunately in many so called agile environments I’ve been part of there isn’t an effective mechanism for giving feedback to the project manager and/or the business who are sort of above and/or excluded from the process. This is pretty tragic because they learn nothing and move on to the next project thinking they did everything right and the delivery team is responsible for the failure.
You have to make it clear that the team shares responsibility for success. And when I say team I mean everyone from DEVs to QAs and PMs as well SMEs and the rest of the business side. Find ways to make people accountable - and not just accountable but empowered and engaged. Everyone needs to have skin in the game.
Reason 2 - segregating team members by role
You know you have a big problem when your BA, QA and SME are not at the scrum and/or retrospectives. This is not great because you won’t be able to address any issues that go beyond the development team quickly and effectively. Any problems with requirements, testing or signoff will be difficult to sort out effectively if the stakeholders are not involved in these discussions. So you’ll hone your development team to be highly effective - which incidentally is the relatively easy part - and they’ll sit there frustrated because there are other gaps in your process that are not being addressed.
You should focus on building cross functional teams where everyone feels involved and responsible for the project outcome. There will be better opportunities this way to address issues closer to the source and reduce waste. You will get a happier team because the lines of communication are open and BAs can talk to DEVs and QAs and vice versa.
Number one reason - whitewashing the retrospective
We’ve all been part of retrospectives where there is a facilitator and they think they’re job is to filter what’s being said and not record the more painful truths that sometimes emerge in these meetings. Various people’s opinions and feedback are downplayed or plainly disregarded. It’s true that sometimes people are being a bit pessimistinc and overly critical and I sometimes make that mistake myself. It’s important to recognise the teams successes but at the same time we have to be careful not to ignore issues just because they are inconvenient.
A classic example is around “business” unavailability to meeet for requirements ghathering, perform acceptance testing or sign off on stories. Another common one is the in-house framework somebody developed is now a serious liability and doesn’t scale.
Ignoring these problems will only turn them into chronic issues down the line and your team will have to pick up more slack as the project progresses. You have to deal with these things or you have a really good chance of turning your project into a death march.