Old Habits Are Hard to Break

My organization is transitioning from a waterfall style of running software projects to Scrum.  Everyone involved in the project has had Scrum training, they understand the benefits, and they are on-board with the changes.  Sometimes that's not enough.

The Product Owner and some of the Team were with the organization when they ran waterfall-style projects. They are accustomed to spending a large chunk of time gathering requirements and another large chunk of time doing architecture and design before beginning development.  They would also set aside a large chunk of time for testing after development that they weren't able to focus on because development took longer than estimated and requirements changed mid-development.  They experienced all the typical problems associated with waterfall projects.

But, old habits are hard to break.  If the Product Owner is accustomed to waterfall, they they will likely want to to spend a lot of time on requirements or when discussing a feature they want to detail all the items related to that feature.

It's very important to start with epic user stories and break them down into themes and more detailed user stories as needed.  When initially building the product backlog the stories only need enough detail so both the business and the team understand the functionality and they can be assigned story points.  Detailing all the user stories on the product backlog when it is being initially populated can cause several problems. First, they are likely to change by the time they are implemented anyway.  Second, it takes too much time to detail all the user stories in the meantime there is no value being delivered.  Also, If you spend to much time delving into individual stories, other stories may be overlooked.  Delay the details of the stories until just prior to implementation. Otherwise you'll slip back into the old habits of waterfall.

To break the old habits, you need a disciplined, patient, resilient ScrumMaster to help the Product Owner and the team delay the details as long as possible and to break down larger user stories into smaller ones and focus on each story individually.

Have you ever been on a scrum project where the Product Owner was accustomed to waterfall?  Were their old habits hard to break?

"How to Supercharge Your Productivity"

Quite by accident, I recently attended a free webinar from The Energy Project called "How to Supercharge Your Productivity." Based on the description in the invitation I thought it was going to be about managing distractions, sleep, exercise, stretching, breathing, meditation and all manner of things that you can do through the day to keep your energy level up... besides coffee.

I was surprised at how much the themes in the webinar paralleled some of the ideas in Scrum.  Here are some of the points from the webinar:

• Work in 90 minute iterations through the day, stop to reflect and prioritize.
• Do your most important task of the day first before anything else, even email.
• Don't switch context.  Work in serial rather than parallel.
• Celebrate incremental successes.
• When working in a team everyone should share commitment.
• It might be necessary to take a "leap of faith" by changing the way you work, but stick with it for 30 days and then gauge your productivity.
• Perform daily rituals at the same time every day.
• Have transitional rituals before and after work.

This is really living Agile.  I can't wait until the next webinar titled "How to Give Feedback People Can Hear".  I'll wager it borrows heavily from Agile too.

Our Task Board

Everyone really likes having a real task board in the team room. With just a glance anyone can understand where the team is in the sprint. There is a real emotional response for a team member to walk up to the board and move a card to the "Done" column. I've seen some places that use Velcro so there is an actual loud ripping noise when you peel something off the board. It's very gratifying and gives the team a real sense of accomplishment.

I use a cork board with some masking tape and colored index cards. Our burndown chart comes from TFS. We're using the Visual Studio Scrum 1.0 process guidance template. I also post the team's definition of "done" and their working agreements for the sprint. I a tool called Scrum Task Board Card Creator to print the tasks and stories from TFS.

How is your task board set up?

Agile Housekeeping

My wife and I like to have friends and family over for dinner. We have a two year old son so the house looks pretty much like a day care most of the time with toys and books and puzzles all over the place.

When we are getting ready for company to come over it is typically a dash to get the house in order and make dinner before they arrive. This is one of those times when I get to apply Scrum outside of work and it is very effective.

The first thing we do is "dinner party planning" where we populate our dinner party backlog. Typical items are:

• Go to the grocery story
• Make dinner
• Clean the house

These are our "epic" user stories.  We then break these down into smaller stories, like the actual grocery list, the dishes we'll prepare and the steps to make them, which parts of the house we'll clean and to what extent.  Then we prioritize them and assign them to each other.  As we complete the tasks we cross them off the list.  Every day we stop and re-prioritze the list and then continue to work.  Then on the day of the dinner, we stop and re-prioritze every hour.  It is a iterative process and it works very well for us. We might not get everything done, but we get the most important stuff done and it is the best use of our time.

Do you have any examples in your personal life where you've been able to apply Agile techniques?

Don't Let Tools Get in the Way

In our first Sprint Planning meeting the Product Owner wanted to open up TFS and start creating backlog items and tasks in the tool.  "It's a waste of time to write them down on cards and then take the time to enter them later." he said.

I don't like doing this because the tool typically becomes a distraction. Adding and reordering columns, sorting, making new queries, people asking "what's that button do?" just takes focus away from the planning. I'd much rather use index cards.

We have a distributed team so we need to use some tools.  We settled on Excel and LiveMeeting. Even those simple tools slowed the process and distracted from the planning somewhat.

Remember that the Agile Manifesto states that "we value individuals and interactions over processes and tools."
If you are forced to use tools while planning use as low-tech as possible and don't let the tools get in the way.

Do you have other examples where the tools hindered the interactions?  What tools do you use that don't hinder the interactions?

Surfing the Wave Between Chaos & Order

I attended the Houston TechFest this past weekend.  There were several really good sessions in the Agile track.  A portion of the session "Self-Organizing Teams - Chaos or Triumph?" by Robbie Mac Iver had a very powerful and simple message I'd like to pass on.  He began the section of his presentation by showing just one word:

CHAOS

...and asked what we think of when we picture a chaotic team.  Our answers were:

• Unpredictable results
• Difficult to manager
• Free
• Disorganized
• Confused
• Experimental
• Innovative

Then he added another word:

ORDER

... and asked what we think of when we picture an orderly team.  Our answers were:

• Consistent
• Easy to manage
• Confined
• Organized
• Process-driven
• Stifled
• Regulated

He then pointed out that both chaos and order have good and bad aspects. Though wild, a chaotic team is free to experiment and be innovative, and though easier to manage, an orderly team's innovation can be stifled.  So there is a line between chaos and order, and it's on that line that an Agile team rides.  But the line is not a straight line.  It moves back and forth over the life of a project.  Sometimes a team is more orderly and other times they are more chaotic.  Looking at it this way, the line is really a wave between chaos and order alternately drifting between the two.

Taking that a step further we can say that Agile teams "surf" this wave through the life of the project. And like surfing it is easy to fall.  A team can very quickly fall into too much chaos and become uncontrollable. And just as quickly a team become too ordered where no new ideas are sparking.

The diagram made me think of yin and yang which is an Eastern philosophy that describes complementary opposites that interact within a greater whole, as part of a dynamic system.  It is the perfect symbol to represent an ideal Agile team having equal (yet varying) parts chaos and order.

One of Scrum's tag-lines (as well as one of it's founder's website) is Control Chaos.  This is the essence of Scrum.  Just enough chaos to be free thinking and just enough order to be successful.

"The problem I have with Scrum is..."

I've just given a a Scrum training course to the team because most of them have never been on a Scrum project before.  This is the same training I've presented several times.  It is a distilled version of what I learned in my ScrumMaster training and is based on the Redistributable Intro to Scrum presentation. Typically the best part of these training sessions, for me, are the discussions.  You learn a lot about people and the team and how responsive to change they are by these initial discussions in the training class.

Several members of the team had a few revealing comments.  They are born from preconceptions, pessimism, ignorance of the process, and old waterfall habits, and typically start with,

"The problem I have with Scrum is..."

"... daily scrums seem like they would be a waste of time."

Daily scrums can be a waste of time if people are allowed to drift off topic or try to resolve issues in the meeting. The meetings are timeboxed to 15 minutes and seldom take that long if everyone sticks to the 3 questions, "What did you do yesterday?", "What are you going to do today?", and "What impediments are blocking your progress?".  Are daily scrums more of a waste than not gathering empirical data on where the team is and where they are going every day so any necessary course corrections can be made?  How much time would be wasted if we found out a week or month after-the-fact that we were going in the wrong direction?  A lot -- and that's not agile.

"... if I wanted to be responsible for other people's work, I'd be a manager."

My response to this was, "So you don't want to be on a team?" To which they replied, "No no, I want to be on a team, I just don't want to be responsible for the work of other people on the team."

A little confused by this statement, I dug deeper, "Could you describe a scenario that would make you feel uncomfortable?" They thought for a moment and said, "Let's say we hire a bunch of green developers that don't know anything and put them on the project and they aren't able to produce."

Now I understood their concerns.  They didn't want to be held accountable when the team changed if they were expected to produce more.  I explained that we don't add people to the project in the middle of a sprint and expect them to produce.  The team makes the commitments to the work they are going to do during the Sprint Planning and no work nor people are added in the middle of the sprint. The team is responsible for delivering their commitments each sprint and the commitments don't change during the sprint.  Also if you add people to the team, during the next Sprint Planning you will make new commitments based on the new team. The commitment shouldn't be a linear factor of their velocity.  For example, let's say there are 4 people on the team and their velocity is 40.  No one should expect if we add 3 people to the team the should be able to commit to 70 story points next Sprint.  The team would have to go through the Forming, Storming, Norming, Performing phases again, which takes time and should probably not commit to over 40 points.  They may even commit to less at first because the stronger team members are helping the weaker team members get stronger which may take away from their work.  This may seem counter-intuitive to say, "Our velocity went down because we added more people." But it's just like the first sprint when you didn't know what the team's velocity was until they completed a sprint together.

"... use cases are better than user stories."

My response to this was, "What do you get from use cases that you don't get from user stories with acceptance criteria?"  Their reply was, "When we write use cases we can see the 'big picture' of the entire project because we can connect them with lines and see how they relate. We don't get this with user stories."  I argued that the lines don't come from the use cases they come from the tool that you use to write the use cases.  You can achieve the same thing with user stories by putting them on a whiteboard and drawing lines between them.  User stories have the advantage that they include acceptance criteria so the team knows exactly what to create, and they have benefits so the team knows why.  Comparing use cases and user stories is like comparing apples and oranges.  Use cases define how users will interact with the software and user stories describe a business need the user has that the software will accomplish.  If you feel the exercise of writing use cases provides value to the project then do both. If you get in the habit of writing good user stories you can probably skip use cases and go directly to user stories... and spend less time doing it.

"... user stories shouldn't be negotiable."

When we reached the section of the training on writing good user stories I discussed the I.N.V.E.S.T. criteria for a good user story.  User stories should be Independent, Negotiable, Valuable, Estimate-able, Small, and Testable.  All of theses were pretty easy to understand for the group except for negotiable.  The Product Owner argued that user stories should not be negotiable and what's written should be done.  What is meant by "negotiable" here is that the story is just a short description and does not include details. The details are discovered during the conversations with the customer.  Too much detail can limit conversation with the customer.  User stories should be able to be thrown away or changed if need be.  Recall in the Agile Manifesto we value customer collaboration over contract negotiation.  If the story is too detailed you may shortcut necessary conversations.

These are just a handful of great statements that come from people that are new to Scrum.  What sort of preconceived incorrect statements have you heard from people that are new to Scrum and how were they corrected?