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?

It's Not an Ideal World

I am the ScrumMaster for a  new software development project at a large oil and gas company. The project is a re-write of several disparate process control applications into one cohesive suite of applications. The project has been going on for several months but I just joined recently and there was no other ScrumMaster on the project before me. All the decisions up to now have been made without my input.

Let me lay out the scenario for you and see if you can spot any red flags.

I will also be a development resource. I am expected to split my ScrumMaster and developer responsibilities 30% and 70% respectively.  The Product Owner attended a Scrum overview course and is confident in his knowledge of Scrum.  For the past few months the Product Owner and group of subject matter experts have been meeting to discuss the requirements.  They have come up with over 700 requirements.  The requirements are very high-level with almost no detail and require a lot of domain knowledge to interpret.  They have also documented all the use cases they can foresee. 

The Product Owner decided that each sprint is 18 days long, and each release is 5 sprints long.  In an effort to provide a high level estimate for initial budgeting, resourcing, and scheduling purposes, the subject matter experts, the team, and I met several times over a week to try to assign relative complexity scores to the use cases.  Even though I convinced them to use the Fibonacci sequence for relative complexity scores, I won't call them story points because they weren't user stories that we were estimating and none of them had acceptance criteria.  We then took a random sampling of use cases and detailed them out further and provided effort estimates so we'd have a rough idea how much effort each "story point" wound take.  Then we multiplied that by the total story points and came up with close to 100,000 person hours. 

We are partnered with another company's development team in Japan that will be developing a portion of the application. Our releases will need to coincide with theirs. The project is expected to be complete in 2 1/2 years.  The Product Owner created a project roadmap that breaks down what he thinks should be in each release and details what should be in the first few sprints.  There is no link between the Product Backlog, the use cases, the roadmap or the first couple of sprints' worth of work.

In order to complete the 100,000 hours in 2.5 years it will take about 25 people.  Currently the team is made up of 4 developers (3 local and 1 in the Netherlands) and 1 tester and me.  There are three other "testers" that are from the helpdesk that can commit 30% of their time to the project.  Two of them are local but they work remotely and one is in Malaysia and they have no testing experience.  The tester and one of the developers have been on a Scrum project before and I'm confident they understand the methodology but the other 3 have not.
The first sprint planning meeting is today and the first sprint starts in 2 days.

Anyone see any problems here?  Ideally there would be a lot of things I would change about this project. But we don't live or work in an ideal world.  We live and work in an ever-changing chaotic world.  The best we can do is to be agile and to make the best of the situation.

• Ideally a ScrumMaster should have been involved as early as possible in the project in order to coach everyone on the process.  I was on another project until recently so they couldn't use me and the product owner felt they knew enough about Scrum to get started.  From now on, I'm in every meeting  and discussion regarding the project.
• Ideally I should not be splitting my time between being a ScrumMaster and a developer.  However, I do have some domain knowledge and I'm a good developer resource.  We probably don't need a full time dedicated ScrumMaster right now, but I expect that my responsibilities will shift more toward ScrumMaster and less development as the project goes on, especially if we have more than one Scrum team on the project.
• Ideally the Product Owner and everyone on the team should have already had some sort of Scrum training.  On a project of this size I would recommend that the Product Owner be a Certified Scrum Product Owner.  This may happen later but initially he felt that his overview course was sufficient.
• Ideally the requirements should have been written as user stories.  I wouldn't expect all the requirements would have much detail now. The time spent on the exercise of going through the use cases was probably not entirely wasted, but it would have been easier and clearer if, rather than writing requirements then writing use cases then writing a roadmap, they had just started with epics, narrowed to themes, and then narrowed to user stories.
• Ideally the Product Owner, the team, and the ScrumMaster would decide the length of the sprint together based on how long they think the team can work without being interrupted.  However, the decision by the Product Owner to make the sprints 18 days long is probably a good one.  It's good the Product owner did a Product Planning in the form of a roadmap, but it would have been better to involved the team and the ScrumMaster.
• Ideally several months wouldn't have pasted before the first sprint.  There has been quite a lot of time spent and no business value realized yet.  Had the Product Owner spent lest time on the requirements and the use cases, then the team could have begun work sooner and the project would already have business value.  Since the Product Owner and the subject matter experts are used to working in a waterfall project it is natural to them to spend a very long time gathering requirements for the whole product.
• Ideally the effort estimates should have come after the first sprint when the velocity of the team is known but for budgeting purposes we had to estimate at a high level based on the complexity.  Future estimates will be quicker, easier, and more accurate after the velocity is known.
• Ideally we would only plan one release at a time, but since we are partnered with another company on development we needed a high-level product plan that lays out what the releases will contain so we can coordinate development efforts between the two companies.
• Ideally the team would all be collocated and no one would work remotely.  However, this is often then case and the challenges of a distributed team are not that difficult to overcome.  Remote workers will participate in the daily scrum meetings via conference call and visit the office frequently.  We are using Team Foundation Server with Visual Studio Scrum 1.0 process guidance template and the Urban Turtle plugin to help with team collaboration so we will have a Burndown chart and a virtual taskboard visible to everyone.
• Ideally people's time would not be split with other projects.  Since there are several issues around the testing staff, (i.e. no testing experience, remote locations, and time shared with other projects) we will probably make some changes here. Training, time commitments, rotating one resource on to the project full-time each sprint, have them only responsible for running manual tests, hiring another full time experienced tester, could all help the situation.

In an ideal world, on smaller projects, or projects for smaller companies, you might have everything setup exactly the way you'd like to follow all the principles of Scrum.  But in the real world, we work on large projects for giant immutable corporations and we have to play the best we can with the hand we're dealt.  Obviously we have a lot of challenges ahead of us on this project, but if we keep to the principles of Scrum and the spirit of an Agile progress we will be successful.