Well, we just had to follow-up this year to see how right (or wrong) we were and to throw out some prognostications for 2012. Enjoy the ScrumCast special episode 2012 Predictions.

Business Value

The organizers suggested a presentation that would “show how Agile practices provided business value.”  Well, that’s certainly something that I promote and believe!  I used my year old presentation from a Brown Bag at Gangplank as a base to something better:

Answering Questions

The event was very well attended.  The number of people looking, doing, implementing Agile practices in Phoenix is definitely on the rise!  The 15 minute question time after my presentation was filled with insightful discussion that showed experience.  Just before lunch, each vendor presenter and myself continued to answer questions as a panel.  We could have gone on and on I think, except lunch was ready.

I’m excited by what I saw at the event.  Many people working to improve, figuring out how Agile practices can benefit them and their work.  I hope they find the success they need, with me helping or not!

My Mentors

• Don Dayley, my father – Taught me all the foundational things in life, including how to mow the lawn when I did not want to, sometimes through uncomfortable methods.  He also gave me an unsurpased example of attention to craftsmanship.  Everything he builds or repairs is better than new when he is done.
• Mrs. Fedler, 4th grade teacher – I found most of my first three years of public school boring.  Mrs. Fedler found ways to show me that learning itself was fascinating.  And she showed me that exploring the boundaries beyond expectations was praise worthy.
• Mr. Douglas, 11th grade chemistry – THE hardest teacher I ever had, including college.  The scientific method, analysis, reporting, supporting conclusions based on facts and failing with good humor are among the things he taught me.  Ask me why he sometimes called me “Beaker.”
• Pedro Brassinini – Taught me to love strangers more than I ever dreamed possible and to feel compassion deeper than I had known.  And how self-sacrifice brings inner rewards.
• Bill Sheppard – My first engineering boss was hard and understanding with me, a green engineering student.  He showed me that trust is part of doing my work well.
• Kevin Kilzer – A brilliant engineer of software and hardware.  He harnesses passion for the work like no other coworker in my experience.  Creativity fueled by inner fire is awesome.
• Mike Vizdos – A guide over the years of my journey into the Agile and Scrum world.  Quiet thought is a powerful tool, which he knows and shows how to use in all his work.
• The Ignite Phoenix Team have shown me Agile collaboration skills and community building prowess that I hope rubs off on me.  (Don’t tell them they are Agile, they’d get too self-conscious.)

I could go on with more mentors, some who don’t even know the little, important things they have taught me.  You should take some time to make your own list, even just mentally.  You have had some great mentors too, or you would not be where you are.

Gangplank Mentor

Before I knew January was Mentor Month, I was invited to be a member of the mentor team at Gangplank.  I’m one of the mentors on business operations.  Once a month, more often when I can, I’ll have office hours at Gangplank.  You can book a 45 minute session with me to ask questions about Agile and Agile frameworks like Scrum and Kanban.

My first mentor day is in the afternoon of Tuesday, January 25th.  No fee, just set your appointment with the Gangplank Director of Operations and let’s talk about taking your operations to the next level.

I can’t necessarily give back to all the mentors in my life.  But I can give to someone, who can build something great and give to someone else!

Recently Mike called for people to submit articles to his blog at ImplementingScrum.com.  He uses cartoons to highlight and teach about Scrum and it’s use.  Accompanying each cartoon is his text educating about the point of the cartoon.  His invitation to guest post suggested going back through the older cartoons and writing your own commentary about the action in the strip.

I took him up on his generous offer.  I choose the cartoon Scrum = Scrum as my subject.  I took a different direction than Mike did, back when he originally wrote it.  I wrote on the current discussions about changing Scrum from it’s original definition.

He posted my guest article last week at Scrum = Scrum (It Still Is).  Please take a visit, read and comment on the value of “plain vanilla Scrum” in today’s working world.

@estherderby If there was only 1 agile practice what would it be for you? For me, it would be retrospectives as they are foundational.

I fully agree that retrospectives are the one powerful Agile practice to do if no others are yet implemented.  I posted:

@estherderby The first retrospective we had was stilted and shallow. And it improved the culture of the team dramatically!

As I posted that brief message, I knew a blog post was needed to fully explain the strong statement.

Getting To Retrospective

The team had been doing “Scrum” for some weeks.  I put Scrum in quotes because we really were not doing enough of the practices to use the term.  Key members of this team and engineering management were not fully committed to Agile and Scrum.  We were adopting practices slowly, as the acceptance of these key players allowed.  We were doing:

• Weekly Sprints
• Weekly planning meetings
• Daily team status meetings, like a daily Scrum
• Using a team board with tasks

I had been requesting that we start doing retrospectives, even just do one to try it out.  The biggest objection was the perception that it would be a waste of time on a “feel good” measure of little value.  Percistent discussion and pointing out the well known desire to gather “lessons learned” finally prevailed.  We scheduled one retrospective as a test.  Maybe they just wanted to stop me asking.  Whatever works, right?

The Culture

Prior to beginning our migration to Scrum, this team had a very traditional structure.  A brilliant engineer was the Team Lead.  He determined tasks for each of the team members.  As we started doing sprints and team level planning, this lead continued the practice of defining tasks for each team member.  We shifted to emphasizing that each team member needed to accept the suggested tasks.  The reality remained that the Team Lead was determining the work of the team.  (This practice was not Scrum, nor Agile.  A dicussion of the value of such a slow shift to Scrum is another blog post.  Or an essay!)

Several members of the development team were quiet.  When discussing development one-on-one, they had great ideas and interesting things to say.  When in the team meetings, they were largely silent and simply agreed with the more dominate personalities in the group.

The Setup

I chose our Training Room as the venue for the retrospective.  This is also the same room where sprint planning meetings were held.  Usually the room has four tables pushed together in the middle of the room to form one large table with 12-14 chairs around it.  For most meetings this arrangement is appropriate but for others, it is not conducive to the meeting goals.  (See http://blog.dayleyagile.com/2009/02/23/the-real-elephant-in-the-room/)

I split the tables appart, pushing them out to the edges of the room with the chairs lining three sides of the open space in the middle.  The team board showing the task cards for the sprint just ended was positioned at the front on the wide marker boards, now erased and ready for writing.  Sticky notes and pens were liberally sprinkled around the room for attendee use during the meeting.

The Meeting

During the meeting several notable things occurred.

• As attendees arrived they made comments about the organization of the room.  Some were quizical, some were intregued.  Two who brought notebook computers were unhappy at the lack of a table for thier electronic distractions.
• I asked each attendee to state what value they though they could get out to the meeting.  Their responses were interesting.  More important was getting each of them to talk so each would be more likely to speak up during the meeting.
• Each was asked to write sticky notes of what went well and what could be improved.  This minimized the effect of dominating personalities and ensured that everone had the opportunity to contribute.
• Dot voting with performed to find the top improvements to work on.  The Team Lead was particularly irritated that his three dots were not enough to force his desired improvements to the top of the list.

Immediate Changes

As I think about it today, this retrospective was not particularly effective for the practical work of the project.  We did not even execute well on the choosen top improvements.  The team member interaction started changing from that day forward.

• Everyone contributed at a team meeting, maybe for the first time.  And it was not just the individual answer at the beginning, though I’m sure that opened the door.  Every person provided sticky notes and comments throughout the meeting.
• Several times comments along the lines of “I didn’t know you thought that” were heard.  The following planning meeting that afternoon was more lively than ever.
• Right there, in the meeting, the Team Lead role began to be absorbed into the team.  This was difficult for the dominate personalities to take but the “human side” of the team started forming in a positive way.

Retrospective Power

As time went by, this team began to gel further.  Participation in the meetings and with each other increased.  The team unified further, more easily able to request changes from the larger organization.  We also had serveral meetings that dove to the heart of individual difficulties, something not possible without higher levels of trust.

Several of the dominate personalities eventually left the company, perhaps in part as a side effect of at more egalitarian team environment.  We continued to have retrospectives and attempted to apply the actions to improve our work and team.  This team eventually produced the product and has now moved on, mostly joining into a team designing our next generation project.  Retrospectives are a key part of the work and we never skip them, ever.

If you are doing a slow adoption of Agile practices and must pick only one practice, do retrospectives.  Do them regularly and with serious attention.  Daily meetings, sprints and team planning are powerful and look easier to start doing.  Real change on with the team’s human dynamics really happen when the retrospective becomes part of your habitual practice.

The videos of the Developer Ignite 2 presentations have been posted. Watch the video of my presentation, titled “The True Measure of Agile,” and tell me what you think!

Abstract: The Agile wave is washing over the software development world and lapping at the shores of all creative endeavors. There are buzzwords, expensive software and training consultants a-plenty! What does it really mean to be Agile, with a capital “A”? If you have daily stand-up meetings and iterations, are you Agile or just covering old ways in trendy veneer. Iterations or not, you are Agile ONLY if your actions support the principles of the Agile Manifesto. Let’s take a quick look at the practical implications of THE yard stick of Agility. If your actions support this powerful statement of human interaction, you are Agile, even if your daily “stand up” involves chairs!

Don’t miss the other presentations too. The introduction speech is a good place to start.

Last week I conducted a workshop centered on the Product Backlog.  The focus was to help engineering understand the purpose, position and power of a properly groomed Product Backlog.  In attendance was about 20 people from engineering, engineering management to the VP level and from marketing.  The session went well, with several good conversations sparked during and after the meeting.

And, I learned something.

It’s hard to have a Product Backlog discussion without talking about estimating the stories.  I was using slides from one of Mike Cohn’s excellent “Agile Estimation and Planning” presentations.  The presentation includes a discussion of story points.  From previous conversations, I knew the group might have a hard time understanding the concept and value of story points.  They are used to trying estimates of real time.  Going into the discussion, I was not sure how to show them the value of story points.

We had a break just before the section on story points.  Knowing a slide for estimating in “Zoo Points” was coming up, I wrote a chart on the easel in anticipation.  The first column I headed with “Animal.”  I then solicited volunteers from the early arrivals and put their names on four additional columns.  They laughingly questioned what the animal heading was about.  I told them to wait and see.

We discussed the concept of a story point and hit the “Zoo Points” slide.  Asking everyone to quietly estimate each animal, I wrote the animal list down the first column.  Immediately questions were raised as to the scale or criteria that should be used to estimate the animals.  I reminded them, while writing the animal list, that story points don’t have units.  Some were quite puzzled.

The resulting "Zoo Points" table

I asked each of the four volunteers to tell me their estimation numbers in turn.  All but one provided reasonable numbers of less than ten, even though I had not told them what scale to use.  The fourth volunteer gave them all a five, claiming to not understand.  That was fine.  In discussion, we noted that the scale used and many of the values correlated, even without knowing what each person was using for criteria.  I then asked each volunteer what criteria they used, writing their answers at the bottom of their columns.  Size, danger, strength, etc. were among the answers.

As I wrote the different criteria, my epiphany occurred.  I excitedly stated it to the group as it had formed in my mind:

Unit-less story points allow multiple criteria to be included in the estimate without excluding ANY possible criteria.

If we had started out with a defined list of criteria, the list tends to exclude all other criteria.  It narrows and shuts out possibly important input.  For example, suppose the Product Owner were to state that estimation must take into account story size, difficulty and performance.  A team member will tend to naturally drop other criteria, such as maintainability, domain knowledge, architecture impacts and so on.  Unit-less story points make it easier to obtain all the criteria that concern all members of the team.

A secondary epiphany came quickly:

Unit-less story points allow these multiple criteria to be considered and included very efficiently.

The team can discuss all the criteria used by each team member to come up with their estimate.  But they don’t have to.  Each member could be thinking about completely different concerns, but if they all estimate a “five,” for example, discussion of the concerns is not needed.  All the criteria are built into the number without requiring discussion and argument about which concerns are more important.

Combining these values of story points with the efficiency of planning poker, the team can move on to getting more work done.  Maybe I should have seen these powerful aspects of story points before.  But I didn’t until standing in front of a powerful group, teaching and looking at story points in a new way.

The learning goes on!

And real business life sets in to create disturbances in the sprint.  Let’s look at a hypothetical but realistic situation where sprint disaster can strike.

Suppose there are two teams working on two projects.  Sprint after sprint the teams productively work down their backlogs, end with demos or reviews of what is now done and plan for the next iteration.  One afternoon in the middle of a sprint the department director calls a meeting of the teams following their daily stand-up meetings.

“As you know, ‘Old Yellow’ is our bread and butter product right now.  It’s earnings fuel the new product development you are doing.  BigCorp is our largest customer using Old Yellow.  They need A Great Feature added to Old Yellow right away.  We need to keep working on the new products but if we don’t satisfy BigCorp we’ll be in deep financial trouble.  We need to pull Joe and Tom from project New Blue and Lisa, Nancy and Ashok from project Shiny Red.  They will work on A Great Feature starting tomorrow.”

There is danger here!  The director has asked to pull people off their sprint teams in the middle of the sprint.

• Team self-management takes a hit.
• The sprint plans are in shambles.
• Velocity measures for the teams, for that sprint, are devalued.
• In short, aborting two sprints to start on something else right now is a bad thing to do!

In an ideal world the company would have enough people to handle sustaining efforts so the teams doing new development can stay focused on their iteration and release plans.  But special projects that cut into new development sometimes cannot be avoided and ideal staffing is rarely available.

Let’s return to our difficult stituation.

The ScrumMasters and Product Owners react negatively to splitting their teams, as they should.  One ScrumMaster wisely speaks up, “The teams are in the middle of sprints.  Can we leave the teams to complete their current sprints?  Then we can properly plan the development of A Great Feature for BigCorp with people dedicated to the solution.  Let me draw it out for you.”

Handling a special project

The ScrumMaster continues, “Doing it this way protects the results of the current sprint.  It also provides for clear planning of both subsequent sprints and for development of A Great Feature.  The two current teams will be slower in their next sprint because they are smaller teams but they will now have a plan for that case.  And, A Great Feature will be completed sooner with a dedicated team working on it.”

Nodding, the director says, “Our relationship with BigCorp is excellent.  I’m sure we can explain to them the benefit of a short start delay so they can have a dedicated team working on the new feature.  In fact, I bet they will like that idea.  Great job, everyone!  We’ll lay some ground work so information is ready when your current sprint completes.”

Ah!  Happy endings are so nice!