#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:

The vision of the team: Why are we doing what we’re doing?

Expectations of each other: What are my expectations of you? What are your expectations of me?

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?

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.