If you have been through the Certified ScrumMaster training course you may have seen or been involved in an exercise called the “Daily Scrum From H#%&”. In this the participants each take on dysfunctions which a ScrumMaster may see on their team. The ScrumMaster attempts to hold the Daily Scrum full of these dysfunctional team members without knowing the dysfunctions they are exuding. In the last Certified ScrumMaster course that I co-trained with Bryan Stallings had the following dysfunctions in the exercise:

• Tardy - arrive late for the meeting; offer a weak excuse
• Without focus - give a rambling update and appear lost as to what you will work on next
• Interruping individual - ask a clarifying question on someone else’s turn
• Hidden impediment - mention an impediment but don’t be obvious about it
• Noisy “Chicken” - start your update by saying, “I’m only an observer,” and then proceed to report on things the group wouldn’t care about
• Design zealot - focus your update on a design question or issue and attempt to get resolution in the meeting
• Poor task communicator - refer to your tasks in the most generic sense, such that your update is vague and without context

At the Scrum Gathering 2006 in Minneapolis I became a cast member in a Dysfunctional Daily Scrum video. The video was posted on YouTube here.

Although teams may find themselves confronted with dysfunctional behavior on their teams, in my experience I have found two particular issues with Daily Scrums more often. The first is the team feeling like they are being micro-managed and the other is the use of task unique identifiers.

When first starting to use Scrum many teams apply the tools, processes, and practices of their current working environment into the Scrum framework. This behavior causes many teams to think that Scrum is making their environment even worse. The adoption of Scrum and doing it effectively most often requires a mindshift change.

A Daily Scrum that feels like micro-management, in my experience, is usually caused by applying the traditional task update status to the 3 questions discussed by each team member in the Daily Scrum:

• What did I do since last meeting?
• What am I going to do?
• What impediments do I have?

The application of the task update status with your traditional Project Manager (not that all PMs were like this ;)) causes the team members to spend much more time on the first question, “What did I do since last meeting?”. This focus leads their conversations into long spirals about detailed information that may be redundant or not valuable for the rest of the team. Also, there tends to be an unwillingness to spend any time on the impediments because this may indicate that we do not know how to do our jobs. This pattern begins to erode the value of the Daily Scrum and the team may move to meeting every 2 days, a week, or not at all over a period of time.

When I am coaching a team and I come across this pattern I start asking the team members why they feel micro-managed. The most common responses that I have gotten are:

• Nobody cares about what I am doing
• I do not see any value come from this meeting
• The ScrumMaster always is checking on what I have done
• I already updated my tasks on the Sprint Backlog, why do I have to discuss my progress again
• Everybody talks too much and we go over the 15 minute timebox

After investigating further into the root cause the most common suggestion that I give is to focus more on the last 2 questions, “What am I going to do?” and “What impediments do I have?”. I tell the team that the purpose of the Daily Scrum is not to scrutinize their work but to better understand the state of our Sprint and plan accordingly. By discussing what we each are going to work on our team can better understand potential dependencies, issues, and communications which need to be discussed after the meeting. The impediments which are brought up can be assessed to figure out if the team can resolve them internally or if the ScrumMaster will need to find a way to resolve them. The removal of impediments is essential to enabling the execution of successful Sprints and accelerating the team’s velocity.

Another problem that I have commonly seen on Scrum teams is the use of user story and task unique identifiers to indicate what each team member is working on. Be aware that the use of these identifiers to discuss tasks being worked on could lead to a few issues:

• Product Owner not understanding team member’s discussions in the Daily Scrum
• Team members not re-planning based on information discussed in Daily Scrum
• Just communicating each team member’s status and not communicating the right information to the ScrumMaster
• Daily Scrums which are too fast and not valuable
• Too much focus on the ScrumMaster as status gatherer

Although it may be good for our tools, historical data, and traceability needs, unique identifiers on user stories and tasks are not good communication tools. Depending on the situation, I may suggest that a team start using a task board which is visible during the Daily Scrum or better yet use the human readable description of our user stories and tasks to communicate with team members. This can help to alleviate the overhead of looking up or ignoring what your fellow team members are working on.

In conclusion, the Daily Scrum is an essential practice in the Scrum framework. If the team feels like it is a micro-management tool, are not easily understanding the discussions, or any other bad vibe degrading it’s usefulness then we must conduct root cause analysis to find out what the problem is. Address concerns head on and work as a team to figure out how we can make the Daily Scrum an effective use of our time.

It has been a very exciting month for me here in the Puget Sound area. My son was born on December 23rd at 1:59am and we named him Amun, which means ‘peace’. He is beautiful and my wife is doing great. It is probably obvious why I have not been blogging lately. Here it goes and lets see if I can spew something coherent.

In between timing contractions, being there for the delivery, and irregular sleep I started pondering a very simple question. If organizations, executive management, architects, developers, QA, project managers, and business analysts all keep doing things the same way in IT, how could they expect to improve the results of their work over time. All improvement comes with change and it is best to make these changes as a result of real data.

There are many times that I sit down with teams who want to implement “Agile” but have too many constraints surrounding their projects to enable successful change. Some of the constraints I have heard in the past include:

• We are using an architecture which is being developed by another team using Waterfall and they are right on time. We are finding it difficult to know when they are going to be delivering any functionality that we may need for our Scrum teams to use.
• The person we identified as our Product Owner is not able to dedicate much time to the project. Will this cause any issues.
• Our QA team is within another part of the organization and can not dedicate resources (I like the word ‘people’ here) to any one project.
• The production operations organization can not deploy releases every month. It takes too much time to review and accept an application through our deployment procedures.
• QA must be independent of our development organization due to regulatory compliance. We don’t want the QA team to be influenced through their friendship with a developer.
• Product Owner - “I am not sure what the value of this feature is but it was asked for from somebody above me.”
• We already do most of the things in Scrum already. I guess we can just keep doing things the same way.
• and there are many more…

When coaching any team or organization about what “Agile” can be for them it is imperative from the start to set the correct expectations. In order to gain the benefits of Scrum, XP, or any other “Agile” method we must understand how the Agile Values and Principles are going to affect our team or organization. No longer will we be able to hide our dysfunctions (hey, we all have them) behind project plans, risk mitigation strategies, and lengthy release schedules. We must deal with our dysfunctions each day and find ways to improve our team and supporting environment. Over time, the change will become less frequent and impactful as we better understand where we actually stand. From here we can see more clearly how to align the vision and goals of our organization with the dreams and aspirations of our team members. This will give the group power and agility to attain audacious goals through excellence in product delivery, productivity, and quality.

Now back to the fun stuff. Changing a diaper. 😉 Have a great New Year everyone! I am already having one!

If you have ever worked on a project which used Scrum then you may have run into the “blank backlog” issue. Where do we start? Since there are no perfect answers we will need to work this out through experience. I have been using a “Product Backlog filler” exercise with customers which has been refined through these experiences.

When starting a Scrum project it is recommended we begin with a vision. A high level plan of what the product will do from which we can derive a Product Backlog from. I have found that this vision does not have to be written in “stone” (or paper if that is what you use…) but it should be in a form that can be communicated effectively (pictorially on a white board potentially…). A vision is usually followed quite closely by a list of value statements for the consumer of the product. If we can identify the value for our consumers then we have a nice foundation to start driving out user stories from.

In most situations I have found it best to have the Product Owner and ScrumMaster (possibly myself) work on the initial Product Backlog. This allows for a coherent product development story to be constructed before working with the delivery team. This is not a hard and fast rule since I have recently broken this trend because of the project type and delivery team experience with Scrum. When we have a list of product consumer value phrases created I will place these on a white board or visualization instrument (easel pad, index cards taped on a wall, etc…). We then ask the question “Who wants and supports these value statements?”. This creates a discussion of potential roles and parties to the product being developed along with defining their characteristics. While listing out these roles and parties we may generate some that are not valid or can be merged into a more suitable description. This is great since the discussion will then better define the role and party boundaries.

After this discussion of the roles and parties either attaining or supporting the value statements, we can start to work on the “goals” which will give them the list of values stated. This will usually start with a value to be achieved and a role or party that is interested in this value from the product. Once we decide on these then it is just a matter of writing as many “goals” as possible to make this happen in the product. I use the term “goal” as it is identified in the User Story template by Mike Cohn:

As a <user>, I want to <goal> in order to <value>

Where is one of our value statements identified from the vision, is the role or party identified to attain or support the value statement, and is the list of features which will achieve the value statements for our identified roles and parties. Now that we have all three parts of the User Story template we can write out the actual user stories and put them into our Product Backlog to start a “good” conversation with the delivery team.

In this blog entry I have identified one method for driving out user stories for a Product Backlog which I have found to be useful. There are many other methods which achieve the same goal. I suggest that anybody using Scrum should take a look at how user stories can be used as a powerful way to capture features to be developed in their products. The template developed by Mike Cohn for user stories has been quite powerful in projects I have been involved with and is further explained in his books “User Stories Applied” and “Agile Estimating and Planning”. Take a look at these for more information and other supporting methods for developing products through the user story medium.

One of the 7 main principles in Lean Software Development is “Build Integiry In”. “Integrity” is defined as “free from flaw, defect, and decay”. Although there are many ways to build integrity into our products I wanted to suggest how Scrum and XP practices can assist in achieving this goal.

• Free from “flaw”: In order to reduce flaw in our products we must align development with the driving business factors. We can do this by allowing business to provide a prioritized Product Backlog which is stack ranked with the highest value items at the top. We may also automate our acceptance criteria for the features pulled into a Sprint Backlog as “executable requirements” which may be regressed to make sure the intent of the implemented features continue to meet customer need. You may use a tool like StoryTestIQ to automate your acceptance tests.
• Free from “defect”: In traditional approaches we may design and code our feature implementations and then hand off our builds to the QA team to run manual tests against the build. The amount of time from when a bug is introduced to when it is discovered, handed back to the development team, and then ultimately fixed could be weeks or months. The introduction of Test-Driven Design has decreased the amount of time to progress from introduction of a bug to fix into minutes or even seconds. Writing the tests first improves overall test coverage in our product development and enables automated regression of unit level tests.
• Free from “decay”: Again, the prioritized Product Backlog which places the highest value items on the top to be implemented first in the product development life cycle decreases the amount of decay introduced into the product. The third leg of the Test-Driven Design mantra, “refactor”, also decreases decay in our products by continually evolving the design to meet the current needs. If our test coverage is high enough to allow modifications to the product design but still assure the functional integrity then refactoring may be performed with minimal risk. Continuous Integration is another practice that we may use to minimize decay in our products by notifying the delivery team when flaws, defects, and integration issues have been introduced. If we develop in large batches of features over extended periods of time there is technical debt which accrues and must be dealt with in stabilization phases to remove the decay from our product.

It is important to understand “integrity” and how we can build it into our products. This will allow us to deliver incrementally in short iterations, attain the benefits of emergent design, and increased value of product features for our customers.

I am sure there are going to be some people who think it is crazy but my wife and I have implemented Scrum for our home improvement needs. We do not have enough data to know if it is working yet to help with our home improvement delivery but it has already allowed us to understand our prioritizations and how much there is to do. Of course, my wife is the Product Owner and I am the ScrumMaster. Here is how we implemented it:

1. We got together on a weekend morning and went through the house room-by-room and eventually cover the yard for what is left to do around the house. We captured these items on index cards in a very basic form such as “This is what we need to do in this room”. This took about 1 hour.
2. After we had all of our initial index cards filled out we sat them on the living room floor and decided on a plan to get these prioritized. We decided that using a method to place a cost for each would be a good first step. We developed a high, medium, low, and no cost equivalent that seemed to work and placed the “H”, “M”, “L”, and “N” representing these costs on the top right corner of each card. This took about 15 minutes.
3. We separated the index cards into their respective cost class so that we could prioritize each pile in a cost arena separate from the others. We prioritized each cost pile and went over our priorities with each other before moving on. This took about 30 minutes.
4. After we had each pile separated and prioritized based on cost we decided to take the highest priority of the top index cards on the separate piles and add it to the Product Backlog as the next highest item. This took about 20 minutes.
5. Now that we had a prioritized Product Backlog we decided to create a Sprint Backlog for the next 2 weeks. We captured about 12 of the top Product Backlog items and then placed them on the countertop and eventually into a wall mounted mail holder.

During the next two weeks we got to finishing off each of the Sprint Backlog items. We were not able to finish 3 of the Sprint Backlog items due to a change in the Product Owner’s taste of fabrics and solutions. So far it seems to work. We tear up the index card once it has been completed and add new index cards to the Product Backlog and reprioritize it every 2-3 weeks. Some of the things, from my point of view, that we must work on is getting into the cadence of a Sprint and figuring out what Product Backlog readiness means for our Product Backlog items.

My wife let me know that she felt a bit better knowing what we needed to do around the house. I felt better because we could recognize when items were getting completed. I hope that we are able to keep this up with a baby on the way soon and the continual increase in activities of our 3 year old daughter. When discussing a ScrumMaster in the CSM training course we always say a “Dead ScrumMaster is a useless ScrumMaster”. This may be our biggest risk. 😉

Over the past year I have been working with some great folks at SolutionsIQ. Before taking this job it was apparent to me that the Scrum and Agile movement is where I felt most comfortable. Applying the values and principles along with the Scrum framework and XP practices I have seen an increase in success for many of my projects. I must say that working in an environment such as SolutionsIQ where Agile is the norm, and we wouldn’t have it any other way, lifted my passion for software, teams, facilitation, training, and coaching. That is why I recently applied to become a CST (Certified Scrum Trainer).

After working on Agile teams for a while I thought back to when my own career started on this path to empowered teams, removal of waste, and just-in-time development of requirements. I was brought back to a cellular corporation where I was the first developer on the team which was looking to provide a customer service portal. I started out creating prototypes to show directors and managers in the company what this portal could do. Once the project was funded I helped to pull together the initial requirements for our first release and worked with a new team to deliver it. After a couple of releases I went to PMI training and had a good instructor, although I had no idea they were so good at the time, who discussed a release planning method with customers, project managers, SME (subject matter experts), and the development team. Immediately I tried this method out for the next release of our product with great excitement. We had already delivered for 3 straight quarters to production and our customer was quite satisfied with the work we were doing. The project had sub-components which were rated first and third on the list of top initiatives for the entire division. We had done this while flying under the radar since we were their first ever externally facing web application and we had architectural control over infrastructure and design.

We started out that meeting with huge stacks of post-it notes and everybody we needed to do release planning with a recently increased team size. We had a list of functionality which we hoped to deliver this quarter and the whole group worked on breaking this functionality down into smaller units of work that could be estimated more easily. Although the iteration was for 2 months, the theme of the meeting did seem similar to what I now do today. One big difference now is that I almost never plan for more than 2 weeks. We started placing post-it notes onto the white board and discussed them amongst the team regarding design and any dependencies we might have with each piece of functionality. Approximately 12 feet of white board space was plastered with post-it notes from top to bottom. Notes were written along side the post-it notes on the white board to signal particular areas of interest in the plan. After four hours of planning in that room we ended up with a rather good understanding of what we could deliver in the next product increment.

That quarter we had great success in the delivery of a release and incorporating new people into the team. We had grown from 5 to 12 before the third release and up to around 20 people before starting the fourth release. I remember going into my manager’s office after managing the 12 people during that third release and saying “I don’t think it is good for me to manage that many people at once”. I suggested that we promote two other people on the team to lead sub-teams and my manager was very helpful in implementing this plan. I appreciated that very much. I now live by the “7 + or - 2” rule with only minor exceptions.

I began my application process to become a CST in September and found an ever increasing twist in my gut due to excitement, late nights, and even reflection about where I am in my business and personal life. Having a great mentor like Brent Barton to help me along the way has been incredibly helpful. After finishing my application I felt relieved but also a slite bit of trepidation about my prospects. There are so many great ScrumMasters and Agile coaches out there who are probably in line for CST certification. I hoped that I had the right stuff to make it on the list for this year’s Scrum Gathering interviews.

On Thursday, October 5th, I got my invitation to be interviewed at the Scrum Gathering event on November 15th. I can’t tell you how excited I am to have a chance at becoming a CST and working with some great people in our industry. Please wish me luck as I take the plunge. Thanks.