By Roderick Cain, S&S Associate
Missed the previous Agile at Source blogs? Click on the links to read part one and part two.
“Agile isn’t something you can turn on and off. It’s striving to do a little bit better each day.” Adam Hall – Agile Coach and Waste Reducer.
Retrospectives are usually performed at the end of the Sprint, often every couple of weeks and then only when there is nothing more important to do. Why wait, set aside time at the end of the day to reflect, ask yourself – What was one success I had today? What is the one thing I will do differently tomorrow?
Maybe that is educating the Product Owner on the technical debt that has been hampering the team for months. Treat it like a loan and schedule repayment, never addressing this debt causes fragility and ultimately slows down delivery.
With this and the additional pointers to look out for in part one and two, here are the concluding things to consider with your existing practices:
Please sign on the dotted line: Agile by contract where your 3rd party “partner” insists on statements of work to carry out development. This approach is expensive, causes delays, promotes finger-pointing and stifles agility. There is no way this waste should ever be scaled.
Just the Facts, Ma’am: There are no measures or telemetrics in place, or if they are no one is looking at the output. Cannot see or analyse simple information such as are customers actually using the released features, where errors are occurring or system information such as CPU, memory or disk usage.
The Big I am: Agile Maturity Models are not everyone’s cup of tea but if you are going to complete one then do it honestly. They are not there to beat you up, they are the help focus on what needs improving.
Chuck it over the wall: Development Teams throw their code over the wall to the Operations Team for them to deploy.
Got the Fear: Teams are scared to deploy into production, so do not practice and improve the process.
You lookin’ at me: However hard you try there is always a risk of a production issue. If this happens rather than pointing fingers, teams should swarm to address the problem and look at improvements to minimise the risk of it happening again.
Co-located but not talking: Being in the same physical location helps teams but it is not the only agility factor. Team members need to speak and be aligned with principles and objectives. I have seen a team sitting on the adjacent desks hold their stand-ups via headset vs. getting around a physical board.
Autonomy requires alignment. Company priorities must be defined by leadership. Autonomy does not mean teams get to do whatever they want. Processes for cross-team collaboration must be defined. Autonomy does not mean leaving teams to self-organise every problem.
But we are doing the Spotify Model: Spotify never did the Spotify Model, it was shared as an idea to discuss vs. a framework for businesses to copy. “Even at the time we wrote it, we weren’t doing it. It was part ambition, part approximation. People have really struggled to copy something that didn’t really exist.” Joakim Sundén – agile coach at Spotify.
Vertically Challenges: Development teams are horizontally aligned to systems and applications. In the digital world, the simplest customer journeys span multiple applications. This horizontal alignment means there are multiple team dependencies and handoffs.
It won’t work here: “I’ve heard about many things that “don’t work” and then I learn the team 1) only tried once, and 2) was so busy that trying to adopt *anything* new would have failed.” John Cutler – Product Evangelist – Amplitude. In my view, if you believe in the value of doing something enough you can make it work.
Look into my Crystal Ball: The “safe” big named consultancy you engaged a year ago has come up with your 3-year TRANSFORMATION plan (most likely based on The Spotify Model) and handed it over. Success is now guaranteed.
We have made Agile better: Finally, since I recently witnessed this with a team who had taken the approach that agile meant doing whatever they thought best. You might say “What is wrong with that? It sounds sensible”, however, it basically meant throwing the principles away. The Scrum Master role was a ‘command and control’ team lead, retrospective actions were not implemented if the team lead did not agree with them, using JIRA to manage Sprints but basically doing Kanban and the team lead hiding the Product Owner from the team so they were the face of the product.
This resonates with the following from an April 2020 post “Failed #SquadGoals Spotify doesn’t use “the Spotify model” and neither should you” by Jeremiah Lee: “While Spotify gave teams control over their way of working, many people did not have a basic understanding of Agile practices. This resulted in teams iterating through process tweaks in blind hope of finding the combination that would help them improve their delivery. People lacked a common language to effectively discuss the process problems, the education to solve them, and the experience to evaluate performance. It was not really agile. It was just not-waterfall.”
In Agile at Source – Part Four, coming soon, we shall look at the tools that can be used to address the issues and create a better environment. This toolbox will be somewhat larger containing Agile principles, DevOps, Objectives & Key Results, Value Stream Mapping and a Customer Centric mind.
In the meantime, if you’re interested in bringing the true power of agile to life for your business, click here to book in a chat.
