Seven “early” symptoms of a slipping agile project
.. and how to address them!
I just love walking past a newly-formed agile team! Everyone is charged up, have nicknames and avatars, hopeful of creating the best product in the world! There’s cards and sharpies everywhere, the walls resemble an office setting out of a hollywood movie… and well the people dress cool and just look great!
If you’re smiling, you’ve done the same… as have I. No matter what your job role or function is- agile projects are, indeed, sheer fun to be part of. The positive attitude and self-organising nature of team members are huge levers to success in Agile projects.
However more often than not, we’ve all come across a story where “Agile didn’t work for that project”. This is the time where doubts creep in, and some start suggesting that more “serious” projects (psst psst) should stay away from Agile! This happened to me when a program manager, hired to rescue a troubled project, rechristened the delivery model from “Agile” to “structured iterative”.
He left for a nicer gig before that name change could work its magic.
So in the spirit of keeping the Agile spirit alive in our teams, here are seven early symptoms of a project either about to, or already slipping on its intended goals. Of course, these are not meant to be the only ones, but Mr. Pareto already solved that for us once and for all.
Symptom # 1. A lot of ‘work’ happening but not enough story or task cards!
A good check is to verify if all team members have a couple of task cards allocated to them in the Sprint, or at the top of the product backlog (this of course assumes that there is a well-refined product backlog). Back to basics — the reason of representing cards is to attain a 360-degree view and facilitate self-organising… even if individuals know exactly what they’ve got to do! Chances are if the scrum master is running Sprint planning, backlog refinement and daily scrums well, this would already be taken care of. A reverse symptom is cards either not moving quick enough, which is easily trackable through tracking the creation and expected completion dates against today.
Albeit simple to address and common Agile sense, the importance of this symptom being addressed and being guarded against continuously cannot be overstated.
Symptom #2. “Estimation? I will just let you know when it’s ready”!
Before saying anything else, I will say that there has to be a sensitive balance between developers having freedom and the scrum master having an empirical view of the size of work. So while scrum master Emma chasing developer Sandra since she’s running ‘late’ is a no go (that’s also why story points work better than expected durations), its also important for Sandra to estimate story points on her work, and maintain a forward-looking view of her effort on the Sprint — this will help her keep a constant eye out for impediments, and issue an early warning to the team if her work seems to be slowing down for any reason(s).
Just the primary discipline of measuring one’s own daily progress against the overall quantum of work will build a strong risk-management foundation. So if you see a wall with stories or tasks without estimates, request an invitation to the backlog refinement meeting!
Symptom #3. “Product owner? Did you mean the ‘business’”?
We’ve all been taught to be customer-centric and stakeholder-sensitive in technology consulting or delivery. And while most Agile teams has an allocated product owner to them, I have been surprised to see the product owner still being treated as ‘business’ in some teams. An Agile team is a flat world, where each and every person is there to perform a specific function — no less. That applies equally to the product owner- whether they come from IT, business operations, marketing, or external partner relationships.
So what’s the big deal you ask?
It is critical for the product owner to not only provide decisions, but provide ongoing liaison with other support groups (SME, tech, ops), and work hand in hand with the team on a daily basis. So the role is much more involved and intensive than the traditional “signing off” business stakeholder. It’s important that both the team and the product owner understand, subscribe to, and practice this way of working.
Symptom #4. “I can’t work on my tasks today, I need to prepare for the exec demo”…
I’m going to sound tribal here… but we call them ‘wolves’. They sneak in unnoticed and steal away our calves and kids. So what I’m saying is — an Agile team should be free from external distractions — whether in the form of requests, mandates, or larger than life stakeholders themselves.
I recall a brilliant Agile team in a startup I was a part of recently, being continually inundated with ‘special requests’ from none other than the CEO of a client — we let it slip through as a ‘one-off’, and that was the mistake! Exception became the norm. I failed to guard my scrum team from wolves and lost some star performers from the company in the process. Guilty as charged.
While Agile is fun, sexy and productive- it is outcome-focused, super intensive and pins accountability on to individuals. So any distractions — no matter how critical they might appear to be — are not helping your team in their professional and personal pursuit of doing a good job. The best scrum master in the world will be the St. Bernard who will keep the foxes and wolves away from his flock at all times.
Symptom #5. “Sprint goals? We’re a well-oiled team and we already know what to do”!
We talked of protecting them, now here’s one that will challenge teams! Too many Sprints in the Agile world have started without a clearly defined, and a team-agreed Sprint goal (I’ve done it, I’m sure you have too). During one of my visits to one of the largest Internet-based platform businesses in Australia, the CIO shared with me that they’ve never ever planned beyond three months as an IT organization! How powerful is that! It goes to show how short term goals help teams keep track of longer term roadmaps. In my mind, Sprint goals work in a similar manner. Each team member may have their plan of attack towards work — but that would not help the team succeed unless a more secular and all-inclusive Sprint goal is considered, debated, and agreed upon by all.
I like to randomly ask team members as to what is the current Sprint goal they are delivering to- and that is a five second pulse check that would help me instantly predict the outcome at the end of the Sprint!
Symptom #6. “Of course, we test. We’ve got more testers than developers”!
Before you frown, I have been a tester myself. And I think it is one of the most important tech roles. But is a large number of testers in an Agile team a problem?
Sadly, it is.
Not because it disturbs a social balance, but simply because this is a leading indicator of the absence of a couple of important disciplines in the team — lack of automation, (hence) possible lack of continuous integration, (hence) more time being spent on repeatable activities than shippable work, (hence) lags in velocity.
There is no silver bullet solution around quality on projects (Agile or otherwise), but it is common knowledge that successful Agile delivery relies heavily on automated unit and integration tests. In a desperate attempt to either retain solution IP or execute a huge test suite in a matter of 1–2 days, many Agile teams have had to maintain a pool of functional testers. I hope you’re not interpreting this as there being no need of manual testers- of course there is! But QA runs and continuous integration across environments is a continual and repeating process- and hence automation is a key accompaniment to manual functional validation.
Symptom #7.” Oh that project? They’re the company’s ill-funded cowboys”!
No, I didn’t make that phrase up. Once upon a time, I was in the perfect Agile team, that was creating the most futuristic solution that would spearhead the company as a market leader across Australia. We spent millions, hired the best people, and delivered some truly ground-breaking results. However, we had the reputation of the phrase above! What was most shocking is that the person who said this was one of the members on the program steering committee.
So what went wrong?
We just did not manage change properly!
The board was pouring millions on us when other departments of the company were either being stalled on investment or being shredded in size. Worse still, while we managed upwards really well, we sucked in engaging our peers in other departments whose teams were being impacted by the changes we were creating! Thankfully, an angel (change manager) descended from the heavens above and rescued us. Big time. My faith in enterprise change solidified million-fold.
The Agile journey is a pot of hits and misses like any other undertaking — the only exception being that it does it fast! This means that every such initiative needs to be strongly change managed, communicated upon, user trainings should be planned in consultation with the end users or customer representatives- and most importantly- the product owner and program manager need to articulate the story clearly to everyone touched by the change, clearly communicating as to what everyone can expect to change in their lives and what would the project/ program do to assist them in that journey of change.
These seven symptoms are in no way suggest that Agile doesn’t work, or is any more risk prone to any other delivery model. A delivery model simply serves project goals in terms of schedule, scope cost and quality — and Agile is no different. However, successful Agile delivery depends on how well some of these areas are addressed, and perhaps most important of all, how motivated is the team to smash it out of the park!
What has been your experience with these seven symptoms? Do you have any more symptoms that you protect your projects from? Do you think these symptoms could apply equally to Waterfall projects as well? Please share your stories and experiences so that we all can benefit from them, and keep the spirit alive in our teams and our organisations!
