Mitch Lacey & Associates - Scrum and Agile Training

Technical Interviewing - You're Doing it Wrong!

Sat, 02 Feb 2013 20:22:00 -0600

Last week at the ALM Summit, Microsoft colleague Jonathan Wanagel and I presented a talk titled “Technical Interviewing – You’re Doing it Wrong!” and it was one of many highlights of the event. Download the slides here.

We identified eight anti-patterns that people should avoid. As Jonathan stated in the talk, “many of them were likely created at Microsoft” – and while I can’t say that, I can say that I've seen all of them at many companies around the world.

What we did was break them down into why these are bad and what to do about it using a forecast and the candidate experience.

The patterns we identified

The Riddler
The Disorienter
The Stone Tablet
The Knuth Fanatic
The Cram Session
Groundhog Day
The Gladiator
• Hear No Evil

Here is a quick summary of a few of them. I’ll post a link to the video and audio once it’s up.

The Riddler

This is the person who asks puzzle questions to “see how you think”. An example of this would be the “messed up interview question” post on my site.

The Disorienter

Similar to the Riddler, this is someone who asks programming questions that have nothing to do with the job at hand. This could be writing Sudoku puzzles or my favorite, parsing roman numerals.

The Stone Tablet

This is the person who has a candidate write code on a white board. Really? A white board? I mean, I can understand it because that’s how all modern development is done and it’s obviously the best way to test someone’s skills.

The Cram Session

This is the person who “studies” for an interview, either by asking friends or by looking up common interview questions. The funny thing here is all one needs to do is answer the right questions and they have the job. What the skills are don’t really matter.

The Problems

The problem with each of these techniques is that they don’t create a realistic picture of the candidate’s skills or competencies. They create a poor forecast as well.

Forecast

To forecast is to make a prediction in advance. When we hire people, we make predictions based on written and verbal communication as to whether a given person will be a good fit, both culturally and skillfully, in the company over a period of time. Although, some organizations do this by having a trial period, most companies in the tech industry hire solely based on the interview. That means the forecast made in the interview has to be fairly accurate. Yet this forecast is only as good as the common understanding of why and how they are hiring.

Skills, Competencies, or Both?

Let’s say your reason to hire is that you need more C# programmers. Most companies would screen prospective candidates based on that particular skill: Do they know C# or not? While that makes sense on the surface, it might not be the best way to make a hiring decision. Skills, after all, are easy to learn and can be picked up in a matter of months. A developer who knows java but has never tried C# will be able to pick up C# after a few months, especially when paired with an experienced C# programmer. This assumes, of course that the developer has an ability and willingness to learn, to ask questions, to share his strengths and weaknesses; to put his ego aside and have the courage to learn a new language in order to best help his team.

Let’s reverse that, then, and imagine we hire a very experienced C# programmer who is uncomfortable working in pairs. He doesn't want to improve or branch out from C#, so can never be taught new languages. And he doesn't enjoy mentoring others, so he cannot share his extensive skill set. No matter how senior or experienced this developer is, he would not be a good fit at Scott’s company, or on any agile team, because of the misalignment of values.

Based on those two scenarios, screening candidates should always include competencies—how a person thinks, how that person interacts with others, and what that person values. These will impact how quickly he can assimilate with a team and how rapidly he can learn new skills. After all, you might need that same person to learn yet another new language a few projects down the road. In general, you should hire for long-term fit, not for short-term expertise.

Nominated for the Scrum Alliance Board of Directors for 2013

Fri, 05 Oct 2012 08:37:00 -0500

I am pleased to announced I have been nominated to the Scrum Alliance Board of Directors again. This is a three year term, spanning 2013 through 2015.

I am a long way from the position. Today I submitted my summary position statement, listed below. It will be reviewed by the nominating committee to see if it is a fit, and if it is accepted, I will be one of six people on the slate for members to vote on in November. Even if I don't make it again, it is a great honor.

Once you read this, please add your thoughts to the comments. I'd like to hear what you think. Thank you all for your support.

Summary Statement

In June, 2012, the Scrum Alliance revised its vision (http://www.scrumalliance.org/blog/151-scrum-alliance-newsletter-june-), which is now “to provide Education, Community, and Advocacy to anyone interested in Scrum.” As a Scrum author and practitioner, I share this vision and have been actively working in my own community to realize it.

Over the last five years, I have been working with the University of Washington on visioning, building, teaching and refining their Agile Certificate program. This is a program that went through some rough patches as we worked out how to solve instructor retention, course content, UW employee turnover, and class attendance issues. The program in place for 2012-2013 is the best yet, and enrollment is at an all-time high. Students range in backgrounds from software to embedded systems to physical hardware.

This program was born out of a passion and vision that I had, one that brings agile, Scrum especially, to universities both in an extended education format and also as part of the curriculum for undergraduates. Coincidentally, it also ties into the number one item in the newly revised Scrum Alliance vision, Education.

As a community-elected Scrum Alliance Board Member, I would work to expand the UW offering, using it as a template to help bring Scrum to more universities throughout the world, starting with the United States and other countries where we have a strong academic following. Doing so would further strength the reputation of the Scrum Alliance as the worldwide leader in helping everyone to learn about Scrum.

My focus on university-based education would also help the Scrum Alliance with its second vision item, Community. By investing in education, we would build community, expanding it beyond Scrum Gatherings. Plus, what I learned as the conference chair for Agile2012 would also help us improve our existing Gatherings. By expanding education and improving Gatherings, we would create an opportunity for people from all industries to share, learn from, and educate each other.

Last, the expansion of university-based agile education would also help the Scrum Alliance with its third and last vision item, Advocacy. By bringing together people from a variety of industries and backgrounds, we would create opportunities for people to connect, grow, and help their companies adopt Scrum. Not only would the execution of such an endeavor help students, it would also further validate Scrum as the leading framework for executing work in a variety of industries.

About Mitch – I was one of two Community-elected Scrum Alliance Board Members in 2010. My term ended in December 2011. I have institutional knowledge that will make me more effective starting on day one as I am familiar with the issues. In my time on the board, I never participated in a vote or advocated a position that would benefit me professionally, often arguing, out of principle, in favor of decisions that were disadvantages to me. I also served on the board of the Agile Alliance and was the conference chair for Agile2012, experience that would benefit the Scrum Alliance in terms of Scrum Gatherings.

---

Effective Communication for Distributed Agile/Scrum Teams

Sun, 16 Sep 2012 09:46:00 -0500

I’ve been getting a lot of requests lately of people asking for guidance for effective communication techniques when working in or with distributed agile/Scrum teams. I outline some approaches in my book, The Scrum Field Guide, but it is not all inclusive.

As you research this more, you will find standard answers, including

Have joint team daily standups, where one team is either getting up early or staying up late
Use real-time video if the teams are close enough to each other to have time zone overlap
Have a phone line always on where team members can just talk and the other side responds
Distribute vertically (north/south) where time zone impacts is minimal
Have dedicated office hours where the team will always be available
Travel frequently

These are all fine approaches, however, they don’t fully solve the core requirement for teams, which is to have rich, effective and highly saturated communication between all team members. Whilte I'm not sure anything can fully solve that core requirement, I have been experimenting wiht a new technique that goes a long way toward improving communication.

Consider two Scrum teams; one in India and one in San Francisco – roughly 12 hours apart from each other. Well call them ST-I and ST-SF. Getting these two teams to have a good work-life balance and maintain the goal of rich, saturated communication will forever be a challenge and will only (likely) be solved by extensive travel.

What we started doing was to have ST-I record a video at the end of their day. They put together some notes and checked the video and the notes (not a large status email) into the branch. When ST-SF came into the office, they were able to watch the video, look at the notes and pick up where their sister team, ST-I, left off. As their day progressed, they kept their notes up to date and at the end of their day, they created another video and put it in the branch, right alongside the code. The videos would be five to 15 minutes in length and would be done by screen captures, phones or other immediately-available technologies and stitched together with a Mac or Windows application.

This worked fairly well; however, the video wasn't synced with the notes, which were often 2-3 pages long. That meant that the team members were trying to read the notes while simultaneously watching the video. This proved impossible. The team members found they had to go back and watch the video a few times to get it. So the video and notes were working, but the solution was far from ideal.

I then started talking to a former Microsoft employee who had built a tool to solve the syncing issue. His company is called 9slides and you can see it at 9slides.com. What it does is allows the user to create video and a quick-and-dirty powerpoint presentation (the notes) and sync them together. So now we have ST-SF creating a 9slides video, sending the link to ST-I where they can watch it, review the slides and video synced as one, and start their day. So far this is working very well. Our one remaining issue, which wouldn't be a problem for all teams, is that occasionally ST-I or ST-SF will be working on sensitive or proprietary information that they are not comfortable presenting using the tool. That, however, is a problem for another day.

If you’re doing distributed agile development, I *highly recommend* 9slides for you to sync your content and begin syncing your teams with video and content.

Post your results here.

Recent Podcasts for The Scrum Field Guide

Mon, 02 Jul 2012 04:28:00 -0500

I had the privileged of being interviewed by Dave Prior from Projects at Work and Tom Cagley from Software Process and Measurement Cast.

Enjoy!

The Big Wall: Prioritizing and Estimating Large Backlogs

Mon, 02 Jul 2012 04:06:00 -0500

You’ve just finished a great story-writing workshop with your stakeholders. You’re excited about the new product and are anxious to get started. Until, that is, you get back to your office and look at the mountain of stories that you’ve somehow got to estimate and prioritize. All your excitement disappears as you face the hard truth: You have no idea where to start.

The sheer size of new product backlogs can be overwhelming. That’s why you need to attack them with something even bigger. I’m talking about a club that’s about 14 feet wide and 10 feet high. You need to find yourself a big wall.

While planning poker is a fantastic tool for estimating user stories, it’s difficult to imagine tackling a pile of hundreds of stories, one at a time. That’s why I use a technique I call The Big Wall. It’s similar to Lowell Lindstrom’s Affinity Estimation, which I was introduced to in 2008, with one distinct difference: The Big Wall technique allows you to consider both size and priority.

The only tools you need are a stack of user stories (get them from your product owner, or if you are the product owner, print them) and a big empty wall, about 14 feet long by 8 to 10 feet high. Then you need to gather your stakeholders and team and plan to spend a day or so getting physically involved with your stories.
If you already have an estimated backlog, you can just do the prioritization section of this exercise. If your product owners and stakeholders have already given you a prioritized backlog, you can just do the estimation section of this exercise. (Your product owner will likely want to revisit the prioritization after the estimates are done. After all, cost has a big impact on priority.) Let’s look in detail at how this would work, beginning with the team’s role.

Team

Given a raw product backlog, you should start with estimation. Instruct the team that the far left of the wall should hold the smallest possible stories, and the far right should contain the biggest possible stories, without regard to numbers. Then ask team members to put stories somewhere on the wall based on those two poles. The advantage to doing it this way is that there is no preconceived notion of what a two- or three-point story is; it’s truly relative based on how big the wall is, which is why it’s nice to have a really big wall.

Stakeholders

Your customers and stakeholders will look at the stories in a much different way than the team just did. They’re not as interested in how many points a story has; they are most interested in finding the stories that relate to them and making sure those stories get done. This may put the stakeholders in conflict with one another. This is OK, in fact, it’s ideal because it reflects reality and helps the product owner make tough decisions.

The first thing I do is explain to the stakeholders why we are here and what we want to accomplish. This little speech goes something like this: “I have met with each of you and have created a set of stories that reflect your wants and needs. The team has spent the morning grouping these into relative sizes. The stories to the left are smallest. The stories to the right are the largest. What I’d like you to help me do is determine the relative priority of all these stories. I’m going to ask you to move these stories up or down inside the taped lines. The higher up a story is on the wall, the higher its priority to the business. If you place a story at the top, I will ask you for justification as to why it’s up there. You may also ask each other why one story is more important than the other. In the end, we’ll know how all the stories relate and have an idea of what functionality we’ll have early in the project and what functionality will happen later. The team will observe and might ask questions to help them better understand a story.”

Remind the stakeholders that if they move a story lower on the wall than someone else did, they need to mark it with a yellow dot. This alerts everyone that we might need to have a conversation about the story’s true priority. I also encourage/expect people to ask, “Who moved this one down (or up)?” or to say aloud, “I think this one needs to move. Who wants to disagree?” This enables a conversation to happen between the interested parties without facilitation. If a discussion goes on too long without resolution, the facilitator (usually the product owner), should collect the card, note the two stakeholders who cannot agree, and make a note to meet with them privately later.

While the team is in the room for this exercise, they are not active participants. They are observers, taking notes on the behavior, the interactions, and the reasons why certain stories are rising or falling in priority. They can also answer any stakeholder questions, if needed. If there are stories that the team couldn’t size with confidence because it required answers from a particular stakeholder, the team can also ask questions about those stories, as time allows.
The goal of prioritizing as a group is to help all stakeholders understand the priorities of various stories and how the others view it. The exercise should take between two and six hours, depending on the number of stories and the number of stakeholders.

By the time you are finished, the stakeholders will be able to see the start of a release plan. If you know the team’s historical velocity, you can even give them a rough range of which stories in the upper-left quadrant will be finished. For more information, see Chapter 4, “Determining Team Velocity,” and Chapter 11, “Release Planning” in my book, The Scrum Field Guide: Practical Advice for Your First Year.

Playing the Game Online

This exercise can also be done online thanks to The Innovation Games company.

You can find more information via the following links

Well Run Retrospectives for Scrum and Agile Teams

Sun, 03 Jun 2012 21:27:00 -0500

I often see Scrum teams struggle with the retrospective. Retrospectives are not easy. They take time, they take commitment, and they take courage. When the pressure’s on, they’re often the first thing to go. In the rush to deliver a product, having a meeting to vent your frustration can seem like a waste of time. And if that’s all your retrospectives have become, I agree. You are wasting your time.

That doesn’t mean, however, that you should axe retrospectives. On the contrary, if your Scrum and agile retrospectives have become meaningless, it’s even more important that you do them, and do them right. Why are retrospectives so important, you ask? And what are some key components of an effective retrospective in a Scrum / agile project? Let’s answer both of those questions.

Give Retrospectives Their Due Diligence

Retrospectives are a key part of a Scrum team’s inspect-and-adapt cycle. Every other part of the sprint (sprint planning, daily standups, the sprint review, product backlog grooming) focuses on delivering working software. The retrospective is the sole opportunity for team members to examine how they work and how they are working together. It’s a time for them to learn how to improve, how to work more efficiently, and how to deliver at a higher velocity and with superior quality. Retrospectives are a constant reminder of the need to continuously improve, to always be moving forward. Because when a team stands still, it falls behind.

Retrospectives in Scrum have a more subtle benefit as well. They give teams the opportunity to change behavior and team culture. They are a safe place for team members to share, constructively, feedback with others on how their actions (or inactions) impact the quality, morale, and attitude of the team. Left alone, these small problems fester, like an unattended cut. Retrospectives, on the other hand, allow teams to attend to their small wounds quickly, reducing the chance of infection.

Plan an Effective Retrospective

So, we can agree that retrospectives are valuable. But how do you run them effectively, so that they don’t degenerate into an unproductive complain-and-moan session?

Choose a Facilitator

In Scrum, the ScrumMaster will typically facilitate the meeting, and in XP, it's the coach. That being said, however, any Scrum team member can act as facilitator. You might also occasionally want to bring in an outside facilitator, especially with new teams or those experiencing dysfunction. to ensure the retrospective is focused and effective, the facilitator should plan ahead in regard to meeting format, room setup, and supplies.

Physical Setup

New teams often struggle with staying on schedule during the meetings. As such, I often remove the chairs from the room. I want to prevent people from sitting so that they focus on moving through the parts of the meeting without endless discussion. I have been in too many retrospectives where everyone is leaning back in a chair, debating with no real outcome. I have found that removing the sitting aspect of the meeting helps keep people on track. If you want to keep your seat and have a more subtle reminder of time marching on, you could also display a timer that counts down each time block, perhaps flashing yellow or red as each section of your meeting approaches its close.

Ground Rules

Many meetings are derailed simply because there are no ground rules. Basic ground rules that should be posted in the room and verbally shared at the beginning of each meeting include the following:

Be respectful.
Do not interrupt.
Put away laptops and phones.
Park long discussions in the designated lot.
Recap what you hear to ensure understanding.
What is said here stays here.

Run the Retrospective

The ScrumMaster and all team members should attend each retrospective. I do not recommend inviting the product owner regularly, because I have seen too many times where the product owner hijacks the retrospective to tell the team members where they went wrong, took a bad approach, didn’t listen correctly—you name it. Occasionally, it might make sense to include the product owner, but for most retrospectives, the attendees should be limited to the team and ScrumMaster. In the end, do what works best for your team.

Collect Data

Because the room has already been set up, the meeting can begin as soon as everyone arrives. However you choose to run the meeting, the first 15 minutes or so should be dedicated to data collection. This could be everyone writing on whiteboards, open-space style sticky notes (with people calling out their issues), or a scribe being responsible for writing down ideas on whiteboards.

Prioritize Data

Once the ideas have been collected, they need to be prioritized. You can use virtual currency. It can be anything. I have seen people use ping-pong balls, play money, even just plain “units.” The important thing is to make sure that everyone has the same amount and everyone has the right amount. People spend their currency on the items they want to discuss that were gathered in data collection.

Make a Plan & Choose a Driver

Now that things are prioritized, the team needs time to discuss the high priority issues and make decisions. Timebox this part of the meeting based on the amount of time you have left and the number of items you need to discuss. Bring an egg timer if people have a hard time getting to the point. Once everyone understands the issue, ask, “Is this something we are going to mitigate/fix or not?” If no, discuss why not. Then, move on to the next one. When I facilitate retrospectives and I encounter an issue that the team decides not to fix, I write it down in my notes to capture on the team wiki. That way, when the team comes back and says, “Why didn’t we ever fix this?” I can tell them exactly why we decided not to do it. I find it just helps with dealing with noise later on.

End the Retrospective

Once you have a list of actionable items, or the time has expired, it’s time to close down the retrospective. I like to end it with a one-to-five quick rating of “how was this sprint?” and “what do you think next sprint will be?” One is bad; five is good. People can answer any way they want, but I try to weed out any ill will in the team that may require some discussion. I care about the answer, sure, but I’m more interested in how people answer. What I look for is nonverbal clues that may indicate that what people are saying does not match what they are feeling. I don’t call it out in the meeting; instead I approach the person one-on-one, tell him what I observed, and just ask if there is anything wrong. If the person says that everything is fine again, I’ll let it go and just observe the team over the sprint.

Don’t settle for once-a-sprint vent sessions. Do the work, make the plans, and follow-up on issues from every retrospective. Read more about how the retrospective in Scrum plays a role in the first year in my book The Scrum Field Guide: Practical Advice for Your First Year.

The Case for Retrospectives

Tue, 22 May 2012 21:33:00 -0500

Even with all the good reasons to do retrospectives, they are still the first thing most teams cut when they’re feeling pressured to perform faster, deliver more, or increase quality. What’s ironic is that they are cutting the one thing that could help them both increase their velocity and quality.

New Scrum teams sometimes drop retrospectives because they fail to understand the purpose of the meetings—the why. Dropping retrospectives can cause catastrophic problems—glitches that are relatively easy to solve when they are new can stagnate, fester, and grow into larger issues. Common issues that manifest themselves when the retrospective is cut include drops in quality, a variety of failing tests, lowering of team morale, and more. Dropping the retrospective removes the team’s opportunity to reflect. Without reflection, the team gets lost and wakes up one day to look in the mirror at a very different picture. It’s almost like grooming yourself—most of us shower or brush our teeth daily because, if we don’t, problems start to manifest. Without learning and continuous improvement, teams will fall back to their old habits and wonder what happened—and they will usually blame Scrum for their failure.

Retrospectives drive people to change their behavior over time. To ensure that your retrospectives yield results, make sure that people understand some basic principles:

The retrospective is for the team and no one else. This means don’t go blabbing about what someone said.
Build confidence through small changes. Taking on too much at one time can build frustration. Taking on small, calculated changes and accomplishing them builds confidence.
Own the changes. The team is responsible for its changes, not just the ScrumMaster. Get people involved in driving the changes identified in the retrospective.

Retrospectives are not limited just to sprints. In fact, it is common to see retrospectives after a release, a large unexpected issue, anything. Remember why we do them: so that we can stop, look at the situation, and then make adjustments. In a postmortem, everything has already happened, and our ability to effect change is gone. In a retrospective, we usually are still actively engaged in the project. Consider adding higher-level retrospectives for releases (say every three months) and in case of sudden environmental changes like unexpected outages, scaling up for larger teams with more people, , and creating occasional retrospectives between the team and the customers. The customer retrospective can help you identify areas for improvement between the team, the customer, and the product owner.

Once team members understand how effective retrospectives can be, they won’t ever consider cutting them again.

Read more about Retrospectives and other helpful topics in my new book, The Scrum Field Guide: Practical Advice for Your First Year.

The Case for a Full Time ScrumMaster

Tue, 15 May 2012 19:10:00 -0500

Organizations often have difficulty transitioning to an agile process such as Scrum or XP. Even after they get past the “it’s a fad” or “we can’t work like that” excuses, some in the organization still have trouble letting go of old ideas and habits. One of the most common arguments teams face is that the organization can’t justify or afford a full-time ScrumMaster. Organizations are used to having people wear multiple hats; having a team leader that doesn’t also contribute to the work of the iteration is hard for many to understand.

I am often asked how I measure the impact a ScrumMaster has on a team or organization, and how I convince management to “allow” a person to take on the ScrumMaster role full time. My answer: Start with rates of improvement and relate that to dollars and cents.

Though each team will have different velocities, run a different number of iterations, and have different overall results, the rate of improvement on an agile team follows the same general pattern: a marked period of improvement followed by a plateau.

Teams with engaged, empowered, full-time ScrumMasters, however, follow a different pattern. These teams reach the same plateau as other agile teams but then continue to improve, clearing blocking issues and obtaining training in many engineering practices. These teams perform at high levels, finding their sweet spot and hovering at a sustainable pace. Their trend lines flatten eventually, but at a much higher level than the team without a full-time ScrumMaster.

Improved velocity is great. But to help bring the point home to your manager, we need to put it in terms of cost per story point. To get started, determine the cost of the team per hour. (A simple way to do that is to add together the loaded employee cost for each team member. The loaded cost is the salary plus benefits and time off.) If a team can bust out 10 points per sprint and the loaded team cost is about $440 an hour (team of four people at $110 an hour loaded cost), the cost of the team, per sprint, is $35,200 ($440 times 80 hours for a two-week sprint). This assumes a dedicated team working on one project and that the time spent on non-project-related tasks is still a loaded cost on the project. The cost per story point, then, is $3520 (sprint cost/velocity).

The higher the team’s velocity, the lower the cost per story point. And having a full-time ScrumMaster who can actively work to improve team performance and remove impediments is one of the best ways I’ve seen to achieve outstanding velocities

Don’t handicap your ScrumMasters. Staffing full-time ScrumMasters gives them the ability to realize their true role of team coach and advocate. And it allows teams the opportunity to reach their full potential as well.

I discuss this in much more detail, including graphs of team performance and ways to measure cost, in my recently published book: The Scrum Field Guide, Practical Advice for Your First Year.

The Fourth Question in the Daily Scrum / Standup

Mon, 07 May 2012 22:44:00 -0500

Let’s say you are on a team that is both newly formed and new to practicing agile. Your daily standup meetings appear to be going well and you are looking forward to your team’s first demo. The big day comes, you get in front of the customer, and then the floor drops out. Your app starts acting in a way that is definitely not as intended—all because of a hidden blocking issue.

As the team dusts itself off and gets ready to start the second sprint, you wonder to yourself, “How can we ensure that the team drives out those blocking issues in the daily standup?”

Add in the fourth question.

In the daily standup meeting, start with the three questions as you normally would:

What did I do yesterday?
What will I do today?
What blocking issues do I have?

Then add the following:

What is your confidence, on a scale of one to ten, that the team will accomplish the goal of this sprint?

I recommend using the fourth question at the beginning of any new project. Even if people know each other, they may not have built the trust required to have the open and honest conversations that ensure project success. I've made it a required element for any team that is new to each other, to Scrum, or to both. Even if you’re an established Scrum team, if you are going through your daily standup meeting without uncovering many impediments, yet during the sprint or the review, issues “keep cropping up,” you need to add the fourth question of Scrum.

The fourth question is powerful on its own, but it’s even more effective when the ScrumMaster is also on the lookout for the following:

Nonverbal communication—Look for small signs that a team member might be unsure or uncomfortable. If you see a behavior that seems out of place, ask about it. And stick around long enough to hear the answer.
People who are not comfortable with conflict—A ScrumMaster doesn’t have to be a psychologist, but the best ScrumMasters have probably done some research on how humans work and interact. Different personalities and cultures often respond to conflict in dissimilar ways. Get to know the people you are working with, ask those who have worked with them in the past about their natural tendencies, and spend some time chatting with them informally. Establishing trust goes a long way toward increasing communication.

As your project progresses and the team bond and trust grow stronger, you might find that the fourth question is no longer needed. Most teams I work with use it for the first two to five months. The team will know when the question is no longer needed, so the team should decide if and when it should be dropped.

To read more about why adding the fourth question works, see The Scrum Field Guide, Practical Advice for Your First Year.

The Job and Daily Life of the ScrumMaster

Mon, 30 Apr 2012 15:14:00 -0500

The job of ScrumMaster is real. It can have a big impact on costs (as illustrated in “The Case for a Full-time ScrumMaster” and The Scrum Field Guide), saving the company money - period. But what does a ScrumMaster do all day to justify a full-time role? The following list encompasses most, but not all, of the day-to-day tasks.

Remove impediments/resolve problems
Break up fights/quarrels
Act as a team mom
Report team data
Facilitate
Help out where needed
Educate the organization
Drive organizational change
Removing Impediments/Resolve Problems

Removing impediments and dealing with problems is always at the top of the list because, especially early in a project, there are many issues to deal with, both external and internal. Impediments or problems found by teams in large companies could be that another team does not respond in a timely fashion, your team needs to understand how an interface works and the people who wrote it are not available, or you have someone out sick for a few days. You also have to interface with management, doing everything from convincing them that an agile process is worthwhile, to reminding them of the fact that your job is full time, to paving the way for bonuses based on team, rather than individual, performance. Finally, you work to help the team solve its own problems and remove its own impediments. A good ScrumMaster should strive to work himself out of a job by creating a high-performing team. For some, this may be impossible to achieve, but it should always be the goal, as it shows a mature team that is truly self managing.

Breaking Up Fights/Acting as Team Mom

People are human. Sometimes we get in weird moods, don’t get enough coffee, have a bad night’s sleep, or just see something that sets us off in a bad way. Recently, my youngest daughter, Emma, could not decide what shirt to wear and thought everything she picked out looked terrible - she lost it. My wife and I had to bring her back to reality.

I’ve had perfectly rational team members who come to work one day and lose it over a challenge to their ideas. Talking them off the ledge takes patience and people skills. Good ScrumMasters need to have the soft skills to intervene when necessary and the emotional intelligence to know when it’s better to stay out of it altogether.

Reporting Team Performance

The ScrumMaster needs to help the team improve. One of the ways this is done is through reporting. A good ScrumMaster tracks the team’s historic velocities, burndown rates, and many other project-related metrics. This is done not only to assist the ScrumMaster’s own team in improving its estimation and smoothing the rate at which stories are completed during a sprint, but also to help other teams (especially new ones) in the organization as well.

The important thing to remember is that reporting team data, either internally to the team or externally to management, does not mean you are collecting data to hold against the team. Instead, you are providing visibility into data that the team needs to see and understand to improve.

Facilitate and Help Out Where Needed

The job of the ScrumMaster is to make it easier for the team to achieve its sprint goal. Many ScrumMasters wrongly assume that the best way to facilitate is to just do the work, which is not the case. Facilitation is not solving other people’s problems or doing it for them; it’s making things run more smoothly. The goal of facilitation should be to help the team analyze and get a better understanding of the system and the problems at hand.

The job of the ScrumMaster is not to provide answers or to do everything for the team, but rather it is to help people get to the answers that they may already know. Now there may come a time when you need to help out to complete a task. Helping out is OK on occasion as long as you don’t forget that it can hinder you in your role as ScrumMaster because it can cause you to focus too much on the work and not enough on the larger impediments that may be negatively impacting the team. When you do help out (and I know you will), remember that doing so must be the exception rather than the rule.

Educate the Organization and Drive Organizational Change

“If you want to make enemies, try to change something.” That quote, commonly attributed to former United States President Woodrow Wilson, definitely applies to these two ScrumMaster tasks. It’s tough to convince people to try something new because change is frightening. I find that when introducing new concepts, policies, or methodologies inside an organization, people’s first response is to wonder how it will affect them. Will their jobs be safe? Will they be able to provide for their families? Others openly rebel, refusing to consider the new way because the status quo, as bad as it might be, is better than the unknown.
A good ScrumMaster finds a way to introduce new ideas and initiate change without shocking people’s systems.

For more on the role of ScrumMaster as well as ways to convince management to make it a full-time job in your organization, check out The Scrum Field Guide.

Using Team Consultants to Optimize Your Organization

Mon, 23 Apr 2012 12:12:00 -0500

Data tells us that the best team sizes are between five and nine people, all of whom are fully dedicated to a project for the duration of the project, and who work together in a cross-functional way to deliver working software at the end of every sprint. What many companies find, however, is that there aren’t enough good people to go around. Creating one or two teams? Sure. Creating a whole company of fully cross-functional, dedicated teams? Much more difficult.

Some people have great skills but don’t necessarily make good team members. Others are in such high demand that it’s hard to hold them on one team for the length of the project. In light of these realities, how can you structure a team that is dedicated to the project, contains all the skills you need to get the job done, and provides opportunities for personal growth?

I’ve had success with a concept I call team consultants.

What Is a Team Consultant?

A team consultant is someone in your organization who is available for some amount of work and directly fills a skill gap between the team and the project. Rather than being dedicated to one Scrum team, team consultants choose to offer up their services as internal “guns for hire,” providing specific expertise as needed. As such, team consultants often work for multiple teams and are typically very specialized. That doesn’t mean the team consultants hoard their knowledge, though. As part of a learning organization, team consultants help others by teaching, giving advice, coaching—whatever the team needs during a sprint. And the team consultants grow, too, learning how to work as part of a cross-functional team and how to share their expertise with others.

The project will need a core team of well-rounded individuals who can do the bulk of the work on the project. That team of four-to-six people will be dedicated full-time to the project. Collectively, they are responsible for delivery of the work. They are a cross-functional team who work on only one project, eliminating context switching and multitasking.

Together they will meet to determine what strengths and skills they collectively bring to the project. They will then talk about what competencies that they project requires but which they might be lacking.

Core Member or Team Consultant?

So how do you decide whether someone should be a core team member or a team consultant? The person in the best position to determine this is the person doing the work. Communicate the differences in the two roles, perhaps even posting a table like the table below that lists the benefits and downsides of each role.

Team consultants work on multiple projects and will need to manage their time accordingly. Team consultants often choose this role because they are passionately dedicated to their crafts. These people have been working in their subject matter for so long that they are the “go-to” people for certain types of work.

Signing up to be a team consultant, however, does not mean that someone gets to practice a craft without helping others. On the contrary, whenever possible, team consultants should work to bring up the skills of the entire organization.

The people that make up the core team, on the other hand, are skilled in multiple areas. They are not expected to be experts; in fact the team is designed to provide cross-functional balance of expertise. Like a team consultant, a core team member is responsible for his or her own time, but all this time is dedicated to one team and one project.

Ground Rules

Once you’ve built a team of core members and consultants, you need to establish guidelines to encourage teamwork. The specific guidelines vary from organization to organization but should include the following:

During the course of the sprint, the team and team consultants are jointly and equally responsible for delivering on their commitments.
Team consultants should show up on time, be part of daily meetings whenever possible, and conduct themselves as team members for the length of the sprint.
Team consultants are experts in one area but otherwise no different than a core team member. There is no hierarchy among core team members and consultants.
If anyone or anything is blocking a task, the task should be brought up at the daily standup and addressed immediately.

Remember, too, that you cannot have a core team made solely of consultants. The majority of the team should be dedicated to the project from beginning to end.

Some might look at this model and think that it circumvents Scrum’s call for dedicated, cross-functional teams. It does not. What it does do is provide teams and companies the flexibility to stay within the boundaries of Scrum by having a dedicated, cross-functional team while enabling that team to call on experts, team consultants, to help out as identified and needed by the team. It is not the job of a resource manager or an executive to randomly assign people to the team; that will not work. It is the job of the team members to determine and manage their schedules. If you start to see “teams” of consultants, ones in which there are only one or two core team members, the dedicated, cross-functional team has been lost. Remind the business of the importance of an actual core team supplemented by consultants and reboot.

Having a dedicated team with all the skills necessary to get the project completed is ideal. But most teams will, at some point in the project, find themselves wishing for a particular expertise. If you have internal people who can fill this gap on a temporary basis, bring them in to the project. If your organization does not have team consultants who can fill the gaps, you may want to bring in external consultants for limited engagements. A team consultant can sometimes score a lot of points for a project that might otherwise struggle with a skill gap.

For more information on how to use this model in detail, including setting up your organization, please read Chapter 3 in The Scrum Field Guide: Practical Advice for Your First Year

Determining Sprint Length

Sat, 14 Apr 2012 13:13:00 -0500

There is no one-size-fits-all, magic bullet for determining a sprint length that works well for every team. Originally, Scrum called for one-month sprints, but nowadays many teams have been successful with two-week or even one-week sprints.

Choosing the right sprint length is about determining an appropriate stimulus-to-response cycle. In a sprint, the initial stimulus is the customer setting the priority of the stories. The response is the team building working software. The building of the working software is in turn a stimulus to the customer. The customer’s response is feedback. The more instantaneous that feedback, the higher the likelihood that what is delivered in the end is what the customers really wanted, which is not necessarily what the customer originally asked for. This stimulus-response cycle continues until the project ends.

Key Factors To Consider

When trying to determine the appropriate stimulus-to-response time for your project, consider following criteria:

The expected duration of the project
Customers/stakeholders

How often can they provide feedback and guidance
Scrum familiarity
The cultural barriers existing in the company or with the stakeholder/customer group
Environmental factors

The Scrum team

Scrum experience
Technical capabilities (such as automated acceptance testing, TDD, automated releases, etc.)
Ability to decompose work

These elements play a critical part when any team is trying to determine whether its sprints should be one, two, three, or four weeks. Let’s look at each element in more detail.

Project Duration

Sprint lengths should be chosen in relation to project duration; however, they should never be longer than four weeks. Consider a three-month project. If it has four-week sprints, the stakeholders will only get to participate in two demos before the project is released. This is not enough feedback to mitigate the risks. Shorter sprint lengths are a necessity.

What about a year-long project? Assuming four-week sprints break approximately monthly, that project would offer 11 opportunities (plus the final release) for stakeholders to see the developing product. Four-week sprints are a realistic option, depending on the other factors involved.

Customer/Stakeholder Group

When working to determine sprint length with your customer, it is important to factor in three things.

Customer group
Company culture
Customer environment

Look at the customer group first. It’s crucial to balance the team’s needs with the needs of your customer. Having a one-week sprint might solve some team problems but could put too much stress on the team’s relationship with the customer.

Next, examine the customer’s company culture. Is working with a Scrum team new to the company and its culture? Is it perhaps being tested in a pilot group? If so, consider that short sprints may give a false impression that Scrum teams put undue pressure on the customer.

The environment in which the customer conducts business can also affect the project. Environmental factors (such as regulatory issues) are often overlooked but, from my experience, often affect what the team can deliver and when. If your team has a large number of regulatory issues to contend with, you will probably want to choose sprint lengths of at least two weeks (three or four may be ideal), because of the amount of compliance assessment and auditing that will need to occur before any software can truly be considered shippable.

Scrum Team

The Scrum team itself is a factor in determining sprint length. Considerations include the following:

Team experience with Scrum
Team engineering capabilities (e. g., test driven development, continuous integration, pair programming, etc.)
Team ability to decompose work

As a rule, an inexperienced Scrum team should stick with two-or four-week sprints as a one-week sprint is much more advanced and better suited for established teams that have a good working relationship, excellent engineering practices, and be adept and confident in decomposing work (or want to get better through a trial-by-fire).

Determining sprint length does not need to be a daunting task, but it does require thoughtful consideration. The right sprint length balances our craving for customer feedback and input with our ability to deliver and our customer’s ability to respond.

For more information on how to determine the length of your sprint, please read Chapter 6 in The Scrum Field Guide: Practical Advice for Your First Year

Release Planning in Agile (Scrum and XP) Projects

Fri, 06 Apr 2012 15:50:00 -0500

An agile release plan only has to include the best- and worst-case final release dates, but many plans also include smaller releases along the way, including end-of-sprint releases and quarterly releases. I have even scheduled daily releases when working on a sustained engineering team supporting a production system. What makes sense for your release plan depends on the specifics of your project and the reality of your situation.

I approach release planning in a very systematic way.

1. Sketch a preliminary roadmap.
2. Add a degree of confidence.
3. Include dates and adjust as needed.
4. Update the plan every sprint.

To build an agile release plan, you need three inputs:

1. An estimated, ordered, and prioritized product backlog
2. The team velocity
3. A sprint timeline

Don’t attempt a release plan until the team and the product owner have estimated, ordered, and prioritized the initial product backlog.

Once you have a prioritized and estimated product backlog, you need to know your team velocity, how much work a team can do over time. This number can either be pulled from historical data or estimated. (See Chapter 4, “Determining Team Velocity,” in The Scrum Field Guide on how to do this).

The last thing you need to know is your sprint timeline, the intervals at which your sprints start and end. This could be one week, two weeks, three weeks, or four weeks. Regardless of the interval, once you determine your sprint length (see Chapter 6, “Determining Sprint Length,” in The Scrum Field Guide on how to do this).

With this data in hand you can sketch a best-case and worst-case scenario for how much of the product backlog the team can accomplish within a certain number of sprints.

Remember, release planning does not go away in agile projects, it is just done differently. And "agile means no planning" goes out the window.

For more on how to do effective release planning, order your copy of The Scrum Field Guide: Practical Advice for Your First Year today!

Win a Copy of The Scrum Field Guide

Sun, 01 Apr 2012 22:39:00 -0500

The Scrum Field Guide: Practical Advice for Your First Year is now shipping (link to Amazon)! Throughout the month of April I will be giving away a signed copy of the book to four readers of this blog.

Winning is easy. Just enter a comment on this post with a piece of advice you would give someone who was just starting out with Scrum and XP. It can be small, like "stay disciplined!" or lengthy, it's your call. I will pick two winners who have the advice I like best and I will pick two (well, my kids will) people at random. You've got four chances to win.

I will pick one random winner and one advice winner on April 15, and then again on April 30, with all comments being posted by 23:59 on each day, respectively.

I will also be kicking off my 10 blog posts in 10 weeks initiative each with ideas and concepts from The Scrum Field Guide, starting today (no, this does not count as one).

Good luck!

(PS: thanks to Mike Cohn for ideas on this book promotion)

Free Chapters from The Scrum Field Guide

Tue, 20 Mar 2012 18:43:00 -0500

Addison Wesley informed me that they’ve made a chapters available from my upcoming book, The Scrum Field Guide: Practical Advice for Your First Year. It includes the forwards by Jeff Sutherland and Jim Highsmith as well as Chapter 27, Documentation in Scrum Projects

You can get the free chapters from the InformIT website. Find the picture of the book on the bottom right and download the chapters from there.

You can also check out the book on Amazon here.

Enjoy!

When the Team Becomes the Product Owner

Sun, 05 Feb 2012 07:19:00 -0600

Jim was working as the business manager inside the company. He had years of experience and was a few years from retiring. Jim was working on a project with Michelle and he had been voluntold (told he would volunteer) that he was the teams product owner due to his rich expertise, background and knowledge on the business end of what the project was to deliver. We find Jim having a conversation with Michelle, where she is showing some frustration with Jim’s lack of involvement with the project.

“We’re doing Scrum” said Michelle, “and you’re the product owner!”

Product owner thought Jim? He had heard the term around the water cooler, and he had been skating by doing the job in a half-assed fashion, but now his real job was beginning to back up. It was time to do some homework.

After some digging, Jim discovered that the product owner role was a Scrum role whose primary goal is to ensure the vision that was asked for by the stakeholders/customers is being executed by the team and that he was now responsible for managing and representing the interests of the stakeholders and customers to his development team, who executed the work. He found that the product owner was responsible for working with the stakeholders to understand the functionality of the system under development as well as writing user stories and working jointly with customers.

“Great” he thought to himself, “more work.”

He kept reading and discovered the stories go into the something called a product backlog, an ordered and prioritized list sorted by business value and risk of the work needed to accomplish the project. It contained user stories and other things like bugs and various issues.

“Even more work” he said out loud. He began to wonder how to push this off onto the team. He went back to Michelle to share his concerns.

“Michelle, I’ve been thinking about this product owner role. I didn’t commit to the responsibilities of this role. My manager said I would do it because of my background. I don’t mind helping you out but I just cannot take this on at this time. I need you and the rest of the team to do this type of work. I’m far too busy. You know what we need to do this year so just make it happen and if you need anything critical, pull me in, but I need the team to drive this” said Jim.

Michelle was shocked.

“Jim, I don’t think you understand. You are best suited for this job. You have the experience, the background, relationship with the stakeholders, and you know how this thing should work. We need what’s in your head. You’ve been working on this for quite a long time. I’m worried that if we just come to you for critical items, we’ll end up building the wrong thing. Can we really afford this?”

“I don’t have time, do your best” said Jim.

The Problem

You might think this is isolated and uncommon, but unfortunately in today’s overloaded and understaffed businesses with multiple simultaneous projects, its reality. People are often “too busy” and can’t do their jobs because the business lacks the necessary slack in the system to allow for flexibility and change.

In the story, we have Jim who is essentially handing off his product owner responsibilities to the team (never mind the fact that he was not committed in the first place). We have the team who doesn’t have the insight into the business or the vision and has been tasked with moving the project forward. This is a recipe for disaster.

Jim, as the product owner, is responsible for managing the vision, keeping it on track in the form of user stories and keeping those user stories prioritized and ordered through frequent interaction with customers and stakeholders. Jim, as the business manager, has the industry and business background, and owns the relationships with the customers and stakeholders. By handing off this responsibility to the team, he is essentially signing both of their death certificates.

The team, working to please its product owner through frequent releases, working software and collaboration, has now lost its primary source of knowledge. Jim’s responsibility is to provide the team guidance and to answer questions when ambiguity arises around user stories, and that is now gone.

A Solution

I say “a solution” and not the solution because there is no single, all-encompassing solution to this problem. I see this problem more than you might expect and here is the advice I give to my clients.

Help the product owner/business manager understand their role. The product owner is a full time job, especially with projects that have a lot of change. The longer the project, the more likelihood for change. To read more about the product owner, click here
Discuss the impact of this decision. The decision to have the team become the product owner will end in failure. The impacts of this decision are

The team will build the wrong thing. Why? Because they don’t have the background or knowledge of the vision the way the product owner does. The teams focus is a shorter term technical focus, where the product owner holds the long term vision through active product backlog management and customer interaction.
The product backlog will become stale. When there is too much pressure in a system, something will give. The first thing I see give is the product backlog. The team will not keep it up to date, nor will they have the frequent interaction with customers and stakeholders like a product owner would (this is called grooming). This is because of the focus of the team – executing the project – not managing its scope and area of focus.
Money will be wasted. If you believe that these impacts don’t come with a cost, you are wrong. Time will be wasted, as well as money, and opportunity cost will be lost while the product owner is too busy. Meantime, team is struggling to build the product or service and trying to manage the stakeholders and product backlog (the job of the product owner), doing both poorly.

Track data. I’m a data guy. While my friends tell me I make impulsive “hunch” type decisions, I do so with at least 51% of the available data. If you believe that having the product owner push off his responsibility to the team is the wrong thing to do, like we saw in the story, complaining about it is not going to help. You need data. The things I capture are…

Velocity. You will see a significant drop in the teams’ velocity. This will directly result in a slippage of stories. Publish this data, and once you have three to six sprints worth of data, go back to the all-too-busy product owner and say “here is our new release schedule,” which should be much farther out than it was before due to the increased overhead in the team in doing both roles (team and product owner).
Customer satisfaction. This is a little harder. In your review meetings, ask the customers if they are satisfied with team performance and their delivery. Show them the velocity numbers and the projected release plan. If they are happy, the team is in great shape. Most likely, however, they’ll be a bit worried and/or upset with the performance of the team due to its increased overhead and the longer release schedule.

Business priorities. To me this is a no brainer, but for some it’s a huge challenge. I have clients that often have 20 or more “critical” projects that they need to deliver in a year and each project has equal priority. This is one of the main reasons people become too busy as the business cannot provide direction as to what is important and not important as they relate to company short and long term objectives. As a result, everyone tries to work on everything and practically nothing gets done.

That’s it. I hope you found this article of value. if you liked this post, check out my book, which is full of good tips like this.

Additionally, there are several resources you may find of value to help you identify/prevent this from happening.

Book: Slack by Tom DeMarco – read it and give it to everyone
14 day sprint timelines – print them out
Intro to Scrum section on this website, specifically

Even 3rd Graders are Project Managers

Sat, 21 Jan 2012 13:52:00 -0600

I was chatting with Mike Cohn Agile 2005 about user stories. He told me how he applies some of these techniques to his kids. This got me thinking - what is important to me, as a parent, when it comes to my kids homework.

I want to know what assignments are active, pending and complete
I want to know the measured quality of the work turned in and the time spent on each assignment.
I want my daughter to have a sense of ownership when it comes to her deliverables

I did not want to invent a new proprietary system in solving these. I thought to myself, if user stories work for the team at work, why not at home?

Required Tools

A cork board, hung in a public place where your child frequently visits (in front of the TV might just work for some)
Multi-colored 3x5 cards
Pencils
Thumb tacks or push pins

The Exercise

Every Monday (in our case, our daughter only gets homework on Mondays, so this is any day your child gets a new assignment) we have Ashley write down each of her homework assignments on a single note card. Different subjects get different colors, like red for math - easy enough.

Each card gets the following attributes

Assignment name
Estimated time to complete
Date due

Once complete with the assignment, she will add the following information

Actual time to complete
Actual date turned in
Grade (once provided by the instructor)

She is free to add additional items on the card, like where she found the information, how she liked the assignment, and so on. On the board, create three areas - "Queued (or pending), Active, Completed". This allows you (and her) to see what the backlog of work is, how much work your child has bitten off at any given time and how much work has been completed over time.

Sounds a bit crazy, I know. We want her to learn to be accountable her herself and to her work. We want her to see that the effort she puts in may not give her the grade she desires (quality and reward) and that next time she should work harder. This helps her realize that when she puts in 30 minutes to some work, does a crap job at it and then gets a poor grade, she is the only one she can cry to. We coach her along the way, but ultimately we leave what "done" means to her. Granted, we can coach a littler harder from time to time when she's off in la-la land.

You get the point. Try it out with your kids and let me know how it goes.

The Experiment

Wed, 13 Apr 2011 21:59:00 -0500

I wrestled with this on the train from Arlanda all the way to Stockholm Central. Got to the hotel, unpacked my stuff for the two nights I would be there and said “screw it, I’m taking a nap” – well this was at 1:30pm local time and I got up at 3:30pm. I spent the rest of the day wandering around the city, watched an England Euro cup qualifier and went off to bed at 5:30am the next day.

Feeling overly refreshed, I got up around 3pm and met my friend Robert (MS guy) and we went for what I would consider breakfast – he considered it a late lunch. It was 3:30 in the afternoon and I had been up for about 30 to 45 minutes. We went to a fantastic restaurant called Grill Ruby where I was able to get eggs – and a beer! It was my breakfast beer. Well, turns out having a beer when you get up from a night’s sleep is not the best thing. We wandered around a bit and I took a nap at 9pm for an hour. I got back up, went back to the same restaurant for a late lunch and then worked out in the gym.

This cycle went on for the entire five nights I was there. The hardest thing I found was to make sure I was sound asleep by the time the sun came up and next was to find food. On any given day, I would wake up between 2:30pm and 3:45pm – and I would go to bed around 5am to 7:30am. Most restaurants closed at 11pm or earlier, which was just about lunch time for me. To have dinner would mean I would need to stay up until about 6am to get breakfast in the hotel. Well, this does not work out that well with the sleeping before the sun comes up rule, so I’d often skip dinner.

This really was a fun experiment, one which I will do again. Wandering the streets at 4am in a city is totally different than doing it during the day. If you can manage your food intake, meaning it when food is available, you’ll do fine. Give it a shot, let me know how it goes!

TechEd Europe 2010 Recordings and Downloads

Sun, 06 Feb 2011 20:30:00 -0600

You can grab all sessions here:

http://www.msteched.com/Speakers/Mitch-Lacey

Here are links to my specific talks with slides and audio. Enjoy!!

http://www.msteched.com/2010/Europe/ARC208 - Architecture in Agile Projects – How to do it right

Architecture: Big design up front, or cowboy ‘design-it-as-you-go’ coding? In agile projects we hear that BDUF is evil. Does that mean that agile requires no architecture? Is there no more need for architects in agile projects? Neither could be farther from the truth. In this talk, Mitch Lacey, former Microsoft Program Manager, will walk you through a case study of one of his projects to show you how they architected a system that required 99.999% uptime and supported 5 million users – all while using Scrum and XP.

http://www.msteched.com/2010/Europe/ARC207 - Working Software is Not Enough!

The true measure of project progress is working software - or is it? Our team thought it was, and we were wrong. This is the story of our team, a team that set out to build a new order tracking system for a worldwide vehicle manufacturer and failed. So, what are the factors necessary for a successful project? In this session you will get insights into our team’s key-learnings on critical success factors - insights you can definitely use to ensure your project’s success.

http://www.msteched.com/2010/Europe/ARC206 - Scrum for Managers

The role of the manager in a software company is changing. No longer is it about driving people to achieve results. Now it is about enabling teams to be hyper-productive. But how can this be accomplished? Scrum, an agile framework, has been used successfully to build hyper-productive teams. What is Scrum? How can a manager build hyper-productive teams that outpace everyone else? In this talk you will hear exactly what Scrum is, its base components, and the traits required to help ensure success. Mitch Lacey, former Microsoft program manager will share his experiences helping teams adopt the Scrum framework. In the course of his work he identified four patterns that were present in teams that succeeded, but were absent in teams that failed.

Scrum: Adding the Fourth Question to the Daily Standup

Sun, 05 Dec 2010 06:03:00 -0600

On one project team, when we would do our standup, team members would answer the three questions with energy.

"Yesterday I finished the IAS web service and today I will begin adding the key tables to the new DB, no blocking issues"

We all knew what this meant, after all, we were all sitting right next to each other in the team room.

Near the end of the Sprint, however, things changed. People would still answer the three questions with the same accuracy and gusto that they had been all Sprint long, but they would grumble that we were not on track to meet our Sprint goal. I asked myself, how could this be?

What I noticed was that people were still uncomfortable with raising issues. We were a new team and none of us had worked together before.

I pulled out an old trick, a thermometer test. I first experimented with this in early 2005 and it's a tool I have been using ever since. Simply put, I introduced a new question into the Daily Scrum, which was....

"On a scale of 1 - 10, how confident are you that we will accomplish the goal of this Sprint?"

Now the issues started to surface. While people were not comfortable stating blocking issues caused by other team members, they were comfortable in saying "six" instead.

How to use this on your team

Add the fourth question. Let the team know what it means and what it is for. Then listen. If you, the ScrumMaster, notice a variance in the numbers, discuss it. It's that simple.

Here is an example:

Joe: 9
Mike: 8
Bill: 8
Michelle: 9
Sarah: 5

Whoa! a FIVE??? time to start probing.

Be Cautious

Be cautious - people may want to discuss their numbers in private. Encourage team participation. Let the strong personalities on the team know that they will need to scale back the "strong-ness" and let people talk. This is not a time for attacking, it is a time for building trust and comfort in the team.

How Long?

I see teams use this technique early on and, once trust and communication is established, it dies down.

Stage Producer 101: Building the Best Stage Possible

Thu, 01 Apr 2010 02:03:00 -0500

So you want to be a stage producer for the Agile conference? Great! This post is meant to give you a primer not only on how to get started but also on how to build a wonderful experience for the attendees.

You should skip this job if…

You are doing it for the money. (As I explained in my first blog post, stage producers get at most $1,000 plus hotel and free conference admission.)
You don't have a lot of time. (I find I spend about 100 hours just to get to the point where I send the accept/reject letters. At that point I have another 60 - 100 hours to go.)
You are using it as a way to build your business. My advice, build your business on your own time.

Why do the job?

Because you enjoy the challenge. Running a stage is like running a project. You have to build a team of people you like to work with, and others that can work together. You have to motivate people through leadership and communicate with them frequently.
Because you get to meet other people in the community that you might not otherwise meet.
Because, most importantly, you get the opportunity to give something back to the community.

Stage producers have to meet certain date milestones and have a firm grasp on what will happen when.

August - November: Build your team.
November - March: Review and communicate to the team
March - April: Acceptance and reject emails go out
April - August: You will need to do small things to get your stage ready
August: As the conference nears, things ramp up again

Build Your Team

Setting up your team is a lot harder than you think. I start out by sending an email to 10-15 people that I think might be interested. I ask people that I have worked with in the past and new acquaintances that I think might enjoy being a part of the review team. In 2009 I asked people to review at least 20 sessions each. Doing it this way did not work because we received more submissions than we anticipated. In response, this year I gave people a percentage of submissions for which they would be responsible.

Reviews - Giving Them

Reviews are fun and quite challenging at the same time. When doing reviews, or having your team do reviews. Follow these guidelines:

Make sure there is a vision, a well structured outline, and clear learning objectives.
Give yourself ample time and do them without distractions. I like working in 45-minute blocks.
Provide actionable feedback.

Your review does not need to be a novel, but it should also not be one sentence (unless the submitter really nailed the submission and you're going to accept it).

Here are some examples of feedback that I used for Agile 2010:

"As other reviewers have said, there are a lot of things thrown about freely. On the surface this seems very good. In order to get accepted, however, it needs the sources to back up the claims."

"This feels like it has everything, which I view as a detriment. While attempting to cover a broad range, it feels like it lacks focus. Hone in on a specific set of items and drill them home."

Here is a piece of feedback I gave to a submitter (one of many) who submitted late and did not have a well-built submission.

"This submission lacks the detail necessary for serious consideration. If you are to run a 90-minute tutorial, you need to outline the timings in detail and expand on the exercises you will use. I have read the comments and feel that if you had submitted this before the deadline was approaching, it would have had at least one round of reviews and feedback with the review team, allowing you to adjust the submission. In its current form, I cannot advocate it for the conference this year."

I will always give a review over a comment as it allows me to get a picture of the program as it's being reviewed. I instruct team members to provide comments in the review and put in a recommendation (accept, maybe, reject) and use this data to manage the stage.

Reviews - Managing Them

The submission system, as built today, is not a very good tool for managing reviews. As a result, I use google docs to keep track of how the reviewers have rated individual submissions. I import the submission titles, ID numbers, and reviews and list them out like this:

The count is the number of team members that have reviewed the submission. Each reviewer gives each submission a numerical value of 2 for accept, 1 for maybe, and 0 for reject. These individual ratings are then averaged out. As you saw in the email, I like to have all reviewers review at least 75% of all submissions. This is to ensure that I get at least four, ideally five, reviews per submission. The conference committee only requires three; but I like to have more eyes look at the submissions.

Once the submission system closes, we go back one last time, review all of the stragglers and any updated comments from the review that we missed and solidify the plan. For our stage this year, this was done about five days after the submission system closed. A week later, we had a team conference call to discuss any submissions on the edge of accept/reject. We had about eight to discuss; two were promoted to accept. At this point the review team’s job is done.

Post Acceptance

As of today, 31 March 2010, we are in the accept/reject phase. Acceptance emails went out on the 30th of March and reject letters will go in a week or two. Why the delay? Because not all the people who were accepted will be able to go. We give people 7 to 10 days to confirm. If they don't, we move onto our backups. Once we’ve heard back from all of the submitters, the reject letters go out.

The Conference

Jim Newkirk, conference chair for Agile 2010, instituted some new rules that I think are wonderful. First, stage producers and assistants must open each session on their respective stages, introducing the talk and the speaker. They are not required to stay for the session, but they must collect the feedback at the end of each session and build a report in real time on how the stage is doing based on the scores for the sessions that were accepted. This report is given to the conference coordinator, Jessica, to build into a larger report. The chair will then write a larger conference report to submit to the board at the end. All of this is kicked off by the conference retrospective on Sunday, which all producers are required to attend.

In Closing

All in all, I find working on the conference very rewarding. Because I have done this for many years, I have worked out most of the process bugs for my stage. Every producers approach is a bit different, but in the end, we are all working towards a single goal - build the best conference program and experience we can.

Your takeaway : I encourage you to be a stage producer, but only if you are doing it for the right reasons and you have a firm grasp on the commitment you are making. Though the process isn’t perfect, every producer and every review team is working hard to create the best possible conference. If you have any suggestions on how we could do better, please send them to me. I’ll pass them along at our August retrospective.

Agile Conference Stage Reviews: How it Works

Thu, 01 Apr 2010 02:02:00 -0500

If everyone did his or her part, the stage review process would work very well.

How it Should Work

Submitter gets submission in early
Review team provides feedback inside the conference review system
Submitter gets notified and updates submission
Review team gives it a final pass just after the submission system closes
Stage producer builds program
Accept or reject letter goes out

Unfortunately, in the four years I've been doing this, I’ve found that things don’t always go that smoothly. It starts with a flood of late submissions, many incomplete, and ends with overwhelmed reviewers who cannot respond within the review system.

How it Really Works

Submitter gets submission in just under the deadline
An overwhelmed review team reviews the submission, inside or outside the review system
Submitter gets notified and may update the submission
Stage producer builds program
Accept or reject letter goes out.

This year was no exception. The vicious cycle began when most of the submissions came in all at once. This in turn caused many review teams to push through a lot of submissions very quickly (this is why your first impression is so important—see blog post 2). The rapid turnaround time and volume, then caused some stage producers to bypass the review system to do the reviews.

Why is it that such a bad thing? Simple – it breaks the feedback loop. How is a person to know how his submission is doing without comments or reviews? As I write this, acceptance letters are going out. At the same time, there are submissions remaining in the system that have no comments or reviews. Transparency and a feedback loop are essential ingredients in a fair submission review, yet we have submissions with zero feedback. It’s bad for the submitters, it’s bad for the reviewers, it’s bad for the producers, and it’s bad for the conference. People do the best they can, but when the process breakdown, the system fails.

Your takeaway. You can help make things work the way they should.

Submit your talk early
Email your stage producer
- Ask them directly if they are using the submission review system
- If they are not, ask them how they will be giving you feedback and what the update mechanism will be

I’ve given you a good idea of the reality of the submission process and what you can do to give your presentation the best chance of getting accepted. My next blog post will show you the other side of things: how to be a great stage producer.

Getting your Session Accepted to the Agile Alliance Agile Conference

Thu, 01 Apr 2010 01:57:00 -0500

The following three factors are crucial to a successful submission for the Agile Alliance Agile Conference:

Structuring your Submission
First Impressions are Critical
Timing is Everything

Structuring your Submission

Too often I see submissions that lack the basic elements of what the author is trying to communicate. This has everything to do with timing (see below). Your submission should follow the following guidelines:

Have a good title. Yes, we can rework the title later but, remember, this is your first opportunity to make a good impression. If it grabs the reviewer, it'll grab the attendees.
Have a well thought out introductory paragraph that tells attendees why they should come to your session over others. Consider having a short call to action in this section and a problem statement.
The process and mechanics should tell the review team, as well as the attendees, how you plan on spending your time. Can it change? Sure it can. Should it at least be complete? You bet. This section should include the timings of your session and how you will use the time. Don’t skimp on this part; it should be the meat of what it is you want to do. Additional items to include in this section are
1. Audience. Understanding who your primary audience is, and communicating it, is key to a good submission. People need to understand why they should come to your session and why it adds value. Sure, you are listing if it is introductory or expert as a checkbox, but I look for additional details here, like, "this session is targeted at senior managers inside the company who want to introduce XP and Scrum but are not sure how to get started."
2. Presentation Format. Yes, there is a dropdown that allows you to check tutorial, talk, workshop, etc, but you should still consider weaving a description of your format into this section of the submission. For example, a piece of text from a tutorial session that was accepted says "I’ll start with an introduction and purpose of the game, then explain the rules and show an example of how to play. They’ll have one hour to complete the game." This tells me a lot and I can see how the game will roughly play out.
3. Presentation Delivered Before. This is one of the things I consider a best practice. I think it's pretty straight forward - have you done it before or is it new? If you have done it before, provide a link to a video or some piece of detail where the review team can read about it. If it's new, call it out. I like new things.
4. References to Your Speaking Ability. I know how this sounds, but remember, this is a volunteer effort. These volunteers vary from year to year, so even if you’ve submitted something before, not every reviewer will be familiar with your speaking style. Having a couple names that people can follow up on is beneficial. Having references might be the difference between one submission being accepted and another being rejected.
Learning Outcomes. Good learning outcomes list what people will take away - e.g. "Learn that effective and efficient meetings are focused strategically, tactically or daily - not all mixed up." Bad ones say things like "get an understanding of agile" or "learn new coding techniques." Reviewers and attendees cannot make a determination on so vague a description.
Your takeaway: Have a clear vision of what you want to present, lay out the benefits to attendees of coming to your session over others, highlight why your session is valuable (through data or other means) and tell us, if you have presented it before, what you have learned and what you will do to improve upon it.

First Impressions are Critical

I cannot stress enough how important it is that your submission looks well thought out and organized at first glance. If your submission exhibits any of the following characteristics, you're in a hole before any of us have even read the first word:

An overall submission that is less than 10 sentences
- A process/mechanics session is five or fewer sentences.
- An intro that is five or fewer sentences
An introductory paragraph is bland and does not relate to the conference.
Learning outcomes that are light or non existent

How can the review team understand what the structure of a 60 or 90 minute talk will be when the submission says, "I will be giving a 60 minute talk with time for questions. We will do one exercise." Compare that to a submission that illustrates, clearly, the vision, the goal, and how the session will flow. Which one do you think we will choose?

Your takeaway: You are guaranteed that the review team will look at your submission once. Make that first glance outstanding.

Timing is Everything

In real estate, it’s location, location, location. In conference submissions, it’s timing, timing, timing! The submission system for Agile 2010 was open for 52 days. Nevertheless, 80% of the submissions were added in the last 14 days. What does this mean to you? Everything!

If you submit early, you are all but guaranteed (at least on my stage) to get one actionable feedback loop with the review team. Simply put, if you get it in early in the process, we have time to review it and are very likely to give you feedback via comments. Because you submitted early, you may be able to revise your submission based on our feedback and resubmit, thereby increasing the likelihood of your talk being accepted.

On the other hand, if you wait until the last minute to submit, your submission is more likely to get lost in the noise. Due to the sheer volume of submissions we receive during the last few weeks, reviewers only have time to give each submission a quick read and form an impression as to whether it’s worth a second. If it’s too short or too vague, the reviewer will likely write "not enough information" and move on. That's it. Even if you are able resubmit or provide more information before the final deadline, first reads will get priority over revisions, so the team may not get back to yours before the system closes.

And don’t send us your submission at the last minute with placeholder text where the details should be. We will not be impressed by notes that tell us you will update your submission on a specific date via comments. In fact, when we come across such submissions late in the process, my stage team throws them out. Comments exist so that you can clarify what is already in the submission. They are not a replacement for the submission itself.

Your takeaway : Get a complete submission in early if you want to increase your chances of it being accepted.

I’ve shared with you several ways to increase your odds of getting a session accepted at the Agile Alliance Agile Conference. My next blog post gives you a behind-the-scenes look at how conference stage reviews work.

Agile Conference - A Stage Producers Story

Thu, 01 Apr 2010 01:54:00 -0500

The Agile Alliance "Agile" conference has become the preeminent event for our community each year. It boasts, on average, 1500 attendees and this year received nearly 1000 submissions. Organizing this is no small task.

This post is meant to share with attendees and submitters alike what my experience working on the conference for the last four years has been like. My next three posts will show you what it is my teams look for in submissions, how we make decisions, and more.

I have broken the posts down to these three areas:

I have been working on the conference for four years. In 2007 I was a reviewer and shepherd for the Experience Report (XR) track. In 2008, I worked as a team member for the Leadership & Teams stage that was being run by Johanna Rothman and Mike Griffiths. Along with Pollyanna Pixton, the four of us made up the team and reviewed 150+ sessions. In 2009 I picked up the Stage Manager role for the Organization and Culture stage and this year I am running the Leadership and Culture stage. I have submitted papers each year and have had some accepted and some rejected.

Despite what you may have heard, working the conference is a paid position for only a few people; most who dedicate their time to the conference are volunteers. Even those who are paid aren't making a living off the money. Stage producers in 2008 (if I recall correctly) received $10,000. For 2009, the number went down to $250 because we wanted to ensure we had more money to get good keynote speakers (among other things). In 2010, the stage producer is paid $1,000. In addition, each stage producer is given free conference admission and hotel nights. Prior to the conference we build the stage program. While at the conference, we are expected to introduce each session, with the help of our assistant producers, as well as attend the conference retrospective, write up a report on our stage and to handle the feedback and survey data. Assistant producers and reviewers are often never compensated and dedicate countless hours of their time to helping review hundreds of sessions. My team this year and last year were invaluable. It is truly a labor of love and a way to give back to a community that has given so much.

With that out of the way, it’s time to share with you what my team looks for and what a good submission looks like. My next blog post will deal with ways to increase your odds of getting a session accepted at the Agile Alliance Agile Conference.

How does Scrum Help the Individual?

Sat, 09 Jan 2010 10:34:00 -0600

In November, 2008 there was a discussion on the Scrum Development yahoo group about how Scrum benefits the individual, and why anyone would want to work on a Scrum team. Here is what was asked:

What does Scrum (or other Agile umbrella method) offer to an individual seeking improvement?
I realize that TDD helps one improve one's skillset and so do some of the other Agile practices.
But, specifically to Scrum, which practices are intended to address individual achievement/improvement?
The reason I ask is because teams have stronger and weaker members and would like to know both what the team can do to help the weaker embers and what the weaker members can do to help themselves. While till attaining/maintaining a high velocity, of course. Preferably without overtime.

This got me thinking, what are the values and benefits? It turns out it was easier to answer than I thought. I had been saying these things for years, in workshops and on teams. Here they are:

People who work on Scrum teams will have the opportunity to improve/practice/polish/learn/grow in the following areas

Technical skills (any) by working in a collaborative space, hopefully pair programming
Interpersonal skills through daily conversation and human interaction
Presentation skills by having to show working software every two to four weeks
Relationship skills by having to work with people you may or may not especially like
Leadership skills by teaching others your unique perspective on how you have solved problems in the past
Self confidence by going out of your comfort zone, stretching yourself and growing
Self awareness by understanding what actions, or inactions, your decisions have on others and the system you are building
Communication skills, both verbal and non-verbal, through daily standup meetings, pair programming, customer demo meetings, sprint planning meetings
Estimation skills by having a better understanding of the whole system through the practices of collaborative estimation and collective code ownership
Continuous improvement by having the discipline and trust in your team to allow the items above to become a reality

I use this list when I meet with new teams that are adopting Scrum. Try it out and let me know how it goes!