My last couple of posts ‘That’s not Agile’ (find at https://www.shibusa.com.au/thats-not-agile/ ) and ‘Agile is Sh!te’ (find at https://www.shibusa.com.au/agile-is-shite/ ) have focussed on state of the nation with respect the movement and some broader observations about some of the challenges in way Agile is being adopted, and a few pointers along the way for successful adoption.
Today I’m focussing on identifying what good Agile looks like in practice, and conversely what the warning signs are for poor Agile implementations.
I don’t care if you are a hard core Software TDD, XP, Devops blah blah blah team, or if you are a business team using Agile to drive cultural change. Agile is a culture and a way of working. My comments here apply to all applications of Agile across the board.
An anecdote: Trinkets v Culture
A very highly regarded coach once looked at a project in my portfolio (I was the accountable IT Exec) and reported back to the senior leadership team that a it was an exemplar of Agile. As a strong Agile advocate, I couldn’t have been prouder. Three months later I had to restart the project. The problem was that all the visual cues were there, walls covered in postits and Story Cards, Standups, Showcases, all the Agile ‘trinkets’. So the mechanisms were there for open conversation, early risk identification and rapid delivery. The problem was that the conversations were all wrong “come on guys, we gotta hit the date”, and there were massive conflicts within the team on the solution. None of these issues and risks (known to all and sundry within the team as is often the case) were getting airplay, and were therefore left unresolved. It was a toxic culture, lots of talking behind the hand outside of the project room.
After a number of experiences like this and others like: using coaches who weren’t suited to business applications of Agile (and we were charting new territory back in 2008) experiments that failed, pragmatic tweaking and application of the practices, resets and some very scary moments…. we got a huge program of work done and we all learned a bit about broad implementation of Agile. I never lost faith in the inherently sensible principles of Agile, and in the end we got pretty good at picking when we had it right, and when we didn’t.
What other people said on the Journey
I had people saying broken projects were fantastic based on trinkets, I had people say ‘that project wasn’t Agile’ and yet it had integrated tech and business people, great daily conversation, visualisation: ultimately an integrated agile problem solving machine… not Agile???
So just be careful who you listen to. And here are some ways to assess whether you are really doing Agile well.
The Agile Engine room: Standup
The most important litmus test for effective Agile is team cohesion and effectiveness, and Standup is the canary in the coalmine.
Firstly are they happening regularly? OK good tick.
Lean into Standups, especially at the start of a project/program. Once you have seen a few working well, you’ll know exactly what to look for. A high performing Agile team will be beautiful to watch. It’s like the Customers and the Delivery Team are performing a fast Tango. Totally integrated and moving so fast and seamlessly that you can’t tell which is which. Progress discussion is sharp and to the point, everyone knows what they are doing for the iteration. Issues, great and small are raised comfortably and dealt with naturally and effectively. Collaboration across all elements of customer and delivery teams is natural and easy.
But Standups with new teams, particularly those with people who have no prior experience are not going to start there. Some of the Agile practices are not intuitive, and can feel quite uncomfortable for the uninitiated.
It’s a Tango, but its ugly. Feet get plonked down in the allocated footmarks painted on the floor, but it’s not fluid or natural. Some toes get squashed. At the start that’s to be expected.
However, if you lean in after a month (assuming daily Standups) and you see all or any of these:
. Stilted performance (Exec is here so lets be on our best Agile behaviour)
. Resistant defensive body language
. Waffling story card updates
. Issues being allowed to go through to the keeper
. Low Energy
. Poor personal accountability
. Poor team accountability
. Poor focus and direction
. No sense of velocity
. Consistently inconsistent attendance
. Customer nowhere to be found, or worse, there under sufference
. Team members without the capability, competence or engagement to do what they are being asked to do
. No high level flight plan with measurable, clearly stated end and intermediate objectives (Projects and Programs)
Houston…..
If these things are present, I don’t care how many cards you have on the wall, how pretty it looks, how many state of the art development practices you have, automation tools you use, or Agile assessments you’ve passed with flying colours….. you are heading for catastrophe.
The right conversations aren’t happening, which means some of the great aspects of Agile done well are missing: early issue identification and management, focus and velocity. And if the project is being reported green, you have what we used to call a watermelon: green on the outside red on the inside.
As I gained more experience (and lost a few limbs) I used to make it my practice to attend all Standups at the start of a project until I could sense the right chemical reactions were starting to occur. The transparency of Standup also gave me an insight into the team, and to assess whether it was resourced with the right mix of people with the right capabilities.
Conversely, if the team was crackling appropriately, and you add in:
1. Visual representations of progress which:
. Are trusted by everybody
. Make sense to everybody
. Are used by everybody (Team Member to SC Chair)
2. Regular team driven performance self assessment and course correction (Retrospective)
….. you are nearly cooking with gas.
Management Eco System
The only thing left is to make sure that the team exists in the right management eco system.
To be honest, this is pre-requisite to even starting.
Do the Exec Sponsor, Key Stake Holders, Steering Committees, Line Accountable Leaders all understand that they must play a different role? Do they all have a shared understanding of the problem and is it the exact same understanding that the team has? Do they collaborate to solve problems and work to remove blockers to the team in real time? Do they accept and manage the risk of uncertainty. Do they welcome early issue identification, and work constructively with the team to course correct?
If you have all of the right attributes in the project team but you have a management eco system that:
. Demands time certainty and essentially ‘fixed price’ at the very start on pain of death?
. Refuses to support the team as and when they need it by leaning into Standups and Showcases to help collaboratively remove blockers and decision support in real time.
. Fails to work as a team themselves in supporting the project team, looking to apportion blame rather than work together to solve problems.
. Punishes when bad news is discovered and reported.
The very best practices and behaviours of the team won’t help you. Once again, your results will be tragic…..
But if you have the team humming and the management environment right, magic will happen.