Agile Training Toronto - Kanban, Lean, Scrum Coach » Technical Practices

Sustaining Agility Game

Michael Sahota — Fri, 15 Apr 2011 11:36:10 +0000

Have you been on a software project where each release gets harder and harder? Many projects fall into the tar pit of the Design Dead Core.

Why do nearly all software projects fail to balance short term choices with long term consequences?

Through game-play you will experience how hard it is to make effective choices. Game learnings will be tied into well-known models in and beyond software such as Technical Debt, Stephen Covey’s Production Capability, and Alistair Cockburn’s theory of competing games.

Recipe

Game Objective: Participants experience the attraction of short-term thinking and feel the long-term consequences. The game helps executives and managers understand the importance of investment in sustainable development practices. The game is intended to help them get through a Red Pill, Blue Pill moment.
Number of participants: 6 to 50 (Has been playtested with 40 at XP Toronto User Group Meeting).
Team size: 3 to 5 people per team.
Duration: 90 to 110 minutes
Materials: Game cards (can print or write by hand), pennies (15 per team), dice (two per team)
Setup: (optional) video projector, tables for group work, whiteboard or flipchart.
Credits: This game was created by Alistair McKinnell and Michael Sahota.

Session Timetable

Intro & Motivate Game [3 min]
Break into teams of four or five people. [2 min]
Setup Game [5 min]
Year 1 [30+ min]
Year 2 [20+ min]
Year 3 [15 min]
Debrief [15 min]

There is a backdrop story that motivates the game situation and is used throughout the game to provide entertainment and inject new rules.

What’s Your Choice?

Here is a photo showing the project choices available to management teams:

Game Narrative

You’re working at a large organization. (Although situation entirely applies to smaller companies). Your goal in this game is to get promoted within your organization through delivery excellence. You need 50 Career Points to get promoted. You’ll keep track of your Career Points as the game progresses.

Together with the other people on your team, you form the management team of a software development division. Your team is competing with other teams to get promoted.

[Handout Steady and Fast Cards and Scoring Sheet]
[Each steady project generates $3M revenue. Each fast project generates $4M revenue.]

[Optional Colour: You have two strategies that you can follow for any one of the projects in your project portfolio: (1) negotiate with the development organization and let them influence the deadlines; or (2) pressure the development organization to deliver to meet this quarter's business targets. You may choose a hybrid of these strategies for your project portfolio: running some of your projects with a steady, negotiated delivery pace and some of your projects with a fast delivery pace.]

Year One

Turn 1: Q1
Start of Turn: We are going to walk you through the first turn.
Allocation: You can fund 10 projects. When you take over the following strategy is already in place: 8 steady projects and 2 fast projects.
Scoring: Calculate revenue.
Calculate change in Career Points. Calculate cumulative Career Points.

[Each quarter, you get 1 Career Point for every $1M revenue over $28M and you lose 1 Career Point for every $1M revenue below $28M. You start with 12 Career Points. Need 50 Career Points to win]

Turn 2: Q2
Start of Turn: Your team has achieved more autonomy from the senior management team and you may choose whatever project delivery strategy you like.
Allocation: You can fund 10 projects. Choose an allocation strategy.
Scoring: as above.

Turn 3: Q3
Start of Turn: At the company town hall, your CEO shares her latest business thinking with the organization. Last quarter she attending a seminar based on The 7 Habits of Highly Effective People and going forward she wants the organization to consider not just production but also production capacity.

Some consultants have been hired and have started to put in place some metrics around production capacity.

The consultants present a report to your management team. It turns out that projects that are designated for fast delivery appear to be lowering the development organization’s production capacity by one unit of production capacity for each fast project.

[Fill in last 4 columns to spreadsheet: Invest, Delta Production Capacity, Production Capacity, and Fundable Projects. You start with a production capacity of 105. Update these columns for the first two turns (Q1 and Q2).]

[Each fast project reduces production capacity by 1. You start with a production capacity of 105. The number of Fundable Projects is calculated by dividing your production capacity by 10 and rounding down.]

Explain Invest. Your management team has been given a new portfolio management strategy: in addition to delivering project using either a steady or fast delivery strategy you may also invest in projects to increase your delivery capacity.

Scoring:
[Each invest project generates an opportunity to gain production capacity by rolling a 1d6 where each pip is a unit of production capacity. ]

[In order to avoid getting fired you must meet satisfy these 3 conditions: (1) no more than 5 Career Points lost in any one quarter.; (2) never two quarters in a row with Career Points lost; and (3) never allow Career Points to go below zero.]

Turn 4: Q4
Start of Turn: The consultants present another report to your management team. It turns out that projects that are designated for steady delivery appear to be lowering the development organization’s production capacity as well.
[Reduce production capacity by one for every 4 projects (steady or fast) (rounded down).]

End of Turn: Audit Event. Each team requires two independent auditors from other teams to verify the calculations.

Game Events (Year 2)

Beginning of Q1: At the all-hands meeting to kickoff the New Year your CEO exhorts everyone to work harder and to stay focused on delivery. She announces that Agile software development is on her radar and to stay tuned.The senior management team has set a revenue target of $33M for this quarter.

[Rules: You must meet it or loose an additional 5 career points (usual Career Point loss limit is increased to 10 Career Points). THIS TURN ONLY]

Q2
Beginning of Q2: Your management team becomes aware that an Agile consulting firm has been hired to help the development organization transition to Scrum. [Possible rule: you must do at least 3 fast projects while you still can]

Q3
Beginning of Q3: At the company town hall, as usual, your CEO shares her latest business thinking with the organization. Pick one option:

Discuss design dead core and how it gets created. [3 min] (http://www.agilitrix.com/2010/02/inventors-dilemma-and-the-dead-core/)
Show Schwaber video [11 min] The lights are dimmed and she signals the Audio Visual guys to play the Design-Dead Core video presented by Ken Schwaber. [Ken http://www.youtube.com/watch?v=IyNPeTn8fpo&t=35m38s (to 45:07)]

Beginning of Q4: CEO announces that promotion criteria are under review and they are working on revised policies for Q1 that reflect the need for sustainable development.

Game Events (Year 3)

Beginning of Q1: At the company town hall, as usual, your CEO shares her latest business thinking with the organization.Agile consultant explains Alistair Cockburn’s model of Competing games (current/next): Current Project (bounded game) and Product/Company (unbounded game)

[Rule change: Promotion Criteria is now 35 Career Points and 13 Production]

[CFO: Teams that have very low production capacity can revert to original game starting conditions]

Debrief

Here is an example debrief using ORID (http://pacific-edge.info/orid/):

What did you notice during in the game?
What emotions did the game raise for you?
What does this mean for you and your organization?
What will you do with these learnings?

Resources

Sustaining Agility Game Options – PDF to print 3″ x 5″ index cards (one set per team)
Sustaining Agility Score Sheet – Excel spreadsheet to print (one sheet per team)

Facilitation Tips

It is useful to create memorable even stereotyped characters to help participants connect with the storyline. e.g. CEO has a Texan drawl, CFO is from NYC, Consultant is from California.
Write Rule fragments on flipchart or whiteboard so everyone can see the rules. I suggest skipping text and just put keywords such as “Invest –>+1D6 Production Capacity”.
If you have not played the game before, I suggest you playtest it on your own.
It may be helpful to write up rules on flipchart in advance and then share them when it is time.

Feedback from first run (XPToronto)

“Fantastic, Magical” – Jorgen Baker
“Real pressures bottled up” – Alex Aitken
“Good fun, valuable, opportunity to learn” – Tom Huras
“Thought-provoking, Fun, Interesting” – Nick Faulkener
“Lively, Interactive, Team-focused” – Hedi Buchner

Feedback from second run (Agile Games 2011)

“This game relates hugely to my current work situation where we struggle daily to do thing the right way or increase our technical debt. This game can give great insight to our companies leader to make the right decisions as much as possible.” – A.F.
“Very interesting game. I’m going to try it myself.” – A.J.
“Good mix of presentation and game. Provided great thoughts about career goals, revenue and investing in production capability and the future.” – J.V.
“Great, practical game about strategy and the impact of long-term choices and short-term consequences” – T.M.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Software Craftsmanship promotes Competence Culture

Michael Sahota — Mon, 04 Apr 2011 19:07:44 +0000

The rise of anemic Scrum was noted to dismay among the Agile community and in particular by “Uncle Bob” Martin who coined the fifth Agile manifesto value of Craftsmanship over Crap(Execution). This gave rise to the much needed community of Software Craftsmanship.

Looking at an earlier post - Agile is about Collaboration and Cultivation Culture – it is clear that the Agile community was not addressing the Competence Culture. And we as a community of software professionals do need to pay attention to competence and technical excellence for long term sustainability. Uncle Bob recently wrote a good article on this topic – The Land that Scrum Forgot.

Cultural View of the Manifesto for Software Craftsmanship

The diagram below relates parts of the craftsmanship manifesto to cultures identified in the Schneider cultural model.

Not surprisingly, there is a big focus on Competence Culture. This culture is focussed achieving success by being the best. And craftsmanship is about being the best software developers possible.

The value of productive partnerships stands alone. I am curious as to what purpose this supports as it is not directly related to writing quality software. I am wondering whether:

this exists as a bridge to the Agile community?
is related to the strong XP practice of pairing?
is intended to appeal to the need for mentorship?

So what?

Craftsmanship needs to exist to make sure that the technical practices promoted by XP don’t get lost in fluffy bunny Agile culture. Things like: refactor mercilessly, do the simplest thing that could possibly work, TDD, ATDD, continuous integration, continuous deployment, shared code ownership, clean code, etc.

The existence of a separate movement to support competence culture that exists outside of the Agile, supports the assessment of Agile culture as focussed on Collaboration and Cultivation.

Caveats

I think that Craftsmanship is a good thing. I also believe it is complementary to Agile.

This is post is about understanding how Craftsmanship fits with Agile and company culture.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Go Faster with Root Cause Analysis

Michael Sahota — Mon, 28 Jun 2010 15:56:38 +0000

One of the workshops I run is to help team members understand root cause analysis. I use it with operations teams as well as product development teams. My workshop goal is to have people leave with a basic understanding and some practice.

I created the diagram below to situate this workshop in a larger context of Kaizen (Continuous improvement).

One starting point is with a team using a Scrum board or Kanban to create BIG visible information. This supports teams in identifying problems or waste to stop the production line and investigate the problem using root cause analysis tools. I introduce two tools and have the participants practice with each:

Ask Why five times – powerful technique for drilling down into problems.
Fishbone (Ishikawa) Diagram – looks at the big picture around the problem.

Both of these improve quality to help teams go fast. 5S (sort, straighten, shine, standardize, sustain) is also totally applicable for software – it’s called clean code: coding standard, refactoring, etc.

Finally, the foundations for Kaizen and root cause analysis are:

NO BLAME. Most problems are related to the system, not individuals.
Team work and trust. If 100 people each help find 1% improvement, this will be sustainable.
Genchi Genbustsu – Go and See. When you work on a problem, go to the source and get the facts for yourself. Root cause is about investigation and problem solving – see and think for yourself.

If you want to learn more, check out Implementing Lean Software Development: From Concept to Cash or Toyota Production System: Beyond Large-Scale Production.

Workshop Slides

Here is a slide deck I have used in training. It’s from last year, and would benefit from a refresh to cut down on the text – still very usable. As usual, you are welcome to use this as well as the diagram under Creative Commons license.

Root cause analysis apr 2010

View more presentations from Michael Sahota.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Rapid reliable releases

Michael Sahota — Thu, 03 Jun 2010 17:41:17 +0000

I recently attended a ThoughtWorks QTB – Rapid, Reliable Releases (AKA It’s not making money until its in production) by Rolf Russell and Andy Duncan. It was a solid presentation around the importance of managing environments effectively.

I will walk through the diagram below starting with …

a reliable continuous integration system creates a foundation for rapid reliable releases. It provides early integration and gives the teams rapid feedback on how they are doing. Everything else follows from this.

A key ingredient for successful management of production and other environments is collaboration with dev and ops. There is even a new type of role appearing – DevOps – that handles both development and operations. Either way, someone needs to champion this important interface.

The next topic was about using value stream mapping to see what it takes to actually get something into production (I heartily agree with this approach as I have found it very effective). What we often see as a result is that the work is optimized for each department and is not aligned with the best needs of the whole business and there are lot’s of delays and handoffs.

The next step is to envision future state - what items can go in parallel to get feedback as soon as possible. In one environment is was functional testing, performance testing, and UAT.

A practical idea is to use the cloud for scalable parallel Continuous Integration. In this situation we need lot’s of computers for a short burst, so this lines up nicely with the cloud’s pay per use model and lets testing go really fast.

The final bits of advice were around creating deployment recipes that go with the code (including database changes). In order to accomplish this you will need to create consistent environments and encapsulate differences (such as number of servers, specialized hardware, etc). Once you explicitly handle all the risky bits, then it is easy to support reliable and automated deploys.

If you haven’t done this sort of thing before, then it may seem like a lot of work. For me, it’s seems just normal. I personally implemented a lot of this when I worked at a startup in 2000 and have been using it ever since. I can say firsthand that work on this really pays off.

Video is available on InfoQ.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Strategies for Effectively Managing Legacy Systems

Michael Sahota — Mon, 05 Apr 2010 22:48:43 +0000

Derek Longmuir presented ThoughtWorks QTB on working with legacy systems. You can see the video and slides on InfoQ.

I like the definition given by Michael Feathers:

Legacy code is simply code without tests.

Legacy Systems have Value. They are usually business critical and feature rich. They may even be stable and reliable (YMMV). Hint: in the MindMap below, start at 3 o’clock and go clockwise.

Why change from a legacy system? There are number of good reasons: obsolete technology, can’t add features, system is fragile.

This is an important problem since most systems we have 10% of the effort to build and 90% effort to maintain. So to manage costs, we need maintainable systems.

What to do? Traditional approaches such as Big Bang (think explosion) and wrapping/hiding legacy systems rarely achieve business objectives.

Do a system health check. Look at the code. Get complexity measures. Look at test code ratio. What state is the system in?

Before getting started, there are some tools that you will need for basic technical hygiene. The equivalent of brushing and flossing your teeth is test and build automation.

How to tackle this?

With the Strangler approach, the goal is to strangle the existing application by building a new system that runs in parallel. The idea is to put a new interface in place and begin migrating the functionality in a piecewise fashion. This approach takes a lot of effort and makes sense when there is no hope for the existing code base.

The Phased approach is about rehabilitating the system piece by piece. How do you eat an elephant? One bite at a time.

Strangely, there was no mention of the bible on this topic: Working Effectively with Legacy Code by Michael Feathers. This book is a must-read on this topic. As is Refactoring, Refactoring to Patterns, and Clean Code.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Inventors Dilemma and the Dead Core

Michael Sahota — Wed, 24 Feb 2010 13:32:27 +0000

Ken Schwaber has a great presentation where he talks about the Innovator’s Dillemma and how companies build a (design) dead core.

A typical (success) story

Management – we need to hit the date.
Developers – OK, we’ll cut quality but won’t tell you.
Success! We made the date. We’re heroes!

BUT, this is a horrible long term strategy because you get a design-dead core and can no longer ship product.

Design-dead core

Do you have a design-dead core? Here’s a quick checklist (see mindmap below):

The code is fragile: difficult to work with and things break unpredictably
Little or no automated test harness.
Few experts who really understand the technology.

Innovator’s Dilemma

The purported dilemma is that you need to choose between fast delivery and maintainability. So, if you want to get to market fast you need to take shortcuts that are going to hinder you in the long run.

This is also called the inventor’s dilemma.

Agile to the Rescue

Teams that follow Agile practices avoid this peril in two ways.

By managing features and scope, teams can find the most valuable software to deliver by a certain date.

Technical practices such as automated testing, continuous integration and refactoring keep a code base healthy and maintainable. They also helps teams go faster.

Release Burndown to illustrate the Innovator’s Dilemma

Consider the chart below. Companies start at burndown line A. If they use Agile, they will stay there. Most companies don’t. So, release by release, they accumulate technical debt and the code base decays. After a few years, they build a design-dead core.

As a coach, I like to show teams the chart below and vote on their code base. Many companies are at line C with some area’s that are D.

Help! I have a dead core!

OK, so you’ve got a dead core. Sad news. There are ways to recover. I’d suggest you start with Michael Feather’s book Working Effectively with Legacy Code.

Watch the video

The whole video is great, but for the part explaining the Innovator’s dilemma check out:

Start: 35:38
Stop: 45:07

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Agile Learning Resources

Michael Sahota — Wed, 28 Oct 2009 01:12:04 +0000

This is a list of some resources that are useful for getting started or growing your understanding of Agile.

The permanent page for this content on my website is here (so this is better place to link to since it will be updated).

Getting Started

Short articles for printing out and reading while you are on the train/subway.

Agile Manifesto – Web page
Agile Manifesto Principles – Web page
Article on the history of Iterative developement
Connections between Lean and Agile
Short Scrum Guide – 13 page article/guide
Scrum on a page – This you can put on a wall near you.

Intro to Scrum/Agile

Other Stuff you need to know to get your project started

Next Steps

Check out some of the other resources below.
Start reading some of the books.
You have started a journey of learning – be patient and enjoy the trip.

Additional Learning Resources

Scrum
- Scrum Overview by Ken Schwaber – Website
- Scrum Overview by Mike Cohn – Website
XP
- eXtreme Programming on C2 Wiki.
User Stories
- An Introduction to User Stories – Presentation
Agile Estimation and Planning
- Agile Estimation and Planning – Presentation
Lean
- Demo showing impact of bottlenecks
- Lean for Business – Website
Fun Stuff
- Punchy video about how Agile can improve on Waterfall
Agile Team Room
- Agile Team Room – Photos
- How does radical collocation help a team succeed?
Pairing – team collaboration on tasks
- Benefits of Pair Programming – C2 Wiki
- Benefits Research Paper – Cockburn & Williams
- How Pair Programming works - General concepts behind pairing and pair programming] (used in training)
- Promiscuous Pairing - Some ideas on how rapid pairing can cultivate creativity. Also, How-to Article
Agile Documentation Practices – Web Article
Agile Testing – Video (60 min)
Automated Testing
- Automated Acceptance Testing – Presentation
How Agile are you? (Agile Adoption)
- Nokia Test – basic Agile test
- Uncle Bob’s more extensive test
Crystal Clear – low ceremony Agile process
- 7 Properties of Crystal Clear – Article
- 7 Properties Mind Map

Books to Read

Stage 1: Getting the basics in place

Deepening the practice

eXtremeProgramming

Technical Practices

Lean

Other good ones

Games & Simulations

XPGame – learn how Agile really works
Leadership Game - learn different leadership styles and how you relate to them
Bottleneck Game – learn how to improve your processes to eliminate bottlenecks
Business Value Game – learn strategies and challenges with prioritizing work (product backlog)

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Agile Tour Toronto Presentation: A Gentle Introduction to Agile

Michael Sahota — Sun, 25 Oct 2009 16:24:32 +0000

Below are the slides from my first presentation at AgileTourToronto. It is based on ideas from Alistair Cockburn (among others) and has been a work-in-progress since I started sharing Agile ideas in 2002.

Presentation Overview

There are a lot of choices and alternatives for getting started with Agile. It can be confusing. This talk will give you a brief guided tour of Agile methodologies so that you have some understanding of how they are similar and how they differ. We’ll cover some of the history of iterative development and waterfall as well as the Agile Manifesto to provide context. At the end of this, you will have an understanding of key principles and the Agile landscape.

Slides on Slideshare

A Gentle Introduction To Agile

View more presentations from Michael Sahota.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Deliberate Practice – a key to Craftsmanship

Michael Sahota — Sun, 11 Oct 2009 17:00:19 +0000

At Agile 2009, Mary Poppendieck presented on “Deliberate Practice” – how people become experts. The video and slides are available from InfoQ.

Consider the fifth value statement proposed for the Agile Manifesto by Bob Martin:

Craftsmanship over Crap

This presentation follows in the theme craftsmanship – How do we as a community bring it about?

The answer given in this talk is we need to consider what it takes to develop elite level skills in other professions – deliberate practice. Consider the visual note below:

It seems to me that virtually every company I have every worked for or with has done virtually nothing to bring about excellence in technical (or other) skills. Imagine what the world would be like if companies viewed their employees as assets and invested in them with mentoring and challenges so that they get deliberate practice. This requires companies to think about Production Capability and not just Production. More than just thinking about hitting the deadline. This is an essential component in build lasting success.

Ever heard of this crazy-sounding approach called eXtreme Programming (XP)? Maybe they were on to something.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

User Interface Engineering – Agile 2009 Banquet

Michael Sahota — Mon, 21 Sep 2009 23:57:22 +0000

Jared Spool gave a pretty good banquet keynote for Agile 2009 on User Interface Engineering. The main point is that is that very successful companies use amazing interfaces as a key competitive advantage. And the key to this is good user experience design.

Case and point is Apple. We watched an Apple video from the 80′s that showed Apple’s vision for the future of the computer (funny/sad was a plot element so long ago was about global climate change). Everyone at Apple knew what the vision was and could explain it. So what this means is that everyone is thinking about the long-term vision. Every time they have a choice to make on design they can take a step in the right direction so that the future can be achieved in part through many many tiny shifts.

Good design is INVISIBLE. NetFlicks is destroying their competition through a ridiculously high net promoter score (how likely someone is to refer a friend). No one ever mentions their Web UI even though it rocks – it’s invisble: It does what it needs to and it’s easy. How do they do it? In part through a culture of excellence – employees are the top priority and the CEO puts this ahead of board meetings. To support this they hire fast and fire fast. They also pass the culture test.

How do you learn good user interface design? Mentoring! Good designers know what good design is, but cannot explain it. Like chicken sexing. (Makes me wonder how much we are kidding ourselves that good design can simply be taught through patterns or what not.)

The company test is a recipe for successful cultures. All the companies with awesome user experience met the test even though they were radically different in many ways.

The last point about celebrating failure is critical. If people are not making mistakes, then they are playing it safe. And if they are playing it safe, the result is mediocrity not excellence. There is a similar field of thought around innovation – it also requires support for failure.

If you need help building better UI, start with #2 – spend some time observing your users and then make it better.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.