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!

Individuals and interactions over processes and tools
…
Customer collaboration over contract negotiation

Most of us that work with technology are enamored with it.  Even those not struck by love of bits and bytes seek predictability in our work.  Humans are so much harder to predict and deal with than spreadsheets and marketing requirements documents.  Thus, the enterprise tends to start-up new teams considering only the numbers, features and skills while largely ignoring the humanity of the team.

Recently I have participated in the definition of a new project.  The marketing department measures and discusses features, engineering leadership discusses architecture and micro-processor choices.  Slowly, over meetings and emails, a Marketing Requirements Document emerges and engineering begins to create an architecture definition.  The defined “bells and whistles” show a product that will dominate the market.  The technology described looks fun and exciting, with new processors and data-flow paths that will meet the high performance numbers.  The concept is good, the management team is on board, funding is approved.

“Yee-ha!  Let’s go!”

“Wait.  Who is going to do the work?”

Now, it is true that discussions about people and skills happen during all the planning described above.  But many times such discussion is shallow until the project needs to start.  With the project already started, defining and building the team becomes an hurried exercise.  Consideration of current teams and their projects may be tossed aside in the rush to get started.

More difficult yet is the personality equation.  Rarely in my experience does the “human side” of the people doing the work get as much attention as the questions of technical skills and availability.  Expecting a team of experienced and socially mature developers to gel, simply because they’ve been assigned to the same team, is courting project difficulty.  This matters much more for agile teams who are expected to meet everyday, collaborate on decisions about work and even work side-by-side in the same room.

Here are some suggestions on how to make sure that the people part of the team gets deserved attention:

• Involve potential team members in the product and project definition phase. Even before the project is defined, the people likely to work on it may be known.  Have them participate in the definition discussions and research.
• Create a definition review team to help create the initial Product Backlog. The review team will consist of those most likely to be on the project team.  This allows them to learn about the project and practice working together before the full-time commitment starts.  Estimating a backlog brings out personality, allowing “measurement” of the human factors involved.
• Let the members know as soon as the full-time team is selected, even before they are full-time on the project. This allows for responsible team member feedback about the makeup of the team while there is still time to adjust.
• The first meetings of the team should not be about the project but about the team. Time should be spent defining work agreements and other rules of interaction within the team.  The team defines all the everyday questions like documentation tools that will be used, when will meetings be held, how will disagreements be handled, how will pair-programming partners be determined, will there be penalties for being late to meetings, etc.  The ScrumMaster should facilitate the creation of these rules and publish them with a team commitment to them.
• Allow a day or two for the team to get their working environment in order. Like the working agreement, the team needs to create their physical working environment such that they take ownership and are comfortable.  Moving desks, building servers, setting up the team task board and so on are needed parts of the initial team connections.

For organizations practicing agile or Scrum, the above suggestions should be obivous.  But given our tendancy to get wrapped up in the technology and numbers, neglect of the “human equation” happens easily.

What steps do you take to make sure a new agile team starts off with the best possible human foundation?