In your first few sprints there will not be many defects in your story backlog. Therefore, those sprints will almost exclusively contain new development stories. However, you will reach a point where defects begin to accumulate. As any good scrum master would do, you will turn these defects into new stories and have the product owner (or business sponsor) prioritize them with the remaining stories in the backlog.
For product owners and managers that are new to Scrum it is difficult to envision how defects will be managed. Its difficult because they expect that each sprint is going to be 100% focused on delivering new stories. This perception can be especially dangerous when the manager and/or product owner are trying to set expectations with upper management on project milestones.
You, as the Scrum Master, need to help the manager and product owner anticipate defects. We know that the software is going to take as long as it takes to build. Managers and Product Owners just can't live with a statement like that. Rather than fight this fact you need to find a way to lead in the face of it. You need to inject yourself into the milestone planning process and guide this planning in a way that anticipates defects by planning defect stories for the later sprints in the project. The following chart depicts a hypothetical reduction in new story velocity over time.
In my continuing series of Tips from a Scrum Master, we look at the daily stand up meeting.
The daily stand up meeting presents the Scrum Master with a very timely view into the team's planned activities for the day, or at least it should. Many stand up meetings that I have observed over the years have wandered a bit from the all important intent of team members "Making commitments in front of peers". Instead people fall back into the more comfortable position of reporting what they did yesterday. Don't get me wrong, I want each member of the team to quickly summarize yesterday's accomplishments, but I want it to be very quick, something like, "Yesterday I planned to finish the work on story 215. I have about another hour's worth of integration testing today before it will be finished."
Reporting on the work from the previous day validates that the commitment was met. However, if a commitment was never given then the team member is just telling you what they did the day before and these two things are completely different.
Repeatedly delivering on commitments builds a pattern of success. This pattern of success becomes addictive. People enjoy the satisfaction felt after accomplishing a goal. When you have a team that has built a reputation for delivering on their commitments they focus very sharply to keep that feeling and to protect that reputation. As the Scrum Master you might need to push the team harder at times if they become too conservative with their daily commitments, but only if their conservatism slows down the sprint.
So give it a try. Ask the members of your team to focus their updates on what they plan to accomplish today and make them accountable for delivering on those comittments. Start building a pattern of success for your team Today!
This post is the first in a series of posts that I am publishing targeted at Scrum Masters and Scrum and agile practitioners.
Precious and few are the days in a sprint. You must maximize each day of your sprint for optimal results. I mark time on sprints by tweeting the day number and sprint number each morning, something like "Sprint 2, Day 4". This helps me focus each morning and it reminds me of the ever dwindling time remaining for the sprint and for the project. Consider doing the same via Facebook, Twitter, LinkedIn or your favorite Social Networking site. You'll be surprised by the results and by the interesting conversations that you start.
A straw-man writeup has been proposed by Mark Reinhold for including
Lambda expressions (or Closures) in Java 7.
Over the course of my career as a developer I have never used a language where closures were a tool in the developers' toolbox. Because of this my brain does not create solutions using closures. Since my conversion to Test Driven Development I work hard to ensure that I am implementing the simplest solution possible for the feature that I am developing. For this reason I have titled this post "Does Java Need an 'Extract Closure' Refactoring?" rather than something more obvious, such as "Does Java Need Closures?"
I won't write any code using closures because a closure isn't the simplest thing that can work. I know this because of the millions of bits of code that I have already written in Java without closures.
The only way I can envision myself using a closure would be as the result of a refactoring. For me to extract code into a closure it will have to make the code easier to read and/or improve the reusability of the code.
I'd really like to hear from developers with hard core experience using closures. Please reply to this post with your thoughts.
Dear Garmin,
I recently traveled out of town on business. We flew a commercial airline to our destination, however I packed my Garmin Nuvi to make getting around easier for us once we arrived. On a similar recent trip we joked about the fact that a few of us owned GPS devices but that none of us thought to bring it.
When we loaded into the rental car I announced that I had remembered to bring my GPS with me. A few of my traveling companions did not trust the Nuvi to the same degree that I trusted it. They insisted on double checking the directions calculated by the Nuvi against the paper directions they brought with them.
The Nuvi performed flawlessly when we asked it to take us to the hotel, to our business meetings and to a restaurant near the hotel. However, on the return trip to the airport we needed to stop to refill the gas tank in the rental car. When we exited the highway I asked the Nuvi to find the closest gas station. Since we took the exit for the rental car return I expected the Nuvi to find one or more gas stations very nearby. The Nuvi churned for a minute and then presented me with a list of gas stations within 3 miles of our current location. I blindly selected the first gas station on the list. By default the Nuvi displays the closest item in the list first.
Following the Nuvi's directions we began to head down a steep, windy and seemingly single lane road. When the Nuvi voice instructed me to turn left at a street whose name included the word "Ferry" my heart sank from concern and embarrassment. I wondered, "Surely, the Nuvi would not instruct me to cross a river via a ferry to find a gas station, would it?" As we approached "Ferry Rd." my fear turned into my reality. There to our left floated the ferry dock in all of its "rickety glory". The Nuvi voice instructed us to "board the ferry". My boss and the 2 other passengers groaned in chorus. I wanted to stop the car and jump in the river to escape the embarrassment. Instead I calmly pulled over and spent a few minutes using the Nuvi to find another gas station on our side of the river.
Garmin, please, make ferry boats an avoidance option which defaults to "Avoid" out of the box. I promise that 99.5% of the population will agree with me that they would rather NOT take a ferry to get gas, all other things being equal.
This little lesson taught me to take all of the directions that I get from the Nuvi with a healthy dose of skepticism, especially when I am in a new or unfamiliar city. No longer will I hit the "Go" button without viewing the route to ensure that it meets with my expectations.
Respectfully,
John Sextro
The lack of propinquity could be killing your project and you don't even know it. Propinquity is a "silent" killer. In order to prevent the death of your project you must first understand propinquity.
Miriam-Webster defines propinquity as
"nearness in place or time". In social psychology the theory of "The Propinquity Effect" asserts that there "is a tendency for people to form friendships or romantic relationships with those whom they encounter often". Similarly, in 1966 anthropologist Edward T. Hall introduced the concept of "Proxemics" to describe set measurable distances between people as they interact. E.T. Hall hypothesized that, "The influence of two people on each other is inversely proportional not only to the square of their distance but possibly even the cube of the distance between them."
As it relates to this discussion, I define propinquity as the nearness of the critical members of a project team. I assert to you that project success rates increase as the propinquity (or nearness) of the critical members increases. For instance, a project whose team members work in different buildings in an office park or campus will fail more often than a team whose members work in the same building. Even further a project whose team members all work within 200 sq. feet of each other will succeed more often than a team whose members work scattered throughout a 10,000 sq. foot work area.
In an era of seemingly constant communication among workers via email, instant messenger, text messaging and Twitter you might find it hard to imagine that propinquity plays such a vital role in the success of projects. Many people refuse to accept the hard truth, that these forms of communication poorly substitute for the face-to-face, human-to-human interaction that organically happens when high levels of propinquity exist. Have you ever had a cube neighbor that worked in a different group, but with whom you had a friendship, that moved to another area down the hall, another floor or maybe even another building? How often do you talk to this person today? You were once close, why don't you talk with this person anymore? The reason, lack of propinquity.
It is not that you are too lazy to to pop open a chat window, write an email, walk down the hall, traverse the steps or wait for the elevator...ok maybe it is laziness. Whatever it is, this inhibiting factor is in all of us. By the way, how much do you talk to the new person that moved into your friend's cubicle (or work area)? Scary isn't it?
It is no wonder then that the agile software development methodologies prescribe co-location for all critical team members as a core principle. The creators of the agile methodologies knew, either consciously or subconsciously, of the critical link between propinquity and success in software development. Throughout my 7+ years of practicing Scrum and Extreme Programming I insisted and made certain that my team sat in a contiguous block of cubicles or, preferably, in a team/project room. As a testament to propinquity and agile methodologies stands a track record of success and high customer satisfaction for each of these projects during this 7+ year period. By way of hindsight I can clearly see all of the positive effects that propinquity bestowed onto these projects. In contrast, I can also imagine all of the problems and issues that we might have faced in the absence of propinquity.
If you feel that your project suffers from problems with communication, team spirit, shared vision, or productivity then move the team into a team/project room. Even if the team already sits in close proximity to each other, move them into the room. It will amaze you how much of a difference you will see just by removing a barrier as small as a cubicle wall.
As a Scrum Master I get a lot of questions from my friends and associates in IT asking how they can get started with Scrum and/or Agile on their projects. I’ve been asked and answered the question enough lately that I have decided to add it to my personal FAQ (Frequently Asked Questions). Lately I have been treating my blog as an FAQ for my professional life, a concept eluded to by Jeff Jarvis in his book, "
What Would Google Do?" which I just finished reading recently. The following advice is based on the answers that I have been giving, but has been improved and refined with each additional conversation that I have. It is my hope that we (you and I) can continue to refine this through the discussion that I hope this post generates. So please provide me with your feedback and criticism via the "Comments" section of the site.
How to Get Started with Scrum
The first thing you must do is assess your role on the team. More specifically you need to assess your ability to influence others and to make changes on the team. Every member of a development team (and any team for that matter) has the ability to influence others on the team. If you need advice on how to use your influence or on how to assess your ability to influence others I recommend
http://www.influencewithoutauthority.com/, many years ago I read the book with the same name and found the information and advice in this book very valuable.
Now that you are aware of your influential abilities you are ready to get started with Scrum. Unfortunately you can’t just wave a magic wand and instantly convert the project from "Waterfall" to Scrum, the barriers to such a wholesale change are too painful and expensive to overcome. What you can do is start small. I have found that the best way to introduce a group to Scrum is via the daily stand up meeting. The daily stand up meeting or "Daily Scrum", as it is known, is a good first step because it has the lowest risk to the project and the least adoption barriers to overcome. After all, who could stop you and the other developers from taking 15 minutes in the morning to stand up and discuss what you plan to accomplish for the day. I can’t imagine anyone even wanting to stop you.
The Daily Scrum is the best place to start because it costs nothing, you don’t need anyone’s permission to start doing it and it is one of the most "value-added" activities performed as part of the Scrum Methodology.
How to Start Conducting the Daily Scum
- If you have any doubt in your mind about a member or members of the team and their openness to adopting the Daily Scrum leave them out initially. You only want to invite people, initially, that will be supportive of the change.
- Speak with each person that you are going to invite ahead of time to let them know 1) what the meeting is for; 2) how the meeting will be conducted and; 3) what you hope to accomplish with the meeting. This is your moment to "Sell" each person on the concept so I suggest that you spend some time coming up with a few talking points before heading into the first person’s cube.
- Schedule the meeting. Be sure to select a time that works well for everyone that you are inviting. The last thing you want is for people to have a valid reason to skip the Daily Scrum.
- Execute. Have the meeting every day. Never cancel the meeting and try to avoid changing the time and meeting location. If someone misses a meeting, get on them about it. Tell them how important it is for them to be at the meeting. Make them feel wanted and important and they won’t miss again.
How to Run the Daily Scrum
The Daily Scrum is very easy to run. Every one stands during the Daily Scrum, it helps keep the meeting short and keeps the formality of the meeting to a minimum. It is important to stress the fact that the meeting is not just another status reporting meeting. The most valuable part of the Daily Scrum is derived from each member of the team committing, in front of peers, to accomplish a finite list of tasks over the course of the day. These commitments enable the team to plan and react to the activities planned for the day and enables the team to adjust course if the planned activities do not align with the current project priorities.
The following image is a slide created by Mike Cohn of Mountain Goat Software. It is a very good "one-pager" that you can hand to the participants at your first Daily Scrum to help guide the participants in their preparation for future Daily Scrums.
Next Steps
Ok, you are ready. What are you waiting for? Go make it happen. I would love to hear your feedback on this approach. If you use it on your project I would love to hear about the results. If you need more help feel free to send me an email at john at 9principles dot net.
My next blog post on this topic will address taking the next step to continue on a course towards implementing Scrum on your project.
