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.

It’s December.  Time for gifts and good feelings.  Time for another free class!

As I did in September, I’ll be teaching the four-hour workshop “AGL-101 ntroduction to Agile and SCRUM“ on Saturday, December 18th.  This is a no cost workshop where we will explore the basics of the Agile Manifesto and the Scrum Agile Framework. The class will be held at Gangplank HQ in downtown Chandler, Arizona.

Gangplank Academy

Gangplank is a wonderful dream made real by Derek Neighbors, Jade Meskill and other community minded people.  It is community centered co-working at no cost, and therefore priceless.  Visit their site to learn more about their work.  Especially read the Gangplank Manifesto which, in my opinion, drives Agile values into the realm of community building.

One of the efforts of Gangplank is to provide education opportunities for the community.  They work to provide the infrastructure for people to share expertise and learn from one another.  Regular business and technical “brown bag” sessions happen every week.  Other conferences and events are scheduled regularly.  All of these events together are create The Gangplank Academy where learning on many subjects and for all ages takes place.  This workshop is designated as “AGL-101″ since it is part of the classes of Gangplank Academy.

AGL-101

I am hoping for a great mix of Agile and Scrum knowledge as well as a mix of work focus in this class.  Software projects have traditionally been the focus of Scrum application.  This is logical since it was created from that industry.  However, creators of software product aren’t the only ones who can benefit from Agile values and Scrum.  Management, marketing, operations and other facets of the business of production can be improved by application of high interaction and clear communication.  I encourage you to invite your peers and people “outside” of software and engineering work to spend this bit of time to learn with us.

RSVP

The event is available on Facebook.  Pease RSVP on that page so we can plan for the class size.

One attendee has promised to bring donuts or bagels.  Which do you want?

I learned some interesting things that I’ll try to pass on here.

Where You Are

The attendees of the workshop were a diverse group:  A CEO of a web development firm, a web application developer, a project manager and a high-level manager of development for an insurance company.  Each of them had important and different views of Scrum and Agile. Best of all, each of them were highly engaged in learning.

As we discussed, I saw the each of them being open and honest about their experience and knowledge around Scrum.  They were speaking from “where they were” in their own Agile journeys.  This empowered the rest of us to give them what they needed most out of the class.  Early expression of truth brought about meaningful discussion and value.

We all should do this in all our interactions, whether they be daily meetings, planning or talking with our kids.  Where you are is not known to those around you.  If you help them see that place more clearly, the interaction will be far more valuable for them and you.

Experience Is Not Quite Everything

None of us in the room were new to Scrum.  We all had experience with the terms and the practice.  What do you do in a workshop on the Scrum framework with people who already know Scrum?  Mike masterfully structured the class to use the Scrum framework content as a framework for discussion.

Only reading books, watching videos or attending classes is shallow learning.  Agile is all about action and learning from that action.  And remember, combining learning with experience is powerful for building the next leap in action!

Application Teaches

The workshop was filled with interactive activities, from writing Product Backlog Items on cards to shuffling cards and folding boats.  The long-time practitioners on the team consistently expressed delight at the value of studying a concept and then applying it, even in a “contrived” environment.

Action is where the lesson is learned, just as it is in developing a product.

Keep Applying

Lastly I personally learned that continuous application of principles is needed in my own Agile practice.  It is easy to forget the basic little things that make all the difference.  Powerful things, like honesty, direct but polite disagreement and small pieces of a big vision can be more important than we know.  I promise to keep applying them if you will!

On Wednesday and Thursday, November 17-18 I will be co-teaching a Certified ScrumMaster Workshop.  I am not a Certified Scrum Trainer so Michael Vizdos will lead this workshop.  Participants will be ready to receive their ScrumMaster certification from the Scrum Alliance.  I’ll be his humble assistant as we help people improve their understanding of Scrum over those two days.

Mike Vizdos is known for his experience and thoughtful teaching style. He brings a great perspective of long experience and humor to the learning process. There is much to learn through the cartoons at his Implementing Scrum web site.  Several years ago Mike was the trainer for my own ScrumMaster certification.  He has since been a mentor for me, answering questions and continuing to be a guide through the difficult part of my Agile journey.  I am very excited for the opportunity to work with him in the classroom.

Register for the course with this link for $300 off the usual fee.

The course will be held in a modern classroom in historic downtown Chandler, Arizona.  Chandler is an easy 20 minute drive from central Phoenix.  The city is just finishing a series of downtown improvements with wide sidewalks and wonderful restaurants along the way.

Let me know if you are coming!

Gangplank Academy

Gangplank is a wonderful dream made real by Derek Neighbors, Jade Meskill and other community minded people.  It is community centered co-working at no cost, and therefore priceless.  Visit their site to learn more about their work.  Especially read the Gangplank Manifesto which, in my opinion, drives Agile values into the realm of community building.

One of the efforts of Gangplank is to provide education opportunities for the community.  They work to provide the infrastructure for people to share expertise and learn from one another.  Regular business and technical “brown bag” sessions happen every week.  Other conferences and events are scheduled regularly.  All of these events together are create The Gangplank Academy where learning on many subjects and for all ages takes place.  This workshop is designated as “AGL-101″ since it is part of the classes of Gangplank Academy.

AGL-101

I am hoping for a great mix of Agile and Scrum knowledge as well as a mix of work focus in this class.  Software projects have traditionally been the focus of Scrum application.  This is logical since it was created from that industry.  However, creators of software product aren’t the only ones who can benefit from Agile values and Scrum.  Management, marketing, operations and other facets of the business of production can be improved by application of high interaction and clear communication.  I encourage you to invite your peers and people “outside” of software and engineering work to spend this bit of time to learn with us.

RSVP

The event is available on Facebook.  If you would, please RSVP on the page.  This will help us plan for the proper room and tailor the class appropriately.  Comment on the event page too.  All the communication we can get helps us help you!

The Questions

The original post in the group asked some hard questions about the role of the Product Owner.  Questions about this role are normal since the original Scrum definition does not go into detail about the day-to-day work of the Product Owner.  I think this is intentional as one definition of this role would not fit very many teams and enterprises.  Let me paraphrase and condense the questions:

How does the Product Owner build and maintain the Product Backlog?  How does he ensure the Sprint Backlog is ready for planning?  And, how much time should be spend doing these things?

Study the Role

To understand the power, nature and key importance of the Product Owner role, we should first understand the big picture.  Some of the best documentation about the Product Owner role comes Roman Pichler. Look around his site for some great information.  In particular, Roman produced a slide set that has helped me many times when explaining the Product Owner role to executives and teams.  Read through this set on being an effective Product Owner [PDF] for some great insight.

The process of gathering information about story content; requirements, UI, etc. can vary significantly from company to company and team to team.   Scrum does not provide direct instruction about how the Product Backlog should be assembled and maintained. Scrum mostly says that the Product Owner is in charge of the backlog.  Lets focus on the main goal for the Product Owner with regard to Sprint Planning:

• The Product Owner needs to have at well defined stories ready at the start of the meeting.
• These need to be in business value priority order.
• There needs to be enough ready to fill at least one Sprint Backlog and maybe a few more, just in case.
• These prepared stories define “What?” is to be created and how everyone will know the creation is complete.

To meet these goals, the Product Owner can use whatever method is needed to collect, document, understand and define the answer to “What?” should be created.  Some things the Product Owner might do:

Product Backlog Grooming

In Roman’s writings he emphasizes the idea of a backlog grooming section. There are others also emphasize this idea and I agree with them. Sometime during the Sprint, the Product Owner and all the team developers will spend time fleshing out the stories for the next sprint and maybe a couple more. This allows the team a forward look to help guide the current work and keeps them on the road. Most importantly, it helps the Product Owner understand the costs, risks and benefit of imminent stories.

Stakeholder Communication

The Product Owner will call meetings with the various stakeholders (Marketing, Production, Finance, etc.) to create and refine stories. The Product Owner represents these interests and people to the developers on the Scrum Team. There needs to be communication with these stakeholders often so that their interests are well represented in the stories and hence the end product. These people are not on the Scrum Team (i.e. they are “chickens”), but they are customers, so their input is vastly important.

Team Communication

Besides a formal grooming session, the Product Owner should be available at any time to talk, discuss and meet with the team or individual developers. The best communication method is face-to-face conversation. When such is done between people that regularly spend time together, misunderstanding is much less likely to happen. Specs, diagrams, drawings, etc. are great. Do them asneeded in order to create a great end product. Documents are not the primary means of communication. Face-to-face is the primary means.

Time to Prepare and Define

The amount of detail and work in all this grooming and communication should be biased toward the present and face-to-face communication.

The detail in the Backlog request as far as features, business rules, and the like, should be only as much as needed for customers, Product Owner and team to understand each other. Once they are used to talking and working together, not very much will be needed. Stories in the next sprint or two will have more of this communicated while those further down the Product Backlog will have less. No reason to spend lots of time defining things that are weeks or months away since they will change.

The Product Backlog does not contain detail design.  They should have as little design information as possible, for the moment’s need. Maximize the work not done.  Remember, the team defines the “How?” of the work, which is the design.

• If the story is in the current sprint, there will be lots of this detail as it is implemented.
• If the story is expected in the next sprint, only as much as needed to be ready for Sprint Planning. Not too much.
• If the story is expected two or more sprints out, only as much as needed to have an understood vocabulary around the story. Not very much at all.

When a Product touches several domains (Marketing, Production, Finance, etc) besides the “product” domain, resist the temptation to do Product Owner by committee.  The Product Owner needs to be the one person that the rest of the Scrum Team asks for decisions of priority and completeness of work. The Product Owner may represent many other functional customers but those customers are not members of the team. This is not to say that developers are not allowed to talk to customers, they should. But questions of story definition and priority are for the Product Owner to determine.

The definition of done is defined by the Product Owner, based on customer input. It is part of the answer to the “What?” question. It should be in the story before the Sprint Planning meeting starts.  During the Sprint Planning meeting the developers may reveal that the story is to big or to difficult or somehow not possible to accomplish as defined. This is only because the “How?” that is answered by the developers cannot meet the definition of done for some reason. Hopefully this does not happen too often and usually should be resolved in the Product Backlog Grooming and communication with the customers.

Definition of done should also include technical requirements such as “Shall pass unit tests” and “Shall be built on the official build computer before demonstration.”  These the developers should define and follow.  The Product Owner should understand the importance of high craftsmanship to the end product.

The Product Owner role should not be taken for granted.  It is a key role that each team and company must refine in their own way.  Keep learning about it all the time.  It is one focus that almost always can be improved.

I enjoy helping people with Scrum and Agile. The more I do it, the more I learn and enjoy it. Many of my recent in person and online encounters have had a similar flavor to them. I didn’t put my finger on it until this morning.

In an online exchange people have been discussing the Sprint Burndown Chart. Opinions on it’s usefulness, how it should be used and what it contains vary widely. That’s OK, because every team and situation is different. The point that struck me was one particular comment. This person described how their chart showed burn down of estimated hours for tasks. They adjusted the burndown each day if a task’s estimated hours to done changed, essentially including actual hours into the burndown.

For example, take a task that was originally estimated at two hours. The next day the developer working on the task reports slow progress.  The task is not done with four hours already spent. The developer now estimates the task will take ten hours. So the burndown chart data point would be adjusted up by six hours to include the new estimate.

This example shows the desire of this particular team to track actual hours. I suppose they wished to compare them to the original estimates to measure accuracy, though that did not come up. (There are several reasons that I don’t like such a way of doing things, but that is another discussion.)

Other examples along the theme have been

• eight hour planning meetings
• estimating an entire five month long Product Backlog all at once
• two days of wireframing before writing the story
• sprint tracking spreadsheets with more detail than a Gantt chart

So when I was thinking about the burndown of actual hours example and other practices of potential waste, the theme hit me:

Big Design Up Front (BDUF) of Scrum

It seems many people are trying to eliminate BDUF of products, with Scrum implementations that are designed big up front.

• They need to define every possible field that might be needed on a story card before they start using story cards.
• They want to track hours and sub-hour increments on tasks, allocated by a percent of the developers time against other tasks.
• They need backlog spreadsheets with date coded story ID’s, date last edited, comments by department in separate columns and priority votes from each of five stakeholders.
• They make up two page forms for recording the definition of done and how each maps to the appropriate use case record(s).

And they do all this before the first team starts the first sprint. Because, well, they’ll need the data, right?

Maybe they will need such tracking of information someday. Any one of the above might be the right thing to do at some point for a particular team or company or product. Does it make sense to design all this infrustructure up front, not knowing if it’s really needed?

BDUF Practices in Scrum

Finally, after weeks of discussion, meetings, documents and planning, they start the first sprint. And here they are with all these BDUF practices now part of their Scrum processes. Product Owners who have more clerk-work than product innovation-work. Scrum Masters who have to keep asking for actual hours worked. Burndown charts that require an instruction sheet to interpret. A project bogged down by the same stuff that was supposed to be left behind by “going Agile.”

Simple Code, Simple Scrum

The best code is simple, direct and no more complex than it has to be. The best products have a clear function and benefit to their customers. The best information is direct, focused and simply presented. The best Scrum is simple as possible. Just as it is not possible to know all the answers to creating an innovative product before starting development, it is not possible to know all the things needed for an awesome and highly productive Scrum process. Start simple, way simple, with just the basic pieces. Then, retrospective after retrospective, the team and company learns what they need, solves it in a simple way and gets back to the real business of creating a killer product.

Just go! You will learn what you need along the way, faster than you ever imagined!

Last Saturday, May 15th, was the seventh incarnation of Desert Code Camp.  As I briefly announced before, Code Camp is a day of volunteer presenters and attendees bent on learning from each other.  I throughly enjoy these events.

Deeper Into Scrum

My first session was “Going Deeper Into Scrum, An Agile Journey” where the goal was not to teach Scrum but to find places where using the framework is difficult for the attendees, and then talk about those places.

The room was full and quiet, too quiet at first.  We soon got things going with a definition of the Scrum framework.  I drew the flow, cerimonies and artifacts on the board, answering a few questions as we went.  I then invited the attendees to write on the sticky notes distributed around the room.  They wrote one point or item of difficulty with Scrum on each note.  They were invited to the front of the room to place their notes on or near the part of Scrum effected by the note.

The resulting board was awesome!

I then did my best to bring out the issues on the sticky notes, grouping them or pulling them into the discussion as the conversation flowed.  Several of the attendees were very helpful with questions and answers as we shared possible corrections to the difficulties.  I’m sure we did not address all the notes in the remaining time for our hour.  I do hope people learned and shared some gems of help that they can apply to becoming more Agile with Scrum.

Lunch Time

30 minutes was set aside for lunch time.  This started directly after my first session.  Due to the nature of such a conference, scheduling is done as best the volunteers can with the knowledge they have.  In my case, the second session I was teaching immediately followed lunch.  By the time I finished excellent after class one-on-one discussions and clean-up, it was time to setup the next class in a different room.  Lunch for me would have to wait!  (Thank goodness for granola bars!)

Agile Manifesto and Code

I encountered a difficulty with this session because of the classroom layout.  My plan was to use slides with the four values and twelve principles of the Agile Manifesto and use the marker board for supporting discussion visuals.  The projection screen covered the marker board.  I opted to use the slides, since the Agile Manifesto was the text and writing out all of it would kill the flow

The title of the presentation was “The Agile Manifesto – What it means to the code and the coder.”  We approached this by defining each value and principle of the manifesto and then discussing what the code would look like and the coder would be doing if they follow the manifesto.

The discussion resulted in many mentions of continuous integration, TDD, paring, refactoring and many other development practices.  There were also questions around supporting the manifesto in different business environments such as large vs. small projects.  I enjoyed the banter and peer education that was going on.

Community

A large thanks to:

• DeVry University for providing their campus and classrooms for the event.
• Joseph Guadagno, Camp Director, and all the other volunteers I didn’t see but must have been helping.
• The people in the sessions I led.  There are many people in the Phoenix area working to improve and learn.  They have many questions.  They are bravely working on many impediments.  They are awesome!

Let’s explore this discussion further in the context of last month’s (April, 2010)  Phoenix Scrum User’s Group meeting.

PhxSUG Meeting

We announced the meeting would be a participatory simulation of a Scrum project. About half of the people in attendance had never been to one of our meetings before and many of them were very new to Scrum. We were gratified that some came specifically to experience a Scrum simulation!

We started with a brief discussion of the Scrum framework, with it’s roles, cerimonies and artifacts. With that foundation set, we dove into the activity. The project was five Sprints of the Ball Point Game (PDF)

(Here is a video of the game in action. If you have not tried this game, I highly recommend it. If you watch the video, don’t say too much when you play the game the first time. Don’t give away the secrets too soon!)

All of the meeting attendees are one team. The goal, or “product,” of the team is to transfer as many balls as possible in the two minutes of a Sprint. Between each sprint, the team reviewed performance and planed the next sprint. We had great fun and the team successfully transported all but two of the balls on the last sprint!  We then did a bonus sprint with some “cheat codes” from me, the coach, to optimize the process.  We succeeded in getting all the balls through in the time allotted!

Debriefing

In our discussion after the game, we found some interesting points:

• Changing even small things between sprints effected performance of the team in bad or good ways.
• High communication was paramount.
• Keeping a rhythm of movement in the whole team was important.

There were several other things learned, one of them was around leadership.  As the team was first getting organized for the first sprint, there was some chaos. Lots of people talking, pointing and throwing out ideas. Suddenly one of the participants spoke up and began speaking authoritatively about how the job should be done. The team followed, with some discussion, and the first sprint began. So, suddenly the team had a leader. Not by assignment but by personal energy and willingness to step up.

Dynamic Leadership

During the first planning period between sprints something interesting changed. Another participant pointed out a weakness and suggested a change to cover it. The team followed this suggestion as the previous “lead” blended into the team to make way for a new leader. This passing of leadership continued from sprint to sprint with different individuals teaching the team their ideas about how to improve and others volunteering into key roles. It was natural that the “Team Lead” changed as the needs of the team changed in the quest to improve.

This is dynamic changing of team leadership also happens in a Scrum team. Depending on the goals of a particular sprint, the team may look to the database administrator to lead or the user interface designer. Story to story, sprint to sprint the expertise needed by the “Team Lead” can alter. A team working well allows the currently needed leader to come to the front, and then fall back in favor of a new leader who has the talent or experience to handle the next focus.

When a team has an assigned Team Lead, this leadership adaptation is less likely to happen. Team members will not want to “attack” the assigned lead’s authority by stepping up. The team lead may not want to reveal “weakness” in a knowledge area and so will not allow another team member authority. Once a hierarchy is established, especially when established by higher authorities, it is very hard for those within the structure to alter their expectation of command and allow a better leadership pattern to emerge when needed.

In short, assigning a Team Lead and expecting that person to be appropriate in the role for the entire project is a form of “Big Design Up Front.” There are great Team Leads and managers that know how to foster leadership from team members. I am not denying that such excellence is possible. I am saying that such people are rare and anyone in that position must constantly push and pull against the cultural expectation that they are Lead and therefore must have the answers.

And The Team Shall Lead Themselves

Let the Team be the team lead. Then, the right leader will emerge at the right time as the team naturally strives to accomplish their work. I’ve seen it happen, just as it did the night we were throwing balls around, learning while laughing!

Meeting details are available at the PhxSUG website, where you can sign up for this event and to hear about other group meetings.

I’d love to meet you there!