Category: Agile

The Road to Scrum is Paved with Lego (updated)

Games are a fun, interactive, effective way to teach. A dose of competition mixed with social interaction keeps people engaged. You learn by doing and reflecting on the experience. Powerpoint, your time is over.

Until recently, I hadn’t had the opportunity to use learning games, since most of my work as an Agile coach is done remotely. In February I tried out the Resort Brochure with The Blog Studio and Thmvmnt with positive results, and then in early March I spent a few days with the Web Collective, all small purpose-driven organizations looking to become more Agile.

To introduce everyone to Scrum, I used Alexey Krivitsky‘s excellent Lego For Extended Scrum Simulation. Alexey’s game has improvements over other Scrum simulations I’ve read online:

  1. Build the backlog. Teams estimate the size of items, and the product owner may re-prioritize based on those estimates, just like in a real project. Some games have pre-determined backlogs, with all items sized and prioritized for you. Seems a little too command-and-control to me, which Scrum isn’t supposed to be.
  2. Multi-team collaboration. Teams work together, not against each other to reach their goal.
  3. Metrics applied to planning process. If you are going to bother estimating, make it useful. Teams estimate the size of their work, compare planned vs. observed velocity (how much they get done each sprint) and see the effect of observed velocity on their release plan.
Leading retrospective at end of game

How it works

This was my first time trying the Lego exercise. The product owner (me) explains to the team the vision for the project, to get everyone inspired and focused. In this case, the team has been hired to build a new city.

The team then estimates the items in the backlog, which includes things like one story buildings, a church, a tow truck and a crane. We used Steve Bochman’s team estimation technique to quickly size up stories. Team estimation turned out to be quicker than planning poker, which is what I had always used in projects. Team estimation and planning poker focus on comparing the relative size of features / stories, which is far easier to do and more accurate than trying to guess the absolute time to build each item. The next day the Air Charity team at Web Collective estimated over 50 stories, averaging between 2-3 minutes per story! Amazing speed given this was their first Agile project.

Task board showing 3 sprints of stories and a velocity chart
Task board showing 4 sprints of stories and a velocity chart

Once the items are estimated, the teams have guess how much they can get done in one 5 minute sprint, and that is used to determine their initial velocity. We’ll then count up the number of points at the end of each sprint to adjust that number. In the diagram above, the team estimated 18 points per sprint before starting the work. Each section of stories is a sprint.

Watch the passion, focus and determination for yourselves.

What went well

  • Teams learned the importance of getting enough information from the Product Owner (client) to deliver what the client wanted. Some Lego creations were rejected because they didn’t pass expected scenarios, like being able to open the door on a building without the wall coming apart. The quick feedback cycles of sprints enabled them to fail fast and get back on track.
  • Everyone had fun learning about Scrum. They went through most of the Scrum process, from release planning to working in 4 sprints, including a demo / review at the end of each one.

What could have been better

  • Forgot to update burn down chart at the end of each sprint, and with that, the review of the teams’ overall progress in comparison to the release plan.
  • Need more Lego. One tow truck hobbled on 3 wheels.
  • With 8 people, team estimation stalled at times. Need to learn more techniques to keep flow moving. Hank Roark (@hroark on Twitter) pointed me to James Grenning’s Companion games for planning poker.

What I will do differently next time

  • Use a timer that everyone can see
  • Tweak the estimation process to make it go faster
  • Keep a check list of items to do during every sprint
  • Expand Lego set to add some variation

ITSSM Software Development Workshop: Introducing Agile

Agile, Python, QA, Rational Unified Process and Ruby on Rails. IT folk in Sault Ste. Marie got a smorgasborg of technology, tools and processes at the Innovation Centre’s Software Development Best Practices Workshop. I was the warm-up act, introducing Agile and I chose to do that through a learning game. 5 teams worked on a release plan for building a brochure for a tourist resort. Normally I do this over a morning with one team, so scaling to 5 over 1.5 hours was a bit of controlled chaos.

Below are the slides from the presentation

Surving in Tough Economic Times: 20+ Resources to Get Started with Scrum

Recently I had the opportunity to share about my work passion, Agile and Scrum at a local IT group luncheon. I was pleasantly surprised at the level of interest and depth of questions. Organizer John Hatherly told me they had about double the normal pre-registrations for a talk.

Perhaps the tough economic times is behind some of the interest. Agile / Scrum is ideal for these conditions, since Agile delivers the highest value early and often to clients:

  • The product backlog is a list of potential work items prioritized by business value. The highest value items are worked on first.
  • Working software is released early and often, making it possible to go to market faster.
  • Continuous feedback helps ensure the team is delivering what the client needs, and helps the client to better understand their own needs. Requirements are always better understood once there is working software to try out.
  • Regular team retrospectives with actionable items give teams the opportunity to continuously improve.
  • Proven software engineering practices: test-driven development, collaborative programming, continuous integration and refactoring increase quality and lower the costs of maintaining software. Think of software as a liability to maintain.

Jeff Sutherland, co-founder of Scrum stated in a presentation at Agile 2008 that even teams doing partial Scrum, or ScrumButt as he calls it, can increase revenues by 40%. High performing teams can improve 400% over traditional Waterfall teams. That’s a huge competitive advantage at any time, especially during tough economic times.

My search for a video / slide presentation tool succeeded, so now you can watch it again (nothing else to do?) or catch it for the first time. Total length is about 1 hour 15 minutes due to many excellent questions asked (original presentation is 45 minutes).

Here are useful links for people new to Agile and Scrum:

Fun learning



Agile Community


Book recommendations, in order of preference:

Thinking of transitioning to Agile? Contact me to see if I may be able to help your organization or team.

High Performing Teams: What’s the Secret Sauce?

Agile definition and value illustrated. View full size poster

I’m really looking forward to Plone Conf 2008 for many reasons, one of which is presenting on a topic I am passionate about, namely Agile development, in particular Scrum, an Agile software development framework.

What is Agile?

For people unfamiliar with Agile, Scott Ambler defines it concisely this way:

Agile is an iterative and incremental (evolutionary) approach to software development

which is performed in a highly collaborative manner

by self-organizing teams

with “just enough” ceremony

that produces high quality software

in a cost effective and timely manner

which meets the changing needs of its stakeholders.

Scrum, not just for rugby teams

Scrum is a framework that helps teams work in an Agile fashion. Development is time-boxed into iterations lasting 2 – 4 weeks. Each iteration delivers fully working (and tested) software that is “potentially shippable”. Work to be done is defined in a list, or product backlog, prioritized by the client so the most valuable features are done first.

At Agile 2008, I was fortunate to attend Jeff Sutherland’s (co-founder of Scrum) presentation on Agile contracts. His research has shown that teams firing on all Scrum cylinders can generate 400% more revenue than a team using Waterfall methods. (1) That’s some serious competitive advantage. Early retirement, anyone?

(1) See slide 19 of Jeff’s presentation

What do you want to learn about Agile and Scrum?

45 min goes by quickly so I’m soliciting input on my talk in advance. If you were thinking of catching this one, here is your chance to maximize your time investment. Let me know

  1. if you are currently using Agile and to what degree (see the Nokia Scrum test for a self evaluation)
  2. what you’d like to know in particular about Agile and Scrum

What I am thinking of covering:

  • Introduction to Agile and Scrum, if most of audience is unfamiliar
  • How Scrum leads to high performing teams
  • Quick demonstration of Agile tools built with Plone or built by Plone solution providers using other technologies. Pending list: Plum, XM, Agilito, RoadRunner. Anything else that should be in the list? I may use the tools in the other parts of the presentation to illustrate Agile / Scrum practices

We do Agile, but Where is the Quality?

This post is an assemble of notes from sessions at Agile 2008, including Paving the Way for Agile Testing, Expanding Agile Horizons, The Five Dimensions of Systems by Mary Poppendieck, Natural Laws of Software Development – Deriving Agile Practices by Ron Jeffries & Chet Hendrickson plus keynotes from Uncle Bob Martin (Quintessence) and Alan Cooper (The Wisdom of Experience).

There is plenty more to consider than what is written here to on the topic of quality, of course, but these stood out for me in the sessions I attended.

Do the Engineering Fundamentals

Of all the things I heard at the conference, these were repeated again and again, in varying contexts. Why? They are proven to work. Bob Martin argued that these should be embodied in the Agile Manifesto by adding a 5th Value: Craftmanship over Execution. He argued that those who work in software development need to take more pride in their work, and insist on doing the things that must be done produce quality work.


  • Allocate time in advance for refactoring
  • Need to ensure customer understands need to to increase technical debt, even though refactoring may not have “business value”. You either make small ongoing payments to keep debt manageable or face huge debt later. May want to have customer sign off on this.

Test-Driven Development

  • Kent Beck’s definition: First, you should write new business code only when an automated test has failed. Second, you should eliminate any duplication that you find.

Continous Integration

  • Without CI, small releases are difficult to do, integration problems aren’t found until much later.

Acceptance Tests

  • These describe what the stories should do, with real examples that can be executed in code.
  • Need to be automated, becomes more critical after each successive iteration.
  • Acceptance TDD – acceptance scripts written ahead of the code, written by testers and devs, FIT / Fitnesse recommended tool

Need Technical Leadership

From Lean thinking: have a development manager, someone who is a technical leader who is responsible for successful engineering practices. I see this person overseeing the use of the engineering fundamentals listed above. There needs to be leadership in our teams, from both a technical and management perspectives.

Definition of Done is Foundational

Everyone on the team, as well as the client, needs to agree on when a story is considered complete.

  • Define your Definition of Done (DoD) before the first iteration
  • A definition might include:
    • Unit / integration tested
    • All acceptance tests pass
    • No increase in technical debt
  • Example definition at Menlo Innovations:
    • Developer asks the QA/HTA pair for a “green dot”, but before asking, all unit tests must pass, code must work on machine other than developer’s own
  • Keep the definition visible for the entire team
  • Only a strong DoD (with many automated tests) will be maintainable
  • Maintaining a definition of done begins by first building trust. Trust might be demonstrated by granting full access to modify docs and code, providing the tools and support the team says they need. “The first thing to build is trust” – Brad Appleton

Specialized Testers Can Ask Questions that Need to be Asked

  1. Actively seek out defects
  2. Provide feedback, saves time
  3. Test-specific knowledge and techniques, can help others to test better.
  4. Good at asking questions during iteration planning
  5. Can offer feedback on documents and unit tests
  6. Can assist customer in translating requirements into acceptance criteria, writing acceptance scripts

At Menlo Innovations, QAs spend their time (in order of time spent):

  1. Asking questions
  2. Understanding user needs
  3. Understanding development implications
  4. Do some testing

Interaction Designers Can Turn Raw Data Into Useful Requirements

Alan Cooper argued that interaction designers (ID) bring an essential element to the team’s success:

  • Interaction designers can make sense of human behavior in the same way that a programmer can make sense of a computer’s behavior.
  • Their key contribution is translating research into actionable sketches and narratives that programmers can use. Their work frees programmers from communications failures, management misunderstandings, and wasted work. Those sketches and narratives are like user stories except that they are more accurate, more precise, more detailed, more correct, more complete, more readable, and more understandable by managers as well as by programmers.
  • Research shows that users don’t really know what they want or need. Where interaction designers can deliver significant, unique value is in their ability to distill useful answers from the distorted, raw data extracted from, or contributed by, humans. Interaction designers use ethnographic research, user models, scenario construction, role-playing, and other specialized tools for the distillation process.
  • “The operation was a success, but the patient died”. It is not uncommon to have a successful, Agile development project that still fails to satisfy the user.

Other Tidbits

  • A method to prioritize bugs: place bugs in one of 4 quadrants: likelihood of occurrence vs. importance to client.
  • To verify a build:
    • Generate a list of questions, like “Can a user log in?”
    • Answers not provided, as they may change
    • Questions generate conversation

Effective Pairing: Good, Bad and the Ugly

These are notes and video taken from the highly entertaining Agile 2008 session Effective Pairing: Good, Bad and the Ugly. Thanks to Ryan Hoegg, Lasse Koskela, Dave Nicolette, Brett Schuchert for letting me capture them on video. These four guys acted out personalities, scenarios and pitfalls that can occur with pair programming, each skit followed by a room discussion on how to address the issue(s).

I did manage to write down a few of the tips mentioned:

  • Problem: experienced dev takes over pairing work to meet deadline. Keep track of the number of times that one developer takes control of pairing situation to meet a deadline.
  • Promote code team ownership, skill team ownership. Anyone can change (and hopefully improve) any code in the project. The team must take responsibility for improving each other’s skills. Find the time to help someone get better, otherwise one dev becomes an island of knowledge. Tomorrow never comes!
  • Isolated problem or ongoing? Observe if the situation is part of a pattern or a one-time event.

Part One (12 min)

Part Two (26 min)

Part Three (26 min)