Common pitfalls in the application of Agile - and how to avoid them
Seeing Agile done properly is an eye-opener. It changes your view of software projects in the same way that it is now hard to imagine having to use soap, water and hands to wash your clothes since the invention of the washing machine.
But self-titled "Agile" companies and software projects are all too often unsuccessful. For the new software engineer, there is a danger that this amazing tool for delivering successful software projects will therefore become poisoned in their eyes.
Perhaps the key issue is that Agile won’t fix your problems, it will just expose them. I dislike mirrors for exactly the same reason, it’s uncomfortable to see your flaws and blemishes presented back at you...
I would describe Agile as the process of working as a team, on small well-understood pieces of work, to get a deliverable piece of said work items complete, providing incremental business value. It's a set of guiding principles, where mastery and maturity comes in electing to use patterns and frameworks rather than following them blindly.
Work as a team, and try to understand what you are building before you build it. Don’t bite off more than you can chew. Make sure that changes in direction are low cost by frequently examining what you are doing and what you are building. If all that sounds like common sense, that’s because that is all that Agile should be.
Stand ups are for the team
The words to strike fear into a software engineer's heart:
Yesterday I did… Today I am doing…
As is common knowledge, everyone’s favourite thing is to be forced to speak in front of a semi-circle of other people, who stare at them in silence, waiting their turn. The best part is knowing that each individual person in the group has heard roughly zero percent of what you have just said, being far too preoccupied with rehearsing what they are about to say.
Evil Project Manager glares at you menacingly, and lightning crackles overhead.
How are you still working on this story, when we only sized it at three oranges and a papaya?
I’m exaggerating slightly, but this is not an unfamiliar situation, especially if you hate talking in front of other people.
If someone is making you say the “yesterday I did, today I am doing” format, don’t feel bad for how it makes you feel. That isn’t Agile, it’s a KPI. You aren’t working in a software company, you are working in a call centre, where you have to make x number of sales a day, with no wider understanding of context. If you are making your team do this, just know that they resent you for it and make faces behind your back.
The mistake being made here is simple. The “yesterday, today” format is for ensuring that everyone is kept as busy as they possibly can be, or for pitting one team member against another. But the focus should be on the work in the sprint, not on the individual.
Here’s a different way of doing it:
Next up, the saffron submersible feature. I see it’s still in development. Paul, how’s it going?
Paul: Actually I’ve hit some issues, I think this is going to be more work than we anticipated.
I see, maybe someone else on the team can help by pairing with you on it? John? Mind helping out?
Discussion. Problem. Solution. The Beatles are doing Agile properly...
Maybe this process exposes that you aren’t spending enough time refining your stories, or your definition of ready is lacking. Maybe it exposes that a spike (time-boxed exploratory piece of work) should have been done to fully understand the problem. Maybe it exposes that the estimates are too optimistic. Whatever it is, it’s something to discuss at retro (the retrospective exercise at the end of a sprint where you examine what went right/wrong).
The word 'exposes' here, is the key part. Agile assumes that you are working in a non-ego driven environment, where everyone cares about getting the work done, and is happy to help others solve their problems. It assumes that the team has the authority and autonomy to identify what is getting in the way, and fix the problems.
The challenge of refinement
If you have picked up a feature to work on, and the information on the ticket is lacking, there are problems earlier in the chain. I’m sure plenty of engineers will have some experience of being asked to write something along the lines of:
Build a thing that sort of does this
Followed by an email halfway through the work that says.
Wait no, except in this case where it does that.
These requirements should have been ironed out in advance, and good luck to the tester who wasn’t in on the email chain. Part of the problem is that people aren't great at describing what they want (ask any professional in the art industry), and people also aren't great at asking people to describe what they want.
Struggling to describe what you want isn’t a personal character flaw. If you are a new product owner, don’t feel bad that your expertise in your field doesn’t immediately translate into concrete requirements, it takes a lot of practice.
See my article on BDD (Behaviour Driven Development) for one potential tool to use here, or just pick up any book on BDD and example mapping. Failing that, just draw pictures of what is needed. Anything short of interpretive dance that provides unambiguous, traceable meaning, and prompts the right questions, is useful.
The Analyst profession in software engineering is essentially the professional application of having useful conversations, which is harder than it seems. This is great, but unless refinement can meaningfully answer questions, it’s just introducing a new layer to blame in the chain when the same problems happen. All parties involved need a willingness to sit and understand the problem, a framework to capture the understanding, and to ask the right questions.
Even worse, sometimes refinement can just be business and technical people in a room together, incorrectly thinking they are in agreement with each other. This is just as bad as not having a conversation at all, there’s a reason why the famous ‘Three Amigos’ isn’t ‘Two Amigos’.
Key Point: If you are a business person, be aware that software engineers in agreement with each other may simply mean that one understands what the other is saying, not that they understand what you want.
A simple solution here is to widen the types of people in the room. There should be at minimum a person who speaks business, a person who speaks tech, and a QA/tester/whoever is going to be asked to eventually verify that the two spoken languages match up.
These people should be able to disagree amicably. Refinements should feel like a friendly argument for any non-trivial piece of work. BDD is excellent here because it provides a common language that all three parties can settle their disagreements with.
Are you having fun yet?
The above isn’t always going to work. Part of the nature of Agile is accepting that things go wrong, that software is hard, and that we are all to some degree feeling our way in the dark. If it feels like Agile is just a never-ending set of self-doubting “are we doing this right?” meetings, that’s because managing a project is difficult. (Waterfall wasn’t better in this regard, it was just the equivalent of a married couple bottling up their feelings until one of them poisons the scrambled eggs…)
Without a framework to highlight and fix problems, a negative exercise can emerge where teams or individuals blame each other.
It’s the business’s fault for not explaining what they wanted
It’s the software engineer’s fault for misunderstanding what was asked for
It’s the tester’s fault for letting that bug creep through
This is all reactive, and won’t help. Sit in a room, discuss what you thought went wrong in recent history, i.e. the last sprint. Then propose what could be improved. Listen to what people are saying, and be open to the idea of changing the way you work.
Maybe the business didn’t understand just how complex what they were asking for was to deliver.
Maybe the engineers are too enthusiastic to build cool stuff, and aren’t thinking about building a tightly focused MVP any more. Of course, I myself have never been guilty of this...
Maybe the testers are struggling to understand what was actually asked for amid the warring factions and chaos.
Speak your mind, say what is bothering you, and say what would help. Do something nice together as a team to celebrate a successful sprint. We are lucky to work in what is fundamentally a fun profession. Agile should be making you say that yesterday you enjoyed your day at work, and today you are having a blast.