Mitch Lacey & Associates - Scrum and Agile Training

Make Your Remote Daily Scrums More Productive

Sat, 05 Mar 2016 05:25:00 -0600

I recently wrote about 4 secrets to a successfully daily scrum, which covered the basics for ensuring a productive daily scrum meeting. However, what do you do if your team is distributed?

Start off by considering the following diagram adapted from Alistair Cockburn.

Good daily scrums have strong communication and a “hot” or saturated richness level. Why? Because the team is together, in person, talking to each other about a shared interest—their progress toward the sprint goal.

Some companies I work with, however, don’t have the luxury of meeting in person each day. Some teams resort to emailing a written daily update, which is better than doing nothing but not by much. Others upgrade to daily scrum meetings via voice-only phone calls. I recently worked with a team who did remote meetings like this. Five minutes after the meeting, I spoke with some of the team members—all of them had forgotten what the other team members were working on and what their issues were. It’s clear to me that phone calls do not result in very productive meeting.

To run an effective daily scrum meeting that achieves more of the richness and effectiveness that is often seen in a face-to-face daily scrum, a team should institute the following measures:

Install Video Cameras
Consider Time Zones
Travel
Invest in Tools

Install Video/Web Cameras for Remote Daily Scrums

Too many times I hear that people can’t get hardware like webcams due to IT constraints, port issues, or whatever. You must. Not having them is a deal breaker. Asking remote teams to “do scrum” without investing in webcams and other key tools would be like buying a high-performance sports car but being too cheap to put in the highest grade fuel, then wondering why the car doesn’t run well.

Consider Time Zones for Remote Teams

Ideally, the daily scrum should happen at the same time, in the same place, every day. But if you have two or more teams, and one of those teams is 6 or more time zones away, there will have to be some give and take. For example, let’s say a company has outsourced work to a remote team that is 12 hours ahead of the onsite team. The onsite team is content to have the daily scrum at 9am every day, but the poor guys that are 12 hours away, well by 9pm, they’re winding down for the day. They’re tired. They’re not focused. They just want to get through the meeting and be done. To share the love, or the burden, shift the time – meaning each sprint you should alter which team has the late shift. If the remote team had it last sprint, the onsite team has it this sprint. If you are working in four-week sprints, you might need to switch more often. I know if you’re the customer, this might seem unfair. But while, yes, technically you’re paying the bill, everyone needs to share the pain of the time zone game.

Travel

The number one reason companies tell me that they have an offshore development center is to save costs. While that’s a nice thought, introducing remote teams across time zones only makes the costs go up. Poor communication, delays in decisions, and blocking issues that last for days instead of hours – it goes on and on. As I discuss in detail in Chapter 28 of The Scrum Field Guide , having a travel budget is essential for success with offshore teams. The daily scrum is no different. The best way to ensure that these meetings get off on the right foot is to gather both teams together in one location and spend time there. Let people get to know each other, hang out, better understand each other’s cultures, build trust, and become friends. Why? Simple! It helps build communication effectiveness and richness. I find people are more willing to adjust time or to hop on webcams when they are doing it for their friends, not just for some “other team”.

Invest in Tools

I often say to people do scrum “by the book and with paper.” Focusing on the basics and using lightweight, manual tools helps people to learn Scrum. But when you have remote teams, you need a software-based tool to keep the teams up to speed and in sync. The tool cannot and should not replace a daily scrum meeting; but it will allow the team to see progress during the day as things are happening at both sites.

Being part of a remote Scrum team is difficult. There is no doubt about it. Consider the ideas in my previous blog post, then factor in these four additional requirements. If you do, not only will your daily scrums be more effective, your teams and projects will be as well.

4 Secrets to a Successful Daily Scrum

Mon, 25 Jan 2016 11:08:00 -0600

One of the most essential Scrum meetings is the daily scrum, also known as the daily standup. It is intended as a quick meeting to synchronize the efforts of the team members to ensure that every team member is aware of how the team as a whole is tracking towards its sprint goal.

This post discusses 4 ways you can ensure that your daily scrums are productive.

#1: Daily Means Daily

There is a reason the daily scrum is called daily. It should happen every day—not every other day, or every third day. Every working day. Period. This daily cadence establishes a pattern, a muscle memory in Scrum teams. To be effective as a Scrum team, team members must learn to move and work as a team. To further this one-team mentality, members need to make public, daily commitments to each other, instead of working in isolation toward some distant goal.

Teams are much more likely to begin and keep the daily scrum habit if the meeting happens in the same place and at the same time every day and if the meeting always lasts 15 minutes or less.

#2: Stand. Don’t Sit.

And there is a reason teams often call the daily scrum a daily standup. Team members are expected to stand for the meeting. Why? First it keeps everyone engaged. Its difficult to check email or doodle when you’re standing. Second, it keeps meetings short. If you’re feeling the need to sit, the meeting has somehow derailed. Third, standing increases energy levels and awareness, making everyone much more focused. So stand up, every day.

#3: Stay On Point & Take Turns

At the beginning of each meeting, remind the team members that they are there to sync their work and to raise any blocking issues. Repeat the general instructions: each person should answer three questions: what have you done since yesterday, what will you do today, and what impediments do you have. Then invite someone to start the conversation and then hand the volunteer a talking object of some sort.

The talking object can be anything the team chooses: a nerf football, a magic wand, a marker. The point is that whoever is holding the talking object can talk; anyone not holding the object, cannot. If a team member interrupts the person holding the talking object, the authorized speaker can wave the talking object as a general reminder that its his or her turn to speak. When the authorized speaker is finished, he or she then passes the talking object to the next team member. This simple prop keeps the meeting moving with minimal intervention from the ScrumMaster.

All of this repetition and structure might seem excessive—but it’s the best way to develop and maintain good sharing habits among team members while keeping the meeting moving along.

#4: Park Deep Dives

Occasionally a team member will deviate from answering the questions and begin to dive deep into problem solving. It’s natural to want to explain and get input and answers from one’s fellow team members, but the daily scrum isn’t the place for indepth conversations. Think of the issues raised in daily scrum as promises for future conversations—much as a product backlog item is a shorthand placeholder for a longer Q&A session. To help capture these issues, the ScrumMaster should write a note on a whiteboard in a section designated, “Parking Lot,” then signal the speaker to move on. At the end of the meeting, the ScrumMaster should ensure that the team members make plans to address any urgent parked items.

Keep It Real

If your only goal for the daily scrum was to have people arrive on time, give a succinct update, and then leave, you’d be set. But don’t forget that the purpose of the daily scrum is to ensure that the team is on track for accomplishing its sprint goal. Beware of rambling, vague updates that seem to gloss over a lack of progress; they often hide blocked work. ScrumMasters (and other team members) should clarify any vague or rambling updates either during the meeting or immediately after the meeting to surface any hidden issues.

Daily scrums are intended to be of the team, by the team, and for the team. Don’t let yours degenerate into infrequent, status reports that yield little collaboration and undermine progress to the sprint goal. To ensure productive daily scrums, insist on a daily cadence, remain standing, stay on topic, and park the deep dives until after the daily scrum, all while keeping a sharp eye out for hidden problems.

Managing Bugs in Scrum and Agile Projects

Fri, 01 Jan 2016 19:15:00 -0600

As I was revising and writing new content for The Scrum Field Guide, 2nd edition, I emailed my friend Bill Hanlon at Microsoft to get his feedback on my existing chapter on bugs. Bill and I worked together years ago and I often value Bill’s opinion more than I value my own. The guy constantly innovates on things that others would say are good enough. Things are never good enough for Bill, and he’s constantly experimenting and trying new things.

Bill and I began a fantastic dialog about bug management that didn’t conclude until after my book deadline had passed. I’d like to share with you Bill’s approach, how to get started using it, and how my own approach has changed as a result.

Start with a Good Codebase

Bill defines a good codebase as one in which it’s quick and easy to fix bugs. The metric he uses to measure the goodness of a codebase is Average Bug Age (ABA), sometimes called bug cycle time. Bill postulates that the ABA of open bugs is the key to determining if a codebase is of high quality and debt-free.

If a company has a good codebase, then the following will be true:

Since it’s quick and easy to fix bugs, most of the bugs have been fixed already. This yields a high-quality product.
If it’s quick and easy to fix bugs, then adding new features is easy, too. Therefore, team productivity is high.

Now that we have established what constitutes a good codebase, let’s explore the actual fixing of bugs.

Return Bugs to Their Creators

Bill and I both do real-time bug fixing. In The Scrum Field Guide, I advocate fixing high and mid-priority bugs in real-time, but putting low-priority bugs on the product backlog. Bill fixes every bug in real time, even the low-priority ones. We’ll come back to that whole putting-on-the-product-backlog later. First, I want to tell you about Bill’s novel approach to real-time bug fixes.

Bill’s teams have a rule in place, where the person who wrote the buggy code is required to fix it before that person is allowed to do anything else. The flow works like this (I’ve revised some of Bill’s terminology but the flow is the same):

Team member (the discoverer) finds a bug and finds who wrote that bit of code (the originator).
The discoverer gets up, goes to the originator (if they are not already working together) and says “I’ve found a bug in some code you wrote—let’s fix it together.”
The originator immediately stops working on whatever they were working on and the offender and the discoverer work together to fix the bug.

What this means is that if a bug is found by anyone on the team, they identify which team member wrote that code, go to that person with the bug in hand, and say “fix it with me,” resulting in the originator having to stop whatever they are doing to fix the bug.

Bill told me that while bug-prone team members tend to hate this rule, the benefits far outweigh any negative reactions. The biggest benefit for Bill is that the bug-prone members tend to spend a good deal of their time fixing old bugs instead of writing new code. As a result, the best coders end up writing the vast majority of the codebase. The rule has three important side effects:

It limits the damage a bug-prone team member can do, and
It rewards team members who write clean, effective code—usually the ones who have figured out how to do TDD and how and when to refactor—by freeing them up to them write even more code.
It provides the buggy team members with incentive to learn to write better code. And that results in overall faster teams, and a more stable, higher quality codebase.

Stop Tracking Bugs—Yes, All of Them

At this point in the conversation, I was jumping with excitement. It only got better when we started talking about bug tracking systems. I was sharing my frustration with Bill on how a customer of mine was arguing profusely for keeping every single bug logged in a tracking system. I said it was a waste of time and that I’d only track the bugs that were not fixed in real time—the low-priority bugs I’d added to the product backlog. Bill told me I was crazy to track even those bugs, and he had the data to show me why.

A few years ago, his teams stopped using a bug tracking system. Why? Because team members said, “It takes too long—it adds too much time to the bug-fixing process.” The teams said that having the discoverer write up the bug in a bug tracking system, and then having the originator read it and ask questions, slowed things down too much and seemed like doing a process for the sake of doing a process, not for building a quality codebase.

These days, Bill’s teams only use a bug database for externally found bugs. These bugs are categorized as follows:

Not a bug: the bug that was filed in the tracking system was not a bug at all and so was immediately closed as “won’t fix.” The vast majority of the time, the bug report was created by a confused filer.
A real bug: in this scenario, the bug-fixing policy I described earlier kicked in and the bug was fixed and closed immediately.
Feature request: it’s true that sometimes people get confused on what is a bug and what is a new feature request. If a bug report is found to be a new feature request, the request is transferred to the product backlog, turned into a story, and prioritized by the product owner. The bug is closed.

Fixing bugs in real time and abandoning a traditional bug tracking system made his teams so much faster than his peer teams that his manager took notice and started implementing it on all her teams.

Fix the Low-Priority Bugs in Real-Time or Dump Them

Putting bugs on the product backlog was next. Bill and I went back and forth on the concept of putting bugs on the product backlog. I stated my case over and over again on why I put lower priority bugs on the backlog, and he asked me to just give his method a try. Luckily, I found a customer of mine who was willing to experiment with me, and you know what? I agree. Don’t put bugs on the product backlog. Just fix them, or mark them as won’t fix. Not only did the average bug age go down with this approach, there was higher quality code, delivered faster.

Using Bill’s approach has fixed one of the biggest issues I’ve had with teams over the years: the debate over the quality of new feature development. Having the ability to file a bug and have it on the product backlog means there is a way to deprioritize quality by moving bugs farther down the product backlog, and instead focusing on delivering stories. It just creates extra work for the team to triage, and keeps the debate of quality versus new stories/features alive. That’s a debate I’m tired of having. Bill’s approach eliminates that conversation altogether.

What about you? Are you still tracking bugs or trying to measure each bug’s worth versus a new feature? Do your team a favor and try Bill’s approach for a sprint or two. You’ll be amazed at the results.

The Scrum Field Guide, 2nd Edition Sample Chapter

Thu, 31 Dec 2015 05:48:00 -0600

We’ve all heard the common myth, Agile means no documentation. While other agile fallacies exist, this is a big one, and it could not be farther from the truth. Good agile teams are disciplined about their documentation but are also deliberate about how much they do and when.

Download a sample chapter from my book, The Scrum Field Guide, 2nd Edition, titled "Documentation in Scrum Projects" to read about how documentation fits in agile projects, why business should care about it, and more!

Five Things I Wish I Knew When Adopting Scrum

Tue, 02 Sep 2014 14:25:00 -0500

As I coach more and more teams, people keep saying what they wish they had when they started their agile adoption. Not surprising, there is a pattern here. I looked back at my notes from almost 10 years ago when I first adopted Scrum and XP and, oddly enough, many of the things I hear today are on my list from years ago. Lets dive in.

1) Have a Senior Sponsor

Too many times I hear “I wish my boss would hear this” or “our leadership team wants to do Scrum but won’t change X, Y or Z” or my favorite “they just don’t get it!” There are many other phrases as well. There is no trick to getting leadership or senior execs on board with agile, provided you speak their language and show data. What I do is lay out the potential benefits (e.g. higher quality, less bugs, faster delivery times) and the perceived risks (e.g. you won’t get a weekly status report, we will value quality over quantity, you are not allowed to change our direction daily). I will draft metrics with the team that we think we can achieve and report on those in the sprint review meeting, as well as showing our progress. In the end, if you get resistance, ask for six to 10 weeks to try it “by the book” – its far easier to commit to a shorter period of time than the inevitable “are we going to do this forever?” question that you’ll get.

2) Create a Definition of Done

Unfortunately I see teams get lazy on this one. I hear a lot of “we’ll do it later” or “we have one but don’t adhere to it.” Yes, people actually say this! I cannot stress the definition of done enough. It provides the team with a daily reminder on what needs to be done when they do a task, a story or a sprint. Further, it provides the customers and stakeholders with a clear understanding that when someone says the sprint is done, they know that it does include documentation and any other items that typically get put off due to laziness. Read more on how to build your own Definition of Done here.

3) Having Committed People

I was recently coaching a team when a couple folks asked me to go to lunch with them. At lunch, they said they didn’t really believe in this Scrum stuff and it was just the latest management fad that they are being forced to do. They didn’t want to do it but would go through the motions to make their managers happy. They would continue to work the same way just using different words, they said. Unfortunately, I was not shocked by this as this is a pretty common behavior in some companies. I told them “then don’t do Scrum – be honest about why you think this is bad” which led to a much deeper conversation. The point is, most of the team was committed and on board with giving it a good honest effort, and a small group was not. Shortly after, the small group that was not committed left the team and found an environment more suitable to their working style.

4) Be Honest about Development Practices

When I was on my first Agile project, Ward Cunningham, one of our project coaches, said to me “Mitch, you need to adopt the XP engineering practices of TDD, pairing, refactoring and continuous integration or you’ll be sorry.” I dismissed this claim as I knew what I was doing. It was not until we were four sprints in when we all realized that we were screwed. We had no test automation, a weak suite of unit tests and silo’d knowledge. We basically broke most of the Scrum and Agile principles. I’d love to say you can skip the engineering side, but that’d be a lie. Focus here will have a great payoff in the future. Learn more about XP here.

5) Do Scrum by the Book

This is something I did in the beginning; I was an anomaly. Doing Scrum by the book allows teams to get through Tuckmans stages of team development. They learn and grow together. It allows you to learn what works for your team and correct it. Follow the practices diligently always seeking why you are doing them. If you don’t know why you are doing a practice, seek the understanding; ask your teammates what their understanding is and figure out how to applies to you. But mostly, be open, be honest and give it a good try before passing judgment. After all, you are trying something new that you may not have done before.

Why Rework in Agile Projects is Key to Success

Wed, 12 Feb 2014 12:49:00 -0600

My wife and I repainted our house over the summer. We went through the normal process of painting a house, or a room for that matter; We looked at other houses, looked at magazines and talked to some friends. Finally we went to the paint store, looked at some more colors and ended up buying a couple sample containers. We took them home, cleaned up the area where we would do the samples and applied them.

The first three two we bought were just ugly – super, super ugly. The funny part is that we really thought one of the colors was the color that we would paint the house. My son ended up calling it “army green” and army green it was.

“Nope, that’s not doing it for me” said my wife.

Yesssss! I said to myself with a small fist-pump.

Round three and back to the paint store. The people knew us by name now.

“Still can’t find the right color?” the man behind the counter asked. I smiled and kept my mouth shut.

“We’re close!” exclaimed my wife, “I think we need to go with Mustang and that other one we discarded earlier” – two colors that I hated, or so I thought. I recall in my head the colors we’ve gone through so far.

Army green
Vomit green
Baby bottom brown
Some other ugly brown

With samples in hand, we left and put it up on the house. The color was found. It was Mustang. Yup, the color of my house is Mustang, and I actually like it.

Now you’re probably asking yourself why this story is on my blog, and what it has to do with software and throw away code. For that, I will show you an example of painting the house but with the mindset that is so prevalent in companies today, the mindset of getting it right the first time when it comes to building software.

Using this approach would look something like this:

Select the paint color (remember you can only pick one, so we go with army green)
Purchase the supplies and materials ($1,000 in our case)
Schedule and pay the crew to paint the house ($5,000)
Review the results

Now, if we don’t like the color, we do it again, and spend another $6,000 for the privilege to do so. We would repeat this process a total of six times, unless we quit first and said enough is enough, and we’d live with the color on the house that we didn’t like due to lack of funds, frustration, or most likely, both. This could easily cost us $36,000.

Why then would we ever use this approach when painting a house? We wouldn’t (maybe you would), but companies use this approach every day in order to get software projects delivered. Why?

One advantage to “getting it right the first time” is that you don’t have rework. Everyone knows this is a lie though. We end up building our systems by component, getting everything to code-complete or some level of done and move onto the next component. Each component is, in theory, done, however when we go to put all the pieces together, nothing works and we have painful stabilization and integration phases. Just as my wife and I could not pick the right color the first time, it’s nearly impossible to write code “right” the first time.

Another issue with getting it right the first time is that, in the end, things cost more. Why? Because you have to debug the code to figure out what issues were introduced by late integration. Just as painting and repainting our house would cost money for materials and labor, so does software.

Then, we have time. It took my wife and me approximately one month to have the house painted. This timeframe included the “hey, we need to paint the house” moment over the summer through the painters coming back to do some touchup work a week after they finished the job. The house was officially Mustang after three weeks, but I don’t want to cheat – it was “done” according to our definition of done after a month. Now, if we had tried to get it right the first time, the whole exercise would have likely taken, at best, eight weeks – double what it took – and most likely 12-14 weeks. Not bad, only three times as long.

At this point you’re probably saying to yourself “ok, ok, I get it – don’t paint your house without picking colors first!” but I’m not done.

Remember in the story where I said my wife and I probably would have quit, either due to our budget being vaporized, frustration or both? Well, when you relate this to software, it’s the same as shipping to your customers knowing it’s not the best work, knowing it’s not all going to meet their needs. You will probably feel bad about it, but what can you do? The time and the budget were expended. This is a crappy feeling; about as crappy as looking at a house that is “baby poo brown” or “army green” every day for the next 10 years.

So what can you do about it?

First, embrace throw-away code. Yup, there, I said it, throw-away code. Think of throw-away code as the paint samples that my wife and I purchased. That was, in essence, throw-away paint. We spent money on that paint realizing we would probably not like each sample, but what that enabled us to do is reduce our overall risk of having the project run over budget, over time, or both. In the beginning we had no idea what we wanted, but through utilizing the throw-away code mindset that we both have (she’s a program manager too, our poor kids), we got the project done in a timely fashion and it was actually under budget.

This means that you’ll use the XP practice known as refactoring. Refactoring in a nutshell is changing the code without changing the intent of the code. Thinking about it as working on a car – you go work on the engine, tune it up, make it go faster, but on the surface the car looks the same. This is the same thing. Refactoring means you will throw code away, and that’s OK, because what you gain is a deeper understanding of the system.

Achieving Successful Scrum Team Dynamic

Sun, 13 Oct 2013 05:11:00 -0500

In the world of Scrum it’s fairly common for organizations to quickly jump into practicing the agile methodology and then become frustrated or disappointed when they don’t see significant immediate results. Of course, going through the motions of Scrum and actually practicing it effectively are two very different things. In fact, as I explained in a recent Labcast Podcast with OpenView Partners, the road to the latter starts much earlier in the adoption phase — by establishing the right organizational and team dynamics.

Better Software Magazine Article on Interviewing & Hiring

Sat, 14 Sep 2013 07:44:00 -0500

Better Software Magazine asked me to write up a piece on hiring and interviewing based on a session I did at ALM Summit earlier this year.

I am very excited to have this article published. Check it out in PDF format here. The article begins on page 20.

Waterfall is King.

Wed, 04 Sep 2013 21:07:00 -0500

Agile aficionados seem to have it out for the old faithful waterfall process. For years now, they have claimed that a requirements document can’t ever be complete, that you can’t possibly know everything upfront, and that waterfall’s guarantees of on-time delivery are false. Where do they get these crazy ideas?
After all, Winston W. Royce’s “Managing the Development of Large Software Systems” states that software starts out with two essential steps; analysis and then coding. Doing the analysis is the easy part. Get people together in a room, write down all the requirements, refine them and then have them approved with a formal signoff. Not bad! As long as you can guarantee that you know exactly what your customers want in the future, without ever seeing it, you’ll never go wrong. No problem, right?

While you’re at it, be sure to put a stop to all innovation in your industry on the planet, too. With innovation come new ideas, and with new ideas comes change. Your competitors are just going to have to stop developing their systems so you can release your three-year project. After you meet your deadline with all of the agreed upon requirements, you can all collectively consider what the next new thing should be.

As far as upfront planning goes, those touchy-feely agilists claim it’s impossible to know everything at the beginning of a project. What they don’t realize is that if you have enough time, you can figure out anything and become an expert at it. Plus, without perfect plans, how would you ever create the project schedule and determine the overall cost? Sure, if people change their minds somewhere during the project, it’s going more cost them a fortune. But, hey, some of us don’t work for free.

Finally, those Lego-crazed, note card-wielding agile lovers say that we can’t have it all. That we’ll have to choose which of these key elements is going to be flexible: date, features, quality, or cost. That’s just nuts. Of course we can guarantee we will deliver the agreed-upon system on time, on budget, and with exceptional quality. You just have to believe.

Now, you might be saying to yourself, “But Mitch, I’m not sure I can predict the future, or know what everything will cost up front, or design the perfect system in a set timebox.

Software is creative and it takes time to produce the art that is the work of the developer.” Why, that’s just balderdash! You’re starting to sound like one of those crazy agile folks.

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.

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.

Recently we’ve been using various products like Camtasia (paid) orOBS Studio (free), but the premise/goal/outcome is the same. Teams create a quick PowerPoint (or text file) with information on what was done for the day. They record their screen and also record themselves speaking while the screen record is happening. They walk the other team through the status for the day, and it results in a quick and efficient team sync. That way, when the next team picking up the work needs to know what’s going on, they can reference the video. We’ve experimented with posting on hosted sites like YouTube, however, due to sensitive information, we find it easier to post to a shared project folder (e.g. Slack, Microsoft Teams, Resilio Sync) where people have the video upon starting their day.

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!

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

This was an experiment I ran in early 2006 with my now 18 year old graduate, Ashley. I was able to replicate this to other kids in the neighborhood that were willing. The biggest challenge was helping the kids see the value. Kids with good grades were more resistant than those with poor grades. Even my now 12 year old son resists this. He's disorganized, but has good grades. I tell him that won't scale to college, but what do I know, I'm just a boring old adult - so I'm told. Enjoy!

---

I was chatting with Mike Cohn Agile 2005 about user stories. He told me how he applies some of these techniques to his kids. I was having a hard time with Ashley. She was constantly putting her homework off and doing it in the car. I didn't see the point to do it at that point as any learning was lost and it was just an exercise in checking a box.

We talked about what is important to me, as a parent, when it came to her (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!

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.

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!