kuduTalk

Congratulate me.  I recently learned that I have been accepted as a Certified Scrum Coach (CSC).  I have been wanting to be among the ranks of the other CSCs for a while and it took me a long time to do a complete job with the CSC application (and the time delay had a bit to do with writing the Coaching Agile Teams book, too).  The road was long and the achievement is finally here!

So let me clear up a myth that I believed for a while about professional coaching skills in the agile context (actually, in any context).  Maybe you believe this myth right now.  Here it is: Coaching is “soft” because we don’t tell people what to do when we coach.  Instead, we use coaching skills to help them discover what to do next, knowing that action freely envisioned and chosen by them has a much greater chance of happening.  And, a much greater chance of being a real change – the long-lasting kind.  Just because it feels softer than the “hard” methods of compelling, convincing, persuading, influencing or otherwise controlling does not mean that it is soft — (Read more…)

published by Lyssa Adkins on Coaching Agile Teams

Some late breaking events caused several students in a recent Certified Scrum Product Owner class to reschedule, leaving only five students in the class. I (Lyssa) had arranged for a candidate Certified Scrum Trainer (CST), Brian Rabon, to co-teach with me in this class. He and I had some fancy footwork to do as many of the interactive learning activities in the class wouldn’t work well with five people. Luckily, I had learned a novel technique for teaching estimation and release planning from another candidate CST named Carlton Nettleton. Carlton has students plan how to make a fruit salad with a stack of pictures of various fruits (and a few weird things that are technically fruits but not usually seen in fruit salad). As Brian and I talked about how great this would be as a way for the student product owners to immediately experience the major parts of the product owner’s job, Brian got a devilish look on his face and said, “We should have them make real fruit salad.”

Brian trundled off to buy all kinds of fruit and I called the training center to ask about knives and bowls. “We only have one metal knife,” said (Read more…) manager of the training center, “but we have lots of plastic knives.” “Perfect!” I said, “This is just like real life where you only have one environment in which to test and stage your application.”

Brian and I were the stakeholders. We told the students (aka development team) that we were going to all sit down and eat fruit salad in 20 minutes and that they were going to plan it and make it using agile planning and estimation methods. We specified that we wanted an edible fruit salad that would taste good, be visually appealing and aesthetically pleasing. Here’s what happened…

The development team sorting the fruit from easiest to hardest to prepare during sprint planning. Questions such as “What is this fruit anyway?” were prevalent. At one point someone called the red banana a plantain. Everyone bought into that and they immediately de-scoped it because plantains are too hard to prepare. Too bad, too, because everyone later found out that it was a red banana and it was easy to prepare, tastes great, and would have been a very cool addition to the fruit salad!

The development team hard at work during sprint one. They chose not to assign roles, so everyone pitched in where they thought they could add value. There was some chaos, but pretty soon people started asking for help and everyone was at work.

Lyssa discussing the concept of a “product burn-down chart” immediately following sprint one. The result of sprint one… an edible fruit salad, although not that appealing. There was too much cantaloupe and not enough color. Greg, who is good at marketing and talking to executives, put his spin on their progress and really sold the value of their achievement. Also, the development team didn’t meet their velocity estimate; the cantaloupe took longer to process than they originally estimated.

The introduction of a delighter, the kiwi, and tackling the next highest business value feature, the pineapple, during sprint three. Here Frederick is deciding how to process the pineapple, which was originally introduced during sprint two as additional scope. The development team didn’t take the bait though, but decided to process the pineapple as the highest value backlog item in sprint three.

The development team demonstrates their working product increment at the final sprint review meeting. The development team’s reaction to their accomplishment; “Is it what we envisioned? No! Is it what the client envisioned? No! Will it meet everyone’s needs? Yes! Casualties? Zero!”

Serving in the role of Product Owner (and development team) for a fruit salad requires you to make many decisions that parallel real life. It’s amazing how something as simple as a fruit salad brings up all the hard things a Product Owner will have to deal with and make tradeoff decisions about. Here are some decisions that had to be made in order to develop this fruit salad from a Product Owner’s perspective:

Deciding “What’s in, what’s out?” – was done early on, even before estimating effort. Fruit that wouldn’t “go, like a lemon and lime” or looked “not ripe, like the mango” were immediately de-scoped

The development team made assumptions with the stakeholders best interests in mind (pleasing arrangement, uniform size fruit pieces, etc)

The development team changed effort estimates frequently, often based on individuals’ different ideas of how to process (clean, cut, etc.) the various fruits.

As the time limit of the sprint ran out the team de-prioritized or de-scoped low business value backlog items. Here is an example of a line of thought that emerged, “Now that I can see how much orange color fruit that we have in the bowl, we don’t need to cut and use the remainder of the melon. We need the kiwi instead”.

When we debriefed the experience with the students, the following insights emerged:

There wasn’t much dissension among the development team members. Perhaps this was because making a fruit salad is something that everyone has expertise doing?

Only a few people were left sitting on the sidelines (and, if so, only for a minute or two). The team gelled quickly.

Dominators dominated, but by the third Sprint all were involved in the decision making process.

The skill level of the individual development team members was noticed and they quickly became part of the “in-crowd”.

There were some un-planned and un-anticipated activities (such as having to sanitize not only the fruit, but their hands) that slowed down the overall velocity.

Development team members asked for (and received) help frequently. For instance, “Can someone please clear the cantaloupe from the cutting board?”

###

This Blog posting was a collaborative effort between Lyssa Adkins, Brian Rabon, and the students of Collabnet’s CSPO course in San Francisco, CA on August 24 – 25, 2010.

Contributors:

Michael Doeff, CSPO
Greg Herlein, CSPO
Andrew Hayes, CSPO
Frederic Ducros, CSPO
Satoko Nagars, CSPO
Authors:

Lyssa Adkins is the author of Coaching Agile Teams. She is a Coach of Agile Coaches. Her course offerings and coaching options can be found on CoachingAgileTeams.com.
Brian M. Rabon, CSM, CSP, MSEE, PMP is the President of The Briantrust Consulting Group, you can read his blog, find him on Facebook, and connect with him on Linkedin or Twitter.

published by Lyssa Adkins on Coaching Agile Teams

I am part of the Coaches’ Training Institute Co-Active Leadership program this year.  If you want to really delve into yourself to amp up the leadership qualities that help people know what you’re about so they can follow you, with the flip-side of pruning (most painfully) the parts of yourself that don’t help people follow you then this program is made for you.  It is made for me, through both the glorious and not-so-glorious bits.  Anyway, I digress.

In this program, I met Dan Buchner, an award-winning product designer of products you probably have in your house.  Dan is bringing his message of “design thinking for everything” to the world.  It’s a broader view of design thinking than we usually see in the agile world because it’s not limited to software, or even to consumer products.  And, it’s 100% useful for agile teams.  If you struggle with teams solving “the” problem too narrowly or with uninspired ideas, then be sure to catch our upcoming webinar which offers some new mashed-up thinking about agile and design thinking.

Update: The webinar on August 16th was a resounding success.

Here are actual comments from actual people who actually participated in the live (Read more…)

published by Lyssa Adkins on Coaching Agile Teams