Innovation In The Team

Agile teams that are working well are fountains of innovation.  They concentrate on their backlog, crash thoughts and technology together and keep creating product increments that win. Each day can be hard work and fun.  If you approach a the team’s room or work area at any given time, you might see:

• Conversations in pairs or small groups.
• Gestures, pointing and passion about what is happening.
• Stuff on the walls that show information about the state of the work and the goals of the product development.
• Laughter, back slapping and sometimes concern and disagreement.

Innovation In The Company

These same signs of innovation can scale up into the rest of the company.  If you walk through the marketing department, operations or accounting, the energy level is also high.  The work that must be done may be much different than software development and yet the feel, the engagement between people, will tell how much creativity is happening.

Innovation Pocket Problem

I have seen many teams that are rocking the creativity and pushing the innovation envelope.  Then they try to release or attempt to change their seating arrangement or hang something on a wall.  And they encounter the boundaries of their pocket, the organizational impediments that prevent the full power of their work to flourish.  For example:

• The team is creating shippable software nearly every sprint but deployment takes six weeks.  End user feedback is broken.
• Enhanced communication from information radiators is squelched before the benefits are even tested.
• Layers between the team and the customer prevent focus on features that would delight the customer.

Innovation Check

If you are a manager or otherwise in a position to help, periodically make a visual and feel check of your environment.  Walk around and talk to people in different departments.  How does it feel?  Is there innovation visible and creative energy present?  Would a visiting customer walking through your offices see and feel innovation?  Does your environment and processes back up your claim to be an innovative company?  Is the creativity self-evident just by looking around?

If not, what are you going to do about it?

Let me set the stage a bit.

The Penny Game

The Penny Game is a fun way to help people experience the effects large and small batch sizes and other lean ideas.  The basic action of the game has the participants flipping and passing pennies from one person to the next.

Rather than explain it all here I will point you to the web.  The simplest version and description I quickly found was on the Crisp blog.  If you are not familiar with the game, read the description there to better understand what I describe below.

The Clever Twist

The first “Worker” in the game was a programmer, a clever programmer as it turns out.  The first batch size was 20 pennies. I said “Go” and he proceeded to make a heads up stack of all his pennies.  A single stack!  He then carefully flipped over the entire stack at once, instead of flipping them one at a time.  He took a while to do this, as you may imagine, so I was not worried yet.

Then, he carefully handed the entire stack to the next person, who flipped all 20 pennies over at once, as a stack! Now I was worried because each successive “Worker” did the same, each saving a lot of time for a large batch size.  I worried that the point of the game would be lost since the numbers were not coming out as expected.  I told the class of my surprise and worry. I told them not to stop, let’s run the experiment!

The Results

The usual results of this game show that smaller batch size results in significantly faster delivery to the customer.  What do you think happened in this case, with flipping happening in one careful motion?

Surprise! The results still came out as expected. Flipping and passing the pennies one at a time (a batch size of one) was still faster for the customer and overal completion than flipping an entire multi-penny batch all at once.  The delivery speed improvement was not as dramatic, but it still held true.

Our discussion after the exercise was quite interesting. And I was grinning widely that my “risk” at letting the game proceed paid off in making the game more interesting.

Keeping Context and Vision

In a health care delivery situation the provider (doctor, nurse, etc.) needs to understand from the patient the current status of the problem. As I arrived at the urgent care center the triage nurse asked basic questions like “When did this start?” “How is the pain?” and “Where is the pain?” Literally just minutes later I saw my first doctor who asked the same questions, even though he had the paper that the nurse had just filled out. He entered my answers on a computer, starting my incident record. I then proceed through at least eight additional professionals who asked me these same basic questions at the beginning of each of our individual encounters.

Early in the morning after my first night in the hospital the new day shift nurse again asked these same basic questions. I thought all this repetition was an effect of a bad computer system that didn’t share information well. I joked that the nurse should already have that information. She laughed and said that the information was right there on the screen, she just needed to hear it from me. The basic vision of service came from one source, the patient.

(By the way, the morning of the day I left the hospital, I got a new nurse. And he asked me the same basic questions again, for the 12th time.)

Information

I already mentioned the paper documents and computers that abounded, each collecting and feeding information to my care-givers. As I moved through the rooms, the information was already there, all the way to the operating room and my convalescent room. Also of note was a “team board” in my room. Nurses and others wrote on it to update information, give me tasks (“Four walks today, please.”) and allow me to communicate with them.

Regular checks of my blood pressure and other basic information helped adjust the path of care dynamically. And the questions. Always asking questions to be sure they were accomplishing the goals of the work.

Absolute Skill Divisions

Agile frameworks tend to favor a cross-functional team. I noticed that the medical professionals helping me had skill boundaries that they would not cross. For example, the nurse assistant would not ever administer my medication, only the nurse. Regulations, procedures and knowledge prevents too much cross-functionality as person after person provided my treatment. So how did the hospital maintain a “team” feel when treating me?

• The context and vision focus throughout the process, as I mentioned above. Each person who was my primary care giver at that time learned the goal of treatment directly from me.
• Notes, charts and documentation were made by each and every person who interacted with me.
• Each person who arrived had obviously already read some of the notes. They had paper with my name on it or a computer reference already in mind before they said one word.
• Each professional completed their work with me before leaving me. They got “Done” with that step before making way for the next person. No doubt they had other patients but, when they were with me, they were focused on me. Not once did I feel like they were distracted from my needs.

The Points

What did I learn that can help the teams I see and work with?

• Keep asking the basic questions and keep providing the answers. Don’t assume you know the vision or the problem, no matter how much documentation or other information you have. Ask the customer. Don’t assume someone already knows the goal of the work, keep answering them.
• Be prepared to work now and for what comes next.
• Do what you your team expects, until it is “Done.” That way the next thing has a fresh starting point.
• Share goal and product progress information, all of it, all the time.

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.

Documents Say…

The Agile and Scrum literature, including training classes, recommend a team size of “seven, plus or minus two.”  This means a Scrum team should have 5-9 members as the ideal size.  In Scrum this number includes the Product Owner and ScrumMaster.  There are many reasons for this recommendation:

• A team smaller than five decreases diversity of skills, opinion and background too much, which hurts creative capacity.
• Imagine a retrospective on a team of three people. There is a strong tendency toward either a regular complaint session or mutual admiration society.  Neither of these would lead to productive improvements very often.
• A large team requires too many relationships at once.  For example, every member of a 10-person team has nine relationships to maintain, with a total of 90 relationships in the team.  Add an 11th member and the number of relationships goes up to 110!
• The overhead of coordination grows with team size along with the difficulty in maintaining relevance between the members.

Experience Says…

I was once the ScrumMaster of a seven person team.  We were starting the creation of the base technology for a the company’s next generation of products.  Exciting stuff!  We hired or pulled people from other projects to grow the team as the work progressed.  At around twelve members I began asking about splitting the team, to keep the size reasonable.  We decided against it, that we wanted everyone to be aware of what was happening in this complex work.

And the team continued to grow.  Software engineers, hardware engineers, VHDL (embedded stuff) designers and so on were added.  Soon we had 26 on the team.  Yes, it was big, way too big.  We still held our daily stand-up meetings and kept them to 15 minutes or less most of the time.  We worked hard to keep meetings tight and relevant.  And we failed at keeping the energy up.

Splitting Is Good To Do

After several sprints we finally had consensus to split the team into three.  Let me paraphrase some things people said about their new team size after the first sprint:

• Retrospectives are better because it is easier to write items for “well” and “improve” because didn’t have to worry about boring other members with things they don’t care about.
• Daily meetings were not an interruption of hearing about things I wasn’t working on.  I could work, go to the meeting and go back to work with the same thread of thought.
• My team members are helping me more often now. I guess they didn’t really see when help was needed when we had such a large team.

Large or Small, Watch

Whether your team or teams are large or small, watch what is happening.  Pay attention to the information flowing in meetings and during the work.  Especially give a strong look at what is happening in the retrospectives.  Are things discussed shallow or repetitive?  Is there confusion when clarity was expected?  So some members feel alone in the team?  The size of the team may be something you can change to remove such doldrums and re-energize the communication!

As soon as someone gives analytical minds a number and a way to produce that number, we naturally go to work digging into its meaning. Analysis is fine when it leads to beneficial results. Many times such research leads to wasted time at best and damaging side effects at worst. Some examples:

• Velocity was average last sprint. We know we can do better so let’s push this sprint to get +10 on that number!
• The VP says she’ll take us out to the movies if we can increase our velocity by 25% this iteration.
• Team Tiger completed 30 points last sprint and we only got 23. We need to do better than them!

Before we look at these examples further, let’s take a road trip.

Driving Velocity

I live in the Phoenix, Arizona, USA metro area. Because my wife (especially) and I enjoy a famous rodent’s home in southern California, we’ve often made the 350 mile drive to that neighboring state. We know the route fairly well.  We also know that sometimes traffic, detours or other things might interfere with our usual progress.

When we arrive at the hotel our conversations about the trip never sound like:

• We averaged about 62 miles per hour this time. We know we can do better so let’s push to get +10 on that number on the way back!
• Mom says she’ll buy us extra churros if we can bump our speed average by 25% next time we come.
• My buddy Harvey drives at 80 miles per hour on this same route and we only do around 70. We need to do better than Harvey next time!

Do you talk about velocity like that after a road trip? Why not? Because the velocity is not what we are should be delivering. Let’s read that again.

Velocity is not what we are delivering.

On a road trip we are delivering a destination by a more or less certain time. While driving, velocity is important in the moment of driving, in consideration of safety and to avoid speeding tickets. No one cares if we could have gone 78 miles per hour instead of 74 in the stretch between Tonopah and Quartzite once we are in view of an artificial Matterhorn mountain!

Velocity Used Well

The three bad examples I started with all use past velocity and even some other team’s velocity. They all center the conversation around velocity, as if customers want more and more story points! Customers want working software and everything we do should be in support of delivering working software, not velocity.

I promise, if managers ask teams to deliver velocity, they will.  Most likely by cutting quality or simply increasing the scale of work size estimates, which has little to do with delivering more product.  So use velocity as an indicator, as it is used in driving.

• The team velocity now is an indicator of how much work can be done in the next sprint.
• Velocity is an indicator of what will be included within the current series of iterations making up the release.
• Velocity highlights that something is going really well or needs improvement. The improvement doesn’t come by raising velocity, it comes by making the improvement.

Let’s revisit our statements one more time, where velocity plays a part but is not the focus.

• Velocity was average last sprint. Why didn’t our new unit-test framework give us the boost we expected?
• The VP says she’ll take us out to the movies if we can get that video feature done this iteration.
• Team Tiger delivered all their stories last sprint. We need to ask them what is working so well!

There is so much more to say about velocity and how to use it. Please keep in mind the possible negative effects when we take our eyes of the product and start seeking credit for a number. And remember to deliver working software, a product, customer value, not points!

Projects need teams?

It is a very common practice for companies to manage work into projects.  Customers understand this and portfolio management, even management of larger projects, tends to naturally fall into divisions of projects.  The difficulty is that companies naturally extend this into creating a project centric view of all process.  What equipment does the project need?  Which lab facilities are available for the project?  Who are the resources with the right skills?

That last question is about people.  When we think of people as “resources” and “skill sets” we start to see them as interchangeable parts of a machine that will work on a project.  So we take a group of people, many who have never worked together, and assign them to a project and call them a team.  Because, if you are on the same project, you must be a team, right?

Preventing a team

Teams need time to learn how to work together, to figure out likes, dislikes and strengths of each member and time to develop an identity and trust.  These things don’t happen by declaration and don’t happen in one week or even one month.  When these deep interaction attributes solidify, the group of individuals becomes a team.  Great teams can take on whatever you throw at them!

The habit of swapping people in and out of teams is destructive to building these connections and high-bandwidth communication channels.  Ester Derby points out some of these bad effects:

Plucking people off the team or poking people into the team causes a re-set in the team forming process. Mess with the membership often enough, and people will stop trying. When team membership feels like a revolving door, individuals won’t put in the effort to form team bonds. You may get a group that functions reasonably well, but you’ll miss out on the team effect.

It is surprising to me that we fail to see the cost of breaking apart a team.  In the project-centric managing view, a project ends so the team gets split apart on new projects.  And we throw away the investment we made over months of work, choosing instead to pay the cost of re-building a high-performing team.

Teams need projects!

If creating teams around projects is the bad for true teamwork, what do we do with teams and projects?  The Agile Manifesto has an answer in it’s fifth principle:

Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.

Once you have a high-performing team, define projects that they can do.  Work with your customers to create a project that your teams have already proven that they can build and impress people doing.  The costs of dividing people and rebuilding trust, communication and capabilities is very high.  And your teams who have learned how to act as one will be happier to know their joint contribution is valued.

By the way, that team who was afraid of breaking up had a happy ending.  We figured out with management and company needs how they could stay together and continue impressing customers. It was a nice beginning to that ending!

I have seen a common thread all through my career.  A problem experienced seemingly everywhere, at all levels, including with myself.  This problem causes all sorts of dysfunctions and symtoms, from frustration and poor quality to wasted effort and missed deadlines.  It’s a hard problem to solve because most of our cultures, individual to large corporations, are counter to the solution.

The problem is trying to do too much.  A solution is limiting work in progress.

Limiting WIP

Some rights reserved by Tim Green aka atoach on Flickr.com

This is a concept usually connected with Lean and Kanban.  The idea is that work in progress (WIP) is a liability, it is “inventory.” As such WIP represents costs expended without yet realizing value.  Therefore limiting the amount of WIP makes sense from a cost perspective.  And it is more than that.

Problems from unlimited WIP

I have a wife, children, work, hobbies, volunteer projects, church, community events, etc. that I like to participate with.  My ability to pay attention and build any one of these areas suffers if I try to do all of them at once.  For example, my wife dislikes my habit of checking my phone during our date night evenings.  And she is right!

Many companies and even clubs or other groups take on too many things.  For example, that $500,000 contract was too good to pass up, but now the $5,000,000 project is late.  Other effects include:

• Employee and personal burn out.
• Expectations of constant over-time by executives and developers.
• High levels of interruption and context-switching.
• Low quality by taking short cuts because there is so much other work to do.
• Stale features, half-developed that clutter code and minds.
• All the requirements are top priority and all must be in the release or product.
• More meetings to coordinate sharing of people between more projects.
• And many other bad things.

Scrum and unlimited WIP

Scrum teams also suffer from situations of unlimited work in progress.  There are, of course, the issues of interruptions from outside the team and Sprint which are an organizational symptom.  Even if such external issues are not present, unlimited WIP in the team can happen:

• Sprint Planning with stories written such that each team member has stories assigned specific to their individual skills.
• Defining stories that take the entire Sprint to complete.
• No one has time to help team mates with difficulties.
• At the end of the Sprint all or most of the stories are started but few are actually done.

Limit WIP

Simply creating limits on WIP, the number of items allowed to be in process at one time, helps to solve these issues. If I choose my personal projects carefully I can more deeply enjoy the things that really matter. Organizations that discipline themselves to limit work in progress create a culture of focus and urgency.  Teams that “swarm” on stories and make sure Sprint items get done before taking on more work find higher quality, better team cohesion and increased ability to get work done.

How do you sent limits?

Empower yourself and people who you work with to say no.  For example, the VP does not have the right view and information to know if his “little side job” is really as little as imagined nor the knowledge to know how such a diversion will effect the larger projects.  The developer should be allowed to decline and have that answer stick.

Teams need to decide how many stories in a Sprint can be started but not done.  And they need to stick to it, getting things done before starting something new.

Most important, you will find that setting WIP limits will reveal problems.  Stories will not get done and instead of just starting the next story the team will have to figure out and address why current stories in progress are not done.  Organizations will see opportunities go by and will have to figure out which are the most important and what is really needed to support more projects instead of just saying yes and delivering late.  This is all good!

WIP limits are a powerful tool for uncovering places of improvement and finding the correct focus.  Use them, apply them, learn and grow from them.  You really can do more by forcing yourself to do less all at once.

Startup Weekend Chandler

Starting yesterday evening and going on today through tomorrow is the Startup Weekend Chandler event. These events are about learning and networking in an extreme environment to create a company in one weekend. People show up with product ideas, form teams and work on building as much as they can until the weekend is over. Very intense.

I am participating as a mentor to the teams. Last night I was swamped with requests of quick overviews of Scrum and Agile and how it could apply in such a fast paced development run. 10-15 minutes of talking together does not an education make. Still, I think the teams here are applying some of what we talked about. I see team boards and sticky notes all around Gangplank!

Donation-only Agile Training

On Saturday, July 23rd, my friend and superb Agile Coach Bachan Anand will lead a one-day Scrum and Agile training class at Gangplank in Chandler, Arizona. If seen the content, it is great information and a bargain experience for the $195 price. What is special is that Bachan is doing this also on a donation basis. If you are in transition between positions you can pay what you want for the class. Go to the registration page and sign up your whole team! It will be a great experiential learning event.

Meanwhile, In Costa Rica…

I have been invited to speak at the AgileFest conference in San Jose, Costa Rica, July 28-29. The agenda is full of excellent presentations. I’ll be doing two sessions and participating in a third to help people understand different specific aspects of applying Agile to real world work. You are welcome to fly down and join us in a beautiful country!

Finally, Certified ScrumMaster Workshop

Monday and Tuesday, August 1-2 Micheal Vizdos will be in town to offer his unique workshop for a ScrumMaster certification from the Scrum Alliance. I will be co-training with him and enjoying his thoughtful, interactive style. Please sign up right away as the seats are going fast for this popular class.

Look for more posts from me, more often. Neglect of this channel is not good for me. Or you!

Scrum – Ease The Hard Parts

I have participated in this volunteer event in the past and this Saturday is no exception.  I will lead a session at 10:15 AM where we will review the Scrum framework and discuss the places where the framework can be hard to implement.  We will share experiences and techniques for getting through these places for even better performance.

Agile Content Abounds!

Before I list the many sessions about Agile and Scrum, let me remind you of an important point.  Desert Code Camp is free, as in no-cost.  A free opportunity to learn, ask questions and discover gems from practitioners sharing their experience.  Find a session or two or more to take advantage of this community gift!

Here are the sessions related to Agile and Scrum, gleaned from the schedule for you!

• Thinking Agile by Martin Nagel
• Scrum . . And by Ken Ward
• Introduction to Domain Driven Design by Craig Berntson
• Behavior Driven Development From The Trenches by Lee Brandt
• Everyday Extreme Programming (XP) by Clayton Lengel-Zigich
• How To Manage Self-Organizing Teams by Jade Meskill
• User Stories and Release Planning – Difficulties and Nuggets by Perry Reinert

Classes for Kids

There are a number of sessions designed specifically for children to get hands-on experience programming and creating.  Thanks to Gangplank Jr., you can bring your young offspring to learn programming with Scratch, build Lego robots and other things.  Check the schedule for these classes marked with minimum age appropriate notation.

It will be a great Saturday!  If you don’t attend my session, look around for me to say hello before the day is done.