Agile at Source...

[This is a republish of a four part blog series I wrote for Sullivan and Stanley mid 2020 following a SAFe project, hence the strong references to Covid-19. It is rather long so if you prefer a PDF version then please connect.]

Father Ted: OK, one last time. These are small… but the ones out there are far away. Small… far away…?

Agile at Source – Part One

You cannot jump to Agile at Scale (far away) without starting small (close by), before you can scale you need a solid foundation - get small working correctly.

A colleague asked: “What is the biggest hurdle to effective Agile coaching, is it moving people away from Waterfall?“?

The answer in this day and age is no, it is moving from doing agile to being agile. Do not get me wrong there are advantages to the “doing” part of agile frameworks, for example, Kanban boards, daily scrums and Sprint provide visibility, communication and hopefully increased production.

However, without an understanding of why you are following them, the true benefits of agile will not be achieved; continuous improvement, transparency, ability to adapt and delivery based on real customer value.??

With this in mind, here are the top things to look out for in your existing practices:

We are doing Scrum but without those pesky meetings: Sprints without the defined events (they are not meetings), the events get rescheduled often, people do not attend.

By the Book: Blindly following the Sprint schedule vs. understanding what they are there to achieve – short iterations, promoting conversations, amending the plan, improving delivery, unblocking issues, reducing rework, etc.

Separation anxiety: The Sprint duration flexes based on the application release schedules i.e. a deployment window is delayed so the Sprint is lengthened to meet to the date. There is also a difference between a Deployment (just some code put on a server) and a Release (provides value for the end user).

Sprint phobia: Long waterfall type Sprints, the benefit of short Sprints is you get more time to practice, compact review cycles that drive continuous improvement. “You gain strength, courage and confidence by every experience in which you really stop to look fear in the face” - Eleanor Roosevelt.

Points do not always make prizes: Story points are not well understood, velocity is used as a management metric, trying to standardise story points across teams to compare and contrast productivity and they get gamed to increase velocity.

Don’t look back in Anger: No Retrospectives or Retrospectives where actions are not agreed, prioritised or carried out.???

Yawn: The “feeling there are too many meetings”, for weekly sprints the events should take up no more than 10% of the available delivery time. When properly delivered, the events help reduce the number of ad-hoc meetings.??

Daily Stand-up, up, up, up: The Daily Scrum lasts far too long, turning into a water cooler chat, acceptance criteria review. Keep it short and then set up another session if needed.

January gym body - lacking definition: No agreed and visible Definition of Ready or Definition of Done.??

It’s hard to let go: Completed code does not get into production on a regular basis since it is complex to merge, validate and deploy.

Cracking the Whip: Continually exceeding “work in progress” limits, the work gets blocked and more and more is pushed into the process.

Never Ending Story: Work being started and not completed - returned to the backlog, blocked or floats from Sprint to Sprint since ill defined, the team cannot make decisions so waiting on others, the product owner is not empowered and over commitment.

It is important to instil and promote an agile mindset before trying to deploy agile across the whole enterprise.

As Allen Holub (computer scientist and widely published software architect and Agile-transformation consultant) commented “Agile is not something you implement. It’s a set of principles and practices that you adopt to solve business problems. The best way to do that is incrementally. Identify a core problem. Fix it using tools from your Agile toolbox. Repeat.”

We’ve only touched the surface on some of the areas of focus, so we will be back?with part two soon.?

Agile at Source – Part Two

As Sean Reilly , said: “Nail it, then scale it”.?

There was a poll on LinkedIn, “How many teams can a Scrum Master serve? 1, 2, 3 or 4+”, which promoted discussion. A standout being "A good SM can serve two teams, a great SM serves only one."?Which sounds like a quote from Geoff Watts ’s "Scrum Mastery: From Good To Great Servant-Leadership ".??

Everyone involved in agile should read this book, it is right at the top of my ”Kitbag” and one I regularly refer to.??

?It also introduced the term “Jira Jockey” which reminded me of a concern a potential scrum master had, who saw the role as JIRA admin. This is obviously far from the truth but without an understanding of the role and how it is there to serve the team, you will never be able to scale up.?

With this in mind, here are the additional things (a follow on from part one) that you should be looking out for in your existing practices:

Whatevs: Product Owners are not interested in seeing what has been built for them.

AWOL Customers: Missing customer involvement and feedback, is anyone really using what is delivered? What does the customer think of what is delivered? Can we A/B test functionality?

Not just for the hell of it: The Product Owner is not engaged and does not appreciate that this is for them and their customers.

How are you? Good and you: The view that everything is fine and we are doing it all 100% correct. There is always time to take stock, be curious, learn and look for improvements.???

Health and SAFety / LeSS is NOT more: You need to slog the path to agility first, you cannot just jump on the “release” train to Enterprise Agile.

Change is Good / Transformers – evil robots in disguise: What tier of change are you looking at – Team/Tribe/Enterprise? Does the word Transformation scare people? Is continued incremental change better?

Show me the money value: Teams do not understand the “value” that they are delivering, they are just working on features.

MVP: Maximum Variable Product: When everything is a high priority then nothing is. Look at that new shiny thing. JFDI leadership requirements. Amazon does it so we need to!

More swimlanes than an Olympic pool: The boards are sliced and diced by multiple Epics that are being used for grouping features.

There is no ‘I’ in Team: Epics are being worked on by individuals, so lots of specialisation. If a team member is away then work on that Epic becomes blocked. There is a lack of shared knowledge, leading to a lack of collaboration.

You want to Bet: Due to a slow and procrastinated “ideation to release” process not enough experimentation takes place.

JIRAs: When stories start getting called JIRAs you know you are in trouble.?

Useless Archaic Tedium (UAT): User Acceptance Testing is predominantly manual and takes weeks, causing releases to be batched up, product debt and delay in measuring and realising customer value.

“How much scrum would a Scrum Master master, If a Scrum Master could master scrum?

He would master, he would, as much as he could, And master as much as a Scrum Master would. If a Scrum Master could master scrum.”??

Cindy Bloomer - Transformation Leader and Agile Coach.

Agile at Source – Part Three

?“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 where 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.?

Agile at Source – Part Four

The previous blogs highlighted forty plus impediments to smooth scaling of your delivery practices. In this final blog of the series, we will look at the tools that can be used to address the issues previously identified, to create a better environment.

Over the years retrospectives, value stream mapping workshops, backlog prioritisation sessions, shadowing and one-to-ones have unearthed the discussed impediments. Retrospectives are one of, if not the most important part of agile. They do not need to be limited to just a squad, I have run them with over 50 people from different areas of the ideation to release process. Agreeing to a backlog of actionable outcomes is core to continuous improvement and addressing issues.

In part one, I quoted Allen Holub : “Agile is not something you implement. It’s a set of principles and practices that you adopt to solve business problems. The best way to do that is incrementally. Identify a core problem. Fix it using tools from your Agile toolbox. Repeat.”

This toolbox has grown into an agility kitbag containing Agile and DevOps principles, Objectives & Key Results, Value Stream Mapping, a Continuous Improvement mentality and a Customer-Centric mind. Agile and DevOps practices are well established but need a pragmatic approach. It is impossible to solve every problem at once, you need to prioritise. What is your continuous improvement minimal viable product?

Objectives and Key Results may be a newer concept to some readers, so this blog provides an intro. They provide an action-based framework for addressing several key impediments. It would be remiss not to acknowledge the present situation, I will highlight the role OKRs play in cutting through the extreme confusion COVID-19 has caused. We need to move from Pandemic Panic to Productive Panic to being Purely Productive.

An Objective is a description of a goal to be achieved. It can be thought of as the destination on a map.

A Key Result is an unambiguous metric with target value that measures progress towards an Objective. It is a signpost that shows how close you are to your end goal.

An Initiative is a description of the work you’ll do to influence a Key Result. It describes how you get there, for example, walk, cycle, car, etc.

?At Intel, investor and venture capitalist John Doerr was introduced to OKRs by Andy Grove (“The Father of OKRs”) and subsequently implemented them into blue chips including Compaq, Netscape, Symantec, Sun Microsystems, Amazon, Intuit, Macromedia, Google and Twitter.

His formula provides a clear method of describing OKRs: We will (Objective) as measured by (this set of Key Results) by doing (idea 1) Or by doing (idea 2) or by doing (idea 3).

The approach is to create a small number of timeboxed OKRs, either quarterly, execution-focused or annually, with more of an eye on the strategy.

Objectives are:

• Directional: Having a direction helps you to focus your efforts
• Impactful and Inspirational: A moonshot to motivate the team, however they must be achievable
• Understandable: Clearly articulated so they can be shared both internally and externally
• Independent: Achievement is within the team's circle of influence

Key Results are:

• Achievable: KRs tell you how you get to your Objective, so must be possible to meet
• Ambitious: KRs should not be too simple to achieve, they should be stretching
• Measurable: Boolean, they are either completed or not, or a numerical target
• Verifiable and Specific: Clearly defined in terms of scope, so there is no ambiguity

Example OKR

Objective: I will run a marathon in under 4 hrs

Key Results

As measured by:

• Joining a marathon training group
• Training 5 days per week with 1 long run each week
• Increase mileage by 5 miles per fortnight
• Drink at least 3 litres of water every day
• Sleep at least 8 hours every night

Initiatives

By doing:

• A calendar showing when I need to train
• Defining the distance I need to achieve at each session
• A food diary to ensure I meet the nutrition needs
• Putting a recurring order for water on my weekly shop

So how do they improve your delivery?

Focus: Alignment of everyone’s work to deliver the top goals. The advantage of this is it promotes the creation of a prioritised backlog based on a defined framework i.e. customer value, revenue, increased conversion, technical complexity, etc.

Governance: Regular OKR confidence check-ins provide a communication mechanism for tracking priorities and engaging distributed teams.

Transparency: Provide visibility of goals and measures across the organisation. They provide the common language to help teams cut through the fog of information that COVID-19 is causing.?

Commitment: By having top-down and bottom-up OKRs, teams commit to their delivery of the KRs that will ultimately drive the company’s OKRs. Teams thrive when they have the autonomy to ensure their work matters.?

Quantitative: Promote the need for data and the ability to analyse it. Clear KRs remove the need for a crystal ball since it must be measurable week on week.

Continuous improvement: To meet the KRs you may need to look at your ways of working and hone accordingly.

Celebration: Through regular check-in cadence and transparency, wins can be celebrated and team morale improved.

Striving but Never Arriving: This was a quote from a CEO, his teams were putting in immense effort but he was unsure it was delivering the necessary results to weather the pandemic - let alone come out stronger. With OKRs in place, you deliver only the initiatives that move the needle and drive the key results.

The first step is running an interactive Objective and Key Results Setting workshop, where the leadership?team comes together to agree on the company OKRs, from there aligning team OKRs can be set.?