Category: Agile

AYE 2009: People, process and tools, in that order

Posted on by in Agile

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.

Can Agile transform faith communities?

Posted on by in Agile

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.

Avoiding mistakes

Posted on by in Agile

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.

5 tips for effective sprint demos by distributed teams

Posted on by in Agile
Demo during Lego Scrum simulation. Everything goes better with Lego.
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?

Options for team task board when one team member remote

Posted on by in Agile
Team task board
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.  🙂

Agile Estimation [Video]

Posted on by in Agile

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.

How long will that take to get done? The dreaded question

Posted on by in Agile

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

Happy team, satisfied customers

Posted on by in Agile

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