#SGZA 2016: “Post Agile Stress Disorder (PASt)”

I recently attended the regional Scrum Gathering for 2016 in Cape Town. This is a post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions. 

This key-note was done by the famous Jim Benson and actually spilled over into subsequent impromptu session. Jim is a very entertaining speaker and doesn’t pull any punches when it comes to challenging the “accepted best practices” of Agile/Scrum/Kanban.

His talk started with some context: what do we mean by systems and what should we be optimising them for? His opinion: we want purposeful systems – systems that work towards achieving their purpose. Extending from that, we should be optimising systems to achieve that purpose – and nothing else. Processes can be defined as rules of conduct (for people) that optimise a system to achieve its purpose. If we consider processes as rules of conduct, then it makes sense that an imposed process (your process) would enslave me whereas an inherent/organic process (my process) would help me. Also, the inspect and adapt loop becomes the mechanism to continuously adjust our rules of conduct (process) based on the reality in which the system is operating.

Now, before one can optimise for purpose, one needs to understand what the purpose of the system is. Jim suggested some basic questions one should be able to answer:

• Who is my customer?
• What problems are we trying to solve?
• How do we engage professionalism over professionals?
• How do we work in small batches?

As mentioned, the key-note extended into another session and I don’t recall exactly where in the talk that happened, however at some point we started discussing how, in the past, we worked in social hierarchies (good old organisational charts) whereas now we tend to operate within social networks. One downside of social networks is that they have some communication challenges, particularly between networks. One tool Jim shared with us to help with this was an exercise to create a shared story for a team (who should be operating as a social network).

A shared story is created by the team and consists of four parts:

1. The vision of the team: Why are we doing what we’re doing?
2. Expectations of each other: What are my expectations of you? What are your expectations of me?
3. Boundaries: When does someone need to talk to me about something that they are working on? When do I need to talk to someone else?
4. Victory: How do we know when we have succeeded? What does victory look like?

The shared story should be regularly updated and revised by the team.

Some other cool snippets/ideas I picked up during the keynote and subsequent continuation:

• Using a scary scale to help prioritise stories. Teams rank a story as being either a kitten; or a crocodile; or a zombie; or a zombie crocodile (in order of scariness). The idea is that you want to be tackling and learning from the scariest stories first so that you can hopefully make them less scary.
• When having stakeholders rank work, give them only two options: Do (above the line) and Ignore (below the line).
• If your team is struggling with poor quality or not-quite-done stories, then inspect and adapt as stories move to done. Ask the question: how do I feel about this finished task/stories? If the person doesn’t feel happy, then unpack what still needs to happen in order to feel happy or comfortable about the story/task. Over time, these things would probably evolve into a more team appropriate definition of done.

What are your thoughts on some of what Jim had to say and share?

#AgileAfrica Keynote: Alignment at Scale

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

I was very excited at the fact that Henrik Kniberg was presenting at Agile Africa this year. And his opening keynote did not disappoint. First, he made it clear what he meant by Scale. He didn’t mean a couple of teams, or even many teams working on different teams working on separate things – he meant numerous team with various inter-dependencies. And then he told us some ways we could avoid becoming “unagile” when working with lots of teams.

 

He said that the first thing to realise is that for such a complicated ecosystem to work, you want everyone to be operating from a space of high autonomy and high alignment. When you achieve that, then everyone understands the problem and also has the mandate to figure out how to solve it. 

Kniberg then introduced the concept of a “soup” of ingredients required for an environment in which many teams could thrive and continue to operate in an agile fashion. The ingredients of his soup included:

1. Shared Purpose
2. Transparency
3. Feedback Loops
4. Clear Priorities
5. Organisational Learning

1. Shared Purpose

Kniberg emphasised that in order for everyone to have a shared purpose, over-communication was essential. Every team member needs to be in a position where they are able to answer the questions:

• What are you working on?
• Why are you working on it – what is its impact?
• How will you measure when it is done?

He described the following top-down model as an example:

1. The company agrees on their beliefs. This belief relates to how they are to remain a viable operation. It could be around how the company believes they make money; who their customers are; or what is likely to happen in the future.
2. Beliefs then break down into North Star Goals. This is a goal that the organisation wants to achieve in order to realise a belief. It needs to have metrics.
3. Goals are then broken down into “Bets“. It is called a bet because it is a hypothesis: if we do this, then we think (bet) that this will be the impact on our goal.
4. And, finally, teams have goals which contribute to proving or disproving bets (Kniberg called these tribe goals).

2. Transparency

Being clear about what everyone is working on and why helps to provide context that enables autonomous teams to make intentional rather than accidental decisions. One of the tools Kniberg shared with us was the DIBB Framework.

DIBB Framework

DIBB stands for Data, Insights, Belief and Bets. Basically you have a single space listing all the prioritised Bets and it is very clear what data was used to generate insights that led to the Bets, and then the Belief that particular Bet relates too. Bets can be tracked on a single Kanban taskboard with the columns: Now (what we’re working on now); Next (the Bets we will work on next); and Later (not priority for now). Kniberg emphasised that all of this information should be in a simple format that was easy to share with all (one of the companies he worked for used a simple spreadsheet).

3. Feedback Loops

We all know feedback loops are important. Feedback loops help us adjust our course. Scrum and other Agile frameworks already have built-in feedback loops for single teams. It is necessary to increase the feedback loops to cover multiple teams when scaling. Examples of multi-team feedback loops could be a Scrum of Scrums, multi-team retrospectives, Friday demos, Whole Product Review or Alignment Events, and Management Reviews.

Whole Product Review

A whole product review is when all the teams working on a particular product (whether building features or working as a support team) get together to plan for their next timebox. It includes the following components:

• A demo by each team of what they have done since the last Product Review (to create context)
• Break-outs per team to plan ahead for the next timebox.
• Creation of Team Boards that include
  • The goals for the next timebox ordered by impact
  • Stretch goals for the next timebox – these may not be achieved
  • Risks in the next timebox
  • The deliverables that will be delivered at the end of the next timebox
• A management review of the team boards on the same day before the next timebox starts

Triple Feedback Loop

This actually came out of a conversation I was listening to during one of the Fish Bowl sessions at the conference (and not from Kniberg), but an idea for these multi-level feedback loops could be:

1. Normal team reviews (Loop 1)
2. Monthly product reviews (Loop 2 – with all the teams)
3. Quarterly Sponsor review (Loop 3 whole day with team and management)

4. Ordered Clear Priorities

Ordered priorities help teams make the right decisions when trade-offs are required. Priorities should feed down into teams from the Company Beliefs and North Star Goals. Clear priorities help teams answer the questions “If we can only do one, which one would we do and why?”.

5. Organisational Learning

In order to improve, we need to learn. We cannot learn if we don’t have time to stop and process feedback that we receive. Or have time to practice skills we are growing. Kniberg suggested a couple of ways to create slack time in teams:

• A pull team schedule where teams pull work as they have capacity to do it
• Scheduled slack time e.g. retrospectives, gaps in sprints, etc.
• A culture of promoting learning over busyness

Some ideas for cross-team learning:

• Holding “Lunch and Learn” events where teams get together in an informal session to discuss a particular topic
• Cross-team retrospectives
• Embedding team members i.e. having a team member from the team that is sharing temporarily sit with the team that is learning

 The last part of the keynote dealt with the “chef”. The chef is the person who ensures all the ingredients are available for the soup and continuously tweaks them to ensure the soup is as tasty as possible. In traditional organisations, we used to call this person or persons “leaders”. Leaders are not there to tell the team how to solve the problem. They are there to ensure that the team environment contains the ingredients for autonomy and alignments.

Leader chefs:

• Create a shared sense of accountability
• Enable teams to align their decisions to company goals and with other teams
• Ensure that decisions can be made through transparency and clear ordering of priorities
• Create slack

My main take-outs were:

• Intentional rather than accidental decisions
• Scaling needs autonomous teams that are aligned
• Some cool ideas for creating top-down goal alignment and transparency
• Some cool ideas for creating peer-alignment and transparency
• The role of leaders in an Agile set-up

What were yours?

 

With thanks to sketchingscrummaster.com

#SGZA 2015: Story Mapping Workshop

I recently attended the regional Scrum Gathering for 2015 in Johannesburg. This is a post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions.

First, watch this video about making toast.

I really enjoyed the workshop on story mapping. Sadly, I still feel that although I ‘get it’ at a theoretical level, I still cannot see easy ways to use it in practice. It seems harder to create a map than it looks!

Suggested approach to creating your story map:

1. Create a vision (e.g. using the Business Model Canvas)
2. Write up the process or map (as described in the video). Think about the various user roles.
3. Explore the map with questions. “What if…?” “What about…”?
4. Group your activities to form a backbone. Focus on breadth and not depth. Consider the goals for your user personas.
5. Slice your activities into outcomes based on your persona goals.
6. Build your development strategy (order in which you will release)

Other notes

• On average, you will usually identify about 15 user roles. These can usually be combined into about three user personas.
• Unless you are working with a mature product in a stable environment, your road-map should be about delivering goals and not features.
• When building your development strategy, it usually makes sense to build your high value, high risk items first.

Links

• DrawToast.com (resources)
• Business Model Canvas (tool)
• Business Model Canvas template (from DrawToast.com)
• Tool for creating User Personas (among other things)

More on Story Mapping

• Story Mapping Video
• Some more facilitation tips.
• Simple overview
• Some more detail (plus more on vertical slices)

Have you tried story-mapping? Was is successful? What worked for you? What did you struggle with?

[Quote] Sustainable Pace

I’ve always struggled a little with the concept of sustainable pace. Most examples are around team burn-out and not having a ‘death march’. I can buy into that kind of work-life balance idea(l) – although humans generally like a little bit of pressure to get things going – but always felt there must be more to it than that. Then I stumbled across this quote in an article:

‘Sustainable pace’ means that speed takes second place to good QA practices that keep technical debt low.

I like that. How do you feel about this statement?

Explaining Refactoring to Your Customer

“Refactoring is like tidying up at home. If every time I come back from a shopping or from a business trip, I sling down my things and don’t put them away, pretty soon my house is a mess. I can’t find anything, I may end up buying new items because I can’t find the ones I know I already have. It becomes more difficult to move around the house – there are piles of stuff everywhere! I may even break something because it’s obscured by other stuff on top of it. 

Refactoring is the necessary act of putting code in the right place, where other developers can find it quickly and easily. It’s keeping code organised and decluttered. Developers need to do refactoring, or they can end up with the same code in several places, which takes more effort to maintain. Refactoring is not the aesthetic organisation of the code, such as applying feng shui to your home – it’s basic housekeeping.”

Agile Coaching – Rachel Davies & Liz Sedley

Animal sizes

This is a useful technique you may want to try next time you need to quickly prioritise some actions with a large group of stakeholders who have varied levels of experience with agile.

In our case, we were trying to find a framework to help decide what actions to take to improve one of our testing environments. The stakeholders ranged from the development teams who used the environment to test their work, to the IT Ops team who used it to test the deployment process, to the head of the division who obviously had an interest in ensuring things got to Production as efficiently and correctly as possible. After a process of re-affirming the goals of the environment in question and highlighting the issues that were currently being experienced, we found ourselves with a list of thirty problems that needed prioritisation.

In order to do so, I first had everyone plot the problems across a horizontal axis based on the effort/cost/difficulty they associated with solving the problem. As not everyone knew about sizing (and, sometimes when people are familiar with sizing, it can also confuse things), I used a scale of animals. I made the scale clear (an image) plus had a picture of each animal plotted along the horizontal axis. The group quickly grasped the concept and set about categorising problem solutions from cat to blue whale.

Animal sizes scale

Once they had plotted all the problems along an investment (time and/or money and/or skills) scale, it was time to categorise the problems according to impact. For this I added a vertical axis with three sections: showstopper, major and inconvenient. The important bit was that I provided a clear and simple definition for each of these to make sure everyone was speaking the same language.

We used stickies plotted on big sheets of paper on a table so that people could move around easily. At the end of about 15 minutes, a group of about 16 people from different teams and backgrounds had categorised thirty problems by size and impact to form a useful framework for prioritising actions. Documentation was as easy as taking a photo with my cell phone.

UPDATE 16/11/2015: Animal images resource (for printing).