Community and Sacred Spaces within the Agile community. This is a topic close to my heart and one that I am considering proposing for the Agile 2010 conference. I don’t have a format figured out yet. I’m looking for like-minded souls to say a) this is a good idea and b) help me flesh out the concept. I’m open to co-presenting with anyone.

Yves Hanoulle is asking a question each day for people to think about, through his @Retroflection Twitter account. Each day someone is invited to respond, and today I have been asked to answer:

What does being a team really mean (as opposed to the way the word is often misapplied)

To “be a team” in my experience, means to:

• Share goal(s), to have a common purpose for working together
• Commit collectively to getting work done, in a spirit of collaboration
• Respect each other’s differences
• Trust that each person is competent, will raise issues and follow through on commitments
• Have the courage to remove obstacles in the team’s path, including resolving conflicts within the team

Those familiar with Scrum will notice my team attributes are based on the 5 core Scrum values.

These attributes are not easy to attain. It takes time to become a team, and a lot of hard work. Just ask my wife.

Now it is your turn to answer: what does being a team mean to you?

Look around you. Things don’t have to be this way. – Jerry Weinberg, session leader at AYE

Relaxing. Welcoming. Insightful. Practical. Intimate. Grounded. Those were a few of the words uttered last night by some first-time participants at the AYE conference. One person remarked, “[At the end of the conference] I woke up late for my taxi ride to the airport, and was in danger of missing my flight. Normally that would have upset me, but strangely I remained calm.”

AYE is an interactive, small conference focused on people skills and human dynamics (my words). To learn more, I decided to interview myself on the trip home. Here is the (mock) transcript:

Q. Why did you decide to attend AYE Gerry?

I attended the pre-conference session, where I had to answer that question with a drawing, so here it is. Before the conference, I chose a Frisbee to represent who I wanted to be at the conference: active, engaged, giving and taking, being open to wherever I’m directed, having fun. My hope was to be changed personally, to grow in people skills, and in turn impact myself, family, teams and the world. I’m at the point in my Agile coach journey where I realize practices only get teams and individuals so far. Hyper productivity comes not through better processes and tools, but through changed minds and hearts. My logic-driven, analytical mind needs a counterpart to work effectively with people.

Q. What resonated most with you?

Systems thinking

Esther Derby’s systems thinking simulation. This helped me gain a better understanding of the environment teams work in, and what might be impediments / opportunities to bring about desired change. Through a simple scenario of a company making pinwheels, we uncovered many levers for change. Levers come in 3 flavours: containers, differences and exchanges. Borrowing from the HSD Institute definitions

• A container holds a system together as its parts interact to form system-wide patterns. Containers can be physical (team room, office), organizational (departments), or pyschological.
• The significant differences within the container focus the resources of the system and establish the emerging patterns. Some differences matter, some do not. Hair colour probably not that important. Focus on the ones that matter. Look at
• Exchanges among the agents within the container allow for individual and system-wide evolution of new learnings and patterns. Translation: look at the flow of things: resources, language (written/verbal), energy, knowledge, ideas, authority, responsibility, within and between containers.

Building rapport: structuring your conversations

On Tuesday night I had felt some disappointment that I hadn’t had more in-depth conversations with people at the conference. This is partly my own personality weaknesses, so I resolved to work on that for the remainder of the conference. Wouldn’t you know it, the next morning I wandered into Johanna’s structured conversations session, heard her 3 minute what-you’ll-learn pitch and it was as if she was talking directly to me.

I learned the value of building rapport, of connecting on a personal level with someone. Without rapport, you’ll struggle to get to more substantive discussion. My tendency is to want to dive in right away.

People come in many flavours, 16 actually

Underpinning the conference sessions are the work of Virginia Satir, and the Myers-Briggs personality types. Types describe people’s preferences in

• where they get their energy from (extrovert / introvert)
• how they gather information (sensing / intuiting)
• how they evaluate information (thinking / feeling)
• and how they act (judging / perceiving)

My wife will benefit more than anyone from my greater appreciation and respect for people whose preferences are different than mine. I’d like to think I will be more accepting of those differences now. Time will tell.

Meeting Jerry

Two months ago I didn’t know who Jerry Weinberg was. Since then, people have shared how much his writings and workshops have influenced their lives. I valued Jerry Weinberg’s words of wisdom, his challenging questions and quick wit humour. His sessions were shaped more like counseling sessions between himself and a willing participant, with the rest of us listening in, like a reality TV therapy episode. Perhaps the lack of full group engagement was due to his weakening health.

Q. What surprised you?

Most of the participants came from Europe, or so it seemed. Majority of people were there to experience Jerry Weinberg, someone I didn’t know about two months ago. I’m glad I had the chance to be touched by his presence and wise words.

No one except big hotels and fancy homes have green grass. Yards consist of dirt, rocks and cacti.

You can see dry desert, canyons, mountains, forest and snow within 2 hours’ drive of Phoenix.

Q. Was it all good or were some parts meh?

Some simulations felt too abstract to teach me anything. The Satir congruence model didn’t resonate, nor did the session on the Satir change model, which turned into a mini rumble. Felt too meta. Saddened fancy hotels don’t know what vegetarian means, no different than every other non-vegetarian place. When I organize my first conference lentils, beans and tofu shall rule.

Q. Gerry, is there anything else you would like the world to know?

Thank-you to Esther, Steve, Don, Jerry and Johanna (wherever you are standing) for having the courage to be the change you wanted to see 10 years ago by creating AYE. This will not be my last AYE experience.

Everyone at the conference who expressed interest in couch surfing should go there RIGHT NOW and sign up. No excuses. I had a great time staying with Joel and his family, including taking a tour of the country side.

Last Sunday, I had one of my most rewarding experiences as an agile coach. This wasn’t with a software team, as I normally work with, but with a small group of adult friends longing to belong to a vibrant faith community.

For a long time I have been disappointed and discouraged at the lost potential within church congregations, at the hunger for real community left unsatisfied. Most people attending church are not active nor engaged. A few people are doing a lot of work, much of which is not resonating and thrilling. It’s time to re-imagine how we in a faith community want to be in relation to one another, what we want to strive for together. We must take responsibility to create a healthy, vibrant community. For those who gathered on Sunday, this was the first tiny step on that journey.

Agile thinking and the Scrum framework have shown me that the processes and control structures we use greatly influence the values embraced and outcomes achieved. For our session I wanted to avoid it turning into a long rant of everything that is perceived wrong with the current situation. For me the goals of the session were:

1. to find common ground across our individual experiences
2. to establish a vision for the faith community experience we long for
3. and to identify some steps needed to work towards that vision

After a hearty potluck meal, we began by sharing in a few words why we came and what we hoped to get out of our session. I then introduced the Remember the Future game, one of Enthiosys‘ Innovation Games. The game helps people to define an end ‘product’ by looking at the steps in reverse. As humans we find it easier to understand and describe a future event from the past tense over a possible future event, even if neither even has occurred.

I asked everyone to pretend it’s a year from now, October 2010. were part of a vibrant faith community. Describe what it looks like. Jot down steps that were needed to get there. Each item was written on a separate sticky note. After 10 min of brainstorming we posted our stickies on flip chart paper and looked for emerging themes. From that process, four groups emerged. Taking the time to label each group brought deeper awareness of what matters to us in a vibrant faith community.

People became more comfortable sharing and participating as the evening progressed. I had hoped to continue the evening with the Sailboat game, a variation of the Speed Boat Innovation Game. This exercise would help us identify obstacles and opportunities towards reaching our goal of a vibrant community. Since time was running out and our kids were no longer interested in the movie they were watching, we skipped that and finished with an exercise to determine what to do next.

Circle of Questions is a retrospective activity from the book Agile Retrospectives by Diana Larsen and Esther Derby. In this activity, the group sits in a circle, and going around the circle, each person takes a turn asking a question to the person on their immediate left. The question can be about anything they like (barring anything offensive or attacking). The person to the left answers the question to the best of their ability, and then they ask the person to their left any other question (or the same question if they feel they’d like a better answer). This continues until the allotted time is up, or until you have gone around the entire circle twice, whichever comes last. (Thanks to John Wilger for the writeup)

The goal for our activity was to decide what to do next. What transpired was a deep sharing of desires, needs, struggles and hopes. Four guys being vulnerable to one another, listening attentively as each person took their turn. No fluffy stuff, no lighthearted chit-chat. This was a taste of that vibrant community we seek.

So what’s next? I plan to invite another group of people to go through the same exercises, and slowly build a group motivated and empowered to reach our goal. We’ll gather everyone together in about a month, again around a shared meal, and start to discuss community models already out there. Hopefully each gathering will contain the elements of lives connected, spiritual partnership, bonding mission and positive power.

This small experiment was a moving, powerful experience and we were only a group of 4. Imagine if this was done on a big scale with a congregation. We might find the shared vision and motivation to make a vibrant community a reality. I remain hopeful and determined, feeling called to use the gifts from Agile coaching to transform both places of work and worship.

Nurse, what am I supposed to remove again?

A recent study shows that surgical errors are reduced by a whopping 40% by using a simple tool: the checklist. The checklists focus on what to do before, during and after the surgery.

The state of Michigan alone reckons they save 1,500 lives a year and $200 million (in malpractice suits – joke).

I’ve found that teams also forget some of the little but essential steps which creates waste through increased mistakes and delays. Lists are especially helpful for teams and product owners who are transitioning to the Agile process. So today I created some Scrum ceremony reminder lists to help the team I am coaching and I’m making them available for anyone to use under a Creative Commons license. Let me know how they can be made better.

View and download Scrum ceremony reminder lists

Update Sept 29: Reformatted lists to print on 3 sheets of paper, 0.5″ top and bottom margins. You can print all your check lists for one sprint except for the stand up meeting on one double-sided sheet of paper.

Demo during Lego Scrum simulation. Everything goes better with Lego.

What is a sprint demo?

Agile teams using Scrum work in a time box called a sprint to get software built early and often. A meeting is held at the end of each sprint with the whole team including product owner and anyone else who would like to attend. The goals of the demo are to:

1. Demonstrate work is done done. Nothing like taking work for a test drive to see if there is more than chicken wire holding pieces together. Teams demonstrate that acceptance tests pass. Acceptance tests are the product owner’s requirements for a user story to be considered done. I agree with Ron Jeffries‘ view that acceptance tests provide clarity, remove subjectivity over whether a story is done or not.
2. Generate new insights. Seeing and interacting with real software leads to new insights. The client might want new features or enhancements, or realize a corrective change in direction is needed. The product owner has new information on a regular basis to adjust priorities going forward.
3. Progress report. Forget Gantt charts. Seeing the product is the best method for a senior manager to know where the project is at.
4. Team satisfaction. Demos give the team a sense of accomplishment, satisfaction from positive feedback and the client accepting stories. There is also greater confidence in the project’s direction based on feedback.

How to prepare

One or more persons on the team is responsible for presenting the demo of completed stories to the client and the rest of the team. Note, only completed stories are demoed, no recognition for stuff 90% done.

1. Don’t use slides, show real working stuff with ‘just enough’ prep work. Preparation should take no more than an hour for a two hour demo.
2. Plan your demo in advance. Write down the steps you are going to use, and try them out. Make sure the demo is going to work as expected. You’ll look much more professional and the demo will go faster, plus no surprise ‘gotchas’.
3. Use acceptance tests for the basis of the demonstration. Bonus points for automating those tests ahead of time and running the script (at slower speed) during the demo.
4. Know your agenda. The simplest approach is to go through completed stories in priority order.

5 tips for demos by distributed teams

Distributed teams face additional hurdles to giving demos… time lags, less interaction, limited presentation options. Here are some tricks I’ve learned after 3 years of facilitating distributed demos:

1. Test drive without the blindfold. Save time and improve the experience by using a screen sharing tool so everyone can follow along – much better than walking others through a series of clicks and hoping they see want you want them to see. Screen sharing tools that work well and cost little or nothing include Yuuguu, Yugma, and DimDim. Newer versions of Skype offer desktop sharing, though you can’t do video conferencing with Skype at the same time.
2. Remove distractions. Nothing like having your buddy’s IM rant about last night’s hockey game appear on the screen to lose momentum. Close any applications that use pop-up notifications. You don’t want those interrupting the demo. Better yet, close all applications you won’t need for the demo by default so your machine runs optimally.
3. Hearing is everything. I’ve suffered through too many conference calls with poor audio quality. While Skype and some conference calling services are free, you get what you pay for in my experience. I’m a fan of HiDef Conferencing, which supports phone and Skype participants on the same call. There have been a number of times where we’ve jumped onto HiDef after a client’s service ran into problems.
4. Test tools ahead of time. Make sure everyone knows in advance what tools will be used and what they need to do to set them up. Make sure first time users test the tool ahead of time, perhaps a scheduled time before the call so you can help troubleshoot. Avoid the 15 minute scramble at the start of a call to fix issues.
5. Provide an agenda. If everyone has access to the team task board, use that to walk through the list of stories and their itemized acceptance tests. If not, send out an email beforehand with the list of stories to be shown, and any relevant links that will be shown during the demo. Make it as easy for people to follow along and keep up. Alternatively, show the agenda to everyone after each completed step via screen sharing tool.

Bonus tip: Don’t forget to turn off screen sharing when you are done, before you start reading your email.

Do you work on a distributed team? What are your tips for giving effective demos?

Team task board

A new client of mine new to Agile has the entire team located in one office except for one person, a DBA living in Texas, one time zone away. I want the local team to benefit from having a highly visible team task board, which usually means cards/stickies posted on the wall like the picture above.

At the other end of the spectrum, the remote member needs to be informed of sprint progress, to know what tasks to do and to update the tasks he is working on. That level of interaction usually means everyone has to use a digital tool, which in this case seems unfair to the local team’s productivity and communication, given all but one are local.

The best solution, of course is to find some way for that person to move locally. It’s not often that will happen, but moving is the first option to consider. The cost of having a remote team member is borne by the full team, so make sure the remote person adds enough value to justify the cost.

I then went on Twitter to ask for suggestions, and got two, based their experiences:

• Rick Scott (@shadowspar) has worked as a remote team member for several years, mostly as a tester. He suggests using a web cam focused on the task board, or take pictures and post on a project wiki.
• Andy Brandt (@andybrandt) proposes projecting a digital team board on the wall. The digital tool gives the remote person the means to update his work and get details like acceptance tests to do his work. The local team benefits from a highly visible task board.

My thoughts on these approaches:

• Rick’s suggestion is ok for seeing the overall picture, but doesn’t go far enough. It’s hard to see all the details on stickies from a picture, and acceptance tests are often written on the back side of a user story card. Writing all details on the front is an easy modification, but that doesn’t solve the problem of seeing everything clearly. The remote member still has no easy way to update his progress either.
• Andy’s idea seems like a good compromise. Everyone can access and read / update the same information. The local team has their highly visible task board. The key drawback is all changes are made through a tool. Mike Cohn feels that the difference between the two approaches is dramatic.

Idea: Synchronize physical with digital

I asked Mike Cohn for his insights on this topic, and he responded with a great post. The solution he proposes is to have the Scrum Master synchronize a physical task board for the local team and an electronic version for the remote person:

A shared spreadsheet is normally sufficient for this, but some teams opt for a more specialized tool, which is fine. Many tools offer 5-10 user free licenses and since the tool is only needed by the ScrumMaster and one remote employees, the free license is adequate.

Mike then suggests using a marker system to minimize the effort needed to keep the two versions in synch. The Scrum Master then only has to update the flagged tasks, saving her time. This can be done using post-its or coloured dots. The Scrum Master simply removes the markers after updating the tasks.

Derek Mahlitz, a Scrum Master for a team with one remote member confirms this approach is effective for his team:

We do this exact process for my team. We have 7 members in 1 office in NY and 1 member at home in FL. The collocated team updates our task board and I (SM) replicate in an Excel spreadsheet that is stored in our sharepoint solution. That way he can keep up with the tasks. We also do video for daily standup and all collocated team members have webcams for quick meetings throughout the day with FL home worker. We are a year into scrum and this has worked great without issue.

Out of all the solutions I’ve heard, Mike Cohn’s seems like the best approach without extravagant spending on touch screen surface hardware. My client suggested trying a Wii controller to update a web-based task board projected on a wall. Can’t go wrong in trying that. 

I consider Mike Cohn one of the best on the topic of Agile estimation. His 90 min presentation on how to estimate is well worth your time. I took his one day course and all of the material in the presentation appears to come from that course.

Mike is truly inspired to find the best ways to estimate. He once forced each of his teams to pick a different method of estimating, too see which would win out a la Estimating Survivor.

Learn why relative estimating is better than absolute, how too much information can lead to poorer estimates and get good at (planning) poker plus a whole lot more.

If you are thinking about attending the Agile one day work shop at Plone Symposium East, register by end of today, April 30 to get free bonus coaching after wards.

Contact me if you have any questions about the course.

So you’ve gone over requirements, and have an idea of what needs to be done, then the client/project manager pops the question developers dread:

How long will it take?

Then, depending on your situation, you might:

• Give a number based on gut feel
• Look at historical numbers for something of a similar size
• Call a psychic hot line
• Break down the job into smaller tasks and try to estimate those

No matter what your approach is, estimating is just plain hard. Is there hope?

Estimate in two parts – part one: relative sizing

How big is each dog compared to the other? Photo courtesy http://www.flickr.com/photos/andreyevbr

It turns out that we humans are pretty good at relative estimates. We can compare two or more items and agree quickly on the size of one compared to the other. Take these dogs, for instance. How much larger is the labrador on the far left compared to the poodle on the far right, assuming by large we mean height? If we gave the poodle a relative size of 2 compared to most dogs, we might say the lab is a 5. We can then give a relative number to each dog without too much effort.

Now if I were to ask you for the specific height of each dog, we’d have a much harder time both estimating and agreeing on the final number. We’re not so good at actual estimates. Estimating helps us plan, but we don’t want to spend so much time on it that the cost outweighs the benefit.

Now imagine if each of those dogs was a small feature of a system your team plans to build. We’d then have a list of features each with their relative size, and a total size for all features. That gets us the first part of estimating, that is, how much work there is to do, but we still don’t know how long it will take to do the work.

Part two: how much can we get done in a specific amount of time?

For reference sake, let’s call our unit of measure ‘points’. We can determine how long a project will take by dividing the total points by an estimated velocity. Velocity is the rate at which the team completes work. For instance, one team might be able to complete 40 points of work on average over 2 weeks. If total points is 200, then the team will need 10 weeks to complete everything planned:

200 points / 40 points every two weeks = 5 * 2 weeks = 10 weeks

So how do we determine this velocity?

There are several ways to do this, but a simple way to get started is to take a random or representative set of stories (what features are called in Agile), break them down into tasks, and then estimate those tasks in hours.

Let’s say a team that has 100 hours in a 2 week sprint. They take a sampling of stories and come up with the following estimates:

• Story A (13 points): 20 hours, 20 hours total
• Story B (8 points): 15 hours, 35 hours total
• Story C (5 points): 10 hours, 45 hours total
• Story D (13 points): 20 hours, 65 hours total
• Story E (8 points): 15 hours, 80 hours total

At this point, the team feels they can’t take on any more stories for the sprint. They leave a 20% buffer for the unexpected.

The total points planned for the sprint is 47 (13+8+5+13+8).

The team will need a little over 4 sprints to finish, so let’s call it 5: 200 points / 47 = 4.3, or 5 sprints.

We can also determine worst case / base case scenarios, based on how far along we are into the project, using what is called the Cone of Uncertainty principle. Mike Cohn talks about how to apply this in his book.

Bonus: now we can calculate project cost easily

We can also calculate the cost of the project by totaling up hours for each two week time box, or sprint as it’s typically called in Agile. If the team spends 100 hours every 2 weeks at an hourly rate of $100, then each sprint costs $10k and the project cost is expected to be $50k:

2 week sprint cost = 100 hours * $100 / hour = $10k

project cost = 5 sprints * $10k = $50k

I’ve tried to illustrate some simple techniques to create better estimates. Break the task into two parts, first calculating the size of work and then the speed at which work can get done. There is a lot more to estimating that I haven’t covered here. If you’d like to learn more, I’m hoping to offer a one day Agile course at the upcoming Plone Symposium East. If you can’t make it, please post your comment / question below.

If you are going to the Plone Symposium East, or considering going, this post is for you.

I’m offering a one day course on the fundamentals of Scrum, the most popular Agile software development framework. It’ll be a fun, hands-on experience, using games instead of Powerpoint slides to teach.

The catch is I need 10 people to sign up to make the trip and effort to prepare cost-justifiable. You see, I would be going mainly to the Symposium offer this course. Agile is technology agnostic, so while I am an active supporter of Plone, I don’t need to brush up on my buildout skills or learn the ins and outs of deploying Plone at a university (though I’m sure Calvin and Michael will give insightful and entertaining talks). I want to offer something back to the Plone community, and Agile is what I know best. Reconnecting with Plone peeps over beers comes a close second.

My passions lie in helping others, and I get my satisfaction in helping individuals enjoy their work more, teams becoming more productive and clients pleased with the result. I get to support teams as they embrace more fully Scrum’s five core values: commitment, focus, openness, respect and courage.

Is it Worth the Cost?

At US $250, this is the most expensive training option on the menu, but compared to other Agile training offerings, this is a bargain rate. No, you won’t be a super high performing team after one day of training, but you’ll leave understanding a flexible framework you can use to:

• Know at each step how the project is progressing (amazing, but true) and use simple charts to communicate progress to the team and client
• Get far better at estimates
• Adjust the plan with minimal effort, even late in the project when your client wants to make 50 “minor” changes before launch
• Lower the overhead of managing projects
• Keep developers happy by coding more, sitting in killer meetings less
• Lessen the impact of context thrashing, that is doing too many projects / tasks at the same time
• Get an agreed upon definition of done to avoid subjective back-and-forth wrangling
• and the list goes on…

Plus don’t forget you get to play with Legos for half the day. What could be better?

Web Collective shows off their Lego creations during sprint demo

Group Discount

Scrum is for teams, so to make it easier for companies to send more than one person, I’m offering a 10% discount for each sign up, including the first one. That’s a $25 savings per person. I haven’t figured out how to do that within the event registration system, but I’ll get it to you one way or another. To qualify, you do have to work for the same organization.

Decide By April 30 and Get a Bonus

I need a few more sign ups by the end of this month before committing to buying plane tickets. Will you join me the Symposium? Anyone who signs up by the end of the month can join me for dinner after wards where we’ll dive more in depth on the issues / topics that matter to you.

Special Offer: One-on-One

Want even more help? You can either try and corner me at a pub for free (though quality of responses may be diminished) or join me for a one on one hour session to answer any questions you might have, talk through whatever issues/challenges you are facing. Make your list and get your own personal Agile coach. Email me if interested.

Register for course

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 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.

The city of the future, built by Web Collective

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

If you are going to the Plone East Symposium, I am planning to use this same simulation as part of a full day course on learning to become Agile. There will be plenty more learning activities If you are interested in attending, I’m looking for enough people to indicate commitment before planning to go, so please cast your vote.

Update: Poll is now up! Vote right here:

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

I’ve noticed some debate lately about Lean vs. Agile. Machiel Groeneveld covers the debate well on his blog.

My perspective is that Lean is within the Agile family, and makes Scrum more effective by focusing on reducing waste.

What is your opinion? Cast your vote and add your comment to this post.

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

• Scrum cartoons
• Learn Agile by playing scenario games
• Scrum, the board game
• Agile games for making retrospectives interesting

Reference

• (PDF) Scrum in 5 Minutes is a quick digest of Scrum for sharing with others.
• (Video) Scrum in Under 10 Minutes for those preferring visual stimulation.
• Agile Manifesto
• Scrum diagram and overview
• This poster captures the essence of Agile software development. I have it on my wall.
• Scrum glossary of terms
• Succeeding with Agile: A Guide To Transitioning – video and slides from Mike Cohn

Tools

• Play planning poker online, or order some cards
• Agilito, a Django Scrum tool we developed at ifPeople
• Assess the Agile practices your organization is ready to adopt.

Agile Community

• Agile Alliance (I’m a member) and Scrum Alliance (my member profile)
• Scrum discussion list is a great place to ask questions and get answers from prominent people in the Agile community. I’m subscribed.

Books

Book recommendations, in order of preference:

• Agile Estimating and Planning by Mike Cohn
• User Stories Applied: For Agile Software Development by Mike Cohn
  
• Agile Retrospectives: Making Good Teams Great by Esther Derby, Diana Larsen, Ken Schwaber
• Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck, Tom Poppendieck
  

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

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