Interruptions and Missed Commitments

Drop of water - Interruptions have repercussions and possibly cause teams to miss commitments
Photo by NON on Unsplash

Some Scrum Teams find it difficult to stick to the commitments they make. While it can be for many reasons, a common one is that a team is being interrupted with urgent tasks that take attention away from the work that they planned.

What are some of the tools we can use as Scrum Masters to confirm that interruptions are really a problem for our teams, and to help them adjust to a more predictable way of working? Here are three tools that I’ve used with some success:

1. Make the “interruption” work highly visible to the team, and also to those who are doing the interrupting. 

Making things visible is usually a good idea in general. Going on the idea that interruptions potentially cause a slowdown or drag in the pace of work that was planned, making it easy to notice the interruptions can help people to notice the resulting drag. When everyone can see the drag, we can have more productive conversations, and consider course corrections that might help. 

During a sprint, I might use different colored cards on the Scrum Board to make additional work or scope changes more prominent. At the end of a Sprint, I might show a report during Sprint Review, showing what the Scrum Team actually worked on that was different from what they originally committed to. Most tracking tools can generate reports when stories are added to sprints after Sprint Planning, for example.  

It sounds easy, right? In fact, tracking interruption work can be very easy. The difficulty usually comes in with the discussions that need to happen. In order to get to a place where the team can work more productively, we need to attend to the needs of the people who are causing the interruptions.

One thing that can get in the way of the needed discussions is a team’s own awareness and fear that, by calling attention to the extra interruption work they are doing, they will solicit disapproval. People who feed the team extra work are often powerful and influential. It’s hard to say “no” to a favor from your boss. Being sensitive to this, as a Scrum Master, you might ask the team itself for ideas about what might help in their unique situation. You might work towards better connections and relationships between the team’s Product Owner and adjacent stakeholders. Through conversations, everyone may come to better understandings and agreements about how best to interact with the team, and get the urgent interruption work done without adversely affecting the planned work. This brings me to the second tool.

2. Coach the team in application of the Scrum Values (Commitment, Courage, Focus, Openness, Respect). 

The Scrum Values are always a handy tool. A Scrum Master can help to build an environment of trust by teaching these values. That awareness of the values, and the trust that is built, goes a long way towards resolving problems related to work interruptions.

  • Clearly, Commitment applies here. The Scrum Team has made a commitment at Sprint Planning, and the goals of the Scrum Team may be at risk whenever new work is inserted into the Sprint.
  • With Courage, the Scrum Team members will be able to speak up and escalate when interruptions cause a loss of Focus on their goals. It may take some intervention on the part of the Scrum Master to ensure that the message that the team should not be interrupted gets to the people who need to hear it.
  • The team should be able to display Openness with stakeholders and also with themselves about the challenges of the work. This may happen through ongoing transparent reporting. A conversation could be triggered at a retrospective. A Sprint Review may not be the place to go into a deep dive about why work was not completed, but it can be a place to bring to light some of the challenges that otherwise would be hidden. Once noted, other actions may be initiated.
  • Respect (the idea that the team members are all capable and independent) is always essential. On a team that lacked maturity, I overhead one team member disparage their teammates for being “lazy” and not completing tasks soon enough. What was overlooked was that those team members had been asked to do side work for another initiative for their manager. In this case, respect (of the goals of the Scrum Team) was lacking from the organization, and also within the team.  

3. Coach the team to understand its velocity and to make the most realistic commitments possible. 

Finally, once the “interrupt” work is visible, and we have done all we can to apply the Scrum Values, we should turn our attention to the reality of how much work the team has proven it can complete in a sprint (the velocity). 

Even if the interruptions are not formalized as user stories and brought into sprints, it may be possible to quantify and predict the rate of interruptions. Knowing this as a range will help the team to be more accurate when planning new sprints. If we know, for example, that we have a “drag” rate of about 30-40 hrs of team time per sprint, then we could reserve that time as a buffer during planning. By committing to fewer planned stories during a sprint, there will be a greater chance that the stories we do take on will be completed. We may even come to a place where we can set a service level agreement and communicate that out to other people and teams who make unpredictable requests of us. For example, we may be able to communicate out a lead time for new requests. It may be acceptable to the requestor and everyone may realize that what is being asked is not as urgent as originally thought.

None of this is easy, but those are some of the things I have tried. Please let me know how you have helped your Scrum teams who may be struggling with interruptions that cause them to lose focus from their Sprint Goal. Call me at (407) 223-9964 or show up at one of the Agile Orlando Meetups.

Scrum Master Service to Product Owners – A Discussion Focusing on Value

Product Owners have a hectic existence. They’re called upon to make important decisions constantly. The world is swarming with ideas and opportunities competing for attention. One of the favorite parts of my job as a Scrum Master is working with Product Owners. When I can help my Product Owner to find a focus that leads to our team delivering better things, I know that I am delivering good value as a Scrum Master.

School of koi fish - Product Owners have a hectic existence
Photo by Quang Nguyen Vinh from Pexels

“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” This is a quote from The Scrum Guide. Maximizing value is a big responsibility, and it is all on the Product Owner to lead this.

Notice that I said “to lead this”, and not “to do this”.

The Product Owner needs to be able to express the results of their very important decision making around the product, but then they need to leave it up to the development team to work out the details of implementation.

The whole Scrum team needs to understand the big picture product vision, so they can work on things meaningfully. I’ve worked with Scrum Teams where the Product Owner took too much responsibility for details of implementation, and fed the development team what were essentially tasks disguised as user stories. Imagine the value that was lost to the organization due underutilizing the intelligence and creativity of every member of the development team!

As a Scrum Master, I have an outsider perspective. When I notice a Product Owner is distracted from focusing on value, I talk with them to try to steer them back on track.

One Product Owner I worked with had a Business Analyst background and was so interested in well crafted stories that they lost sight of the larger context of what we needed to deliver. Over a period of time, through discussions, I opened the way for them to see that the value is not in the stories, but in the work that makes it into production, and is actually put to use. It’s not easy to get out of a comfort zone, and this former BA struggled with letting go of details.

I encouraged them to write “shell” stories, and to involve the team more in discussions around the shells. The results of the team discussions could be formalized later by entering them into the story tracking tool. The important activity is the discussion and mutual understanding. The team should understand why we are doing something. The Product Owner should be able to explain that to a development team. The fastest and best way to do that is from talking to them about it, not by writing a detailed spec.

“Scrum Master service to the Product Owner … Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible … Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;

The Scrum Guide

As a Scrum Master, I talk to my Product Owners about all aspects of getting the best value from our team.

We talk about value streams. How do stories come in to the team? How are they transformed into user value?

We talk about end users. Who are the people who will consume this product? How do they use our product now? Can we anticipate other uses? Can we imagine them in the act of using our product? Have we observed them using it? Can we categorize our users into broad archetypes or personas?

We talk about metrics. I always question the metrics that are already in place. Does looking at these numbers affect the value delivered to the end user? How? If we are looking at quality metrics, then how important is that aspect of quality to our users? Is there a more direct way to ferret out the thing that will bring more business in? Does this metric that we are tracking actually mask something that is more valuable to the user and therefore potentially much more valuable to the organization?

There is always a lot to talk about. And there are always a lot of decisions to be made when you are a Product Owner. It’s my job as a Scrum Master to assist you with better ways to manage the product backlog, so that the value is very clear to everyone who is working on the product, and it is delivered to the user in its highest fidelity form.

Single koi fish - Product Owners are more effective when they can focus on value
Photo by Madison Inouye from Pexels

Call me when you need a Scrum Master / agile coach who’s attentive to a Product Owner’s need to focus on value. (407) 223-9964

The Truth About Stand-Ups

Oil on canvas, by Claude Harrington

People new to Scrum often find the number of meetings daunting. It’s natural to want to avoid meetings, if your experience was that they tend to be non-productive. Within the Scrum framework, however, teams use the structured meetings as tools to improve performance over time. Let’s look at Scrum’s most frequent meeting, the Daily Scrum, and see how this comes about.

I’ll get two things out of the way first…

It’s not a status meeting.

It’s a planning meeting. The purpose of getting together every day is not for each team member to report her status. You don’t need a meeting for that—a group email or a time log serves the purpose. Instead, at the daily meeting, the entire team inspects its work in progress, towards its short-term goal. The team as a whole figures out what it needs to do immediately, to attain that goal. I’ll explain more, but for now, all I ask is please stop thinking “status meeting” and start thinking “mini planning session”.

Standing is optional.

It’s up to the team to agree about how to hold the meeting. Many teams stand, as it keeps the meeting quick and high-energy. The Scrum Guide calls it the Daily Scrum, and doesn’t mandate standing up at all. Maybe your team is more productive if it has the Daily Scrum while jogging around the block.

Now that we have an understanding of some things that Daily Scrum is not, we can begin to understand what it is.

Every Daily Scrum is an investment in a more productive team.

As a Scrum Master, the Daily Scrum is an opportunity for me to observe interactions between teammates, and check in on the health of the team. Here are seven key performance indicators to monitor how well a Scrum team is functioning.

1. We are consistent.

Sticking to the same time and place every day means a minimum of overhead. A meeting location is already reserved. Everyone has it on their schedule. All we need to do is show up, ready to go.

2. We’re self-organized.

Shockingly for many Scrum Masters, the team runs their own Daily Scrums. Healthy Scrum teams don’t report in to a Scrum Master. They speak to one another, and they help each other. The team does the heavy lifting, and the Scrum Master is available as a coach and facilitator. This daily practice of team autonomy builds strong teams.

3. We work together.

Silos are inefficient. If you arrive at the Daily Scrum with the intention of getting it over as soon as possible, so you can head back to your desk and get some real work done, then something is wrong. Working in isolation slows the team down. Let me explain.

At the Daily Scrum, the team shares its latest learnings. Everyone is on the same page, at least once every 24 hours. This is also a chance to re-plan, if needed. Each teammate needs to be aware of what the others are doing in order to synchronize work. If someone moves ahead based on wrong assumptions, everyone’s time is wasted. These are the ways that this daily knowledge sharing increases the team’s performance.

The Scrum Master observes the team’s interactions in the Daily Scrum, and is ready to offer guidance. He may suggest that two developers work together to solve a problem, for example.

4. We don’t phone it in.

Well, literally, yes, you can conference everyone in for a Daily Scrum. I’ll get to that later. I’m talking about presence here. Everyone needs to pay attention for the magic to happen. When everyone listens, ready to jump in and offer help, the Sprint picks up pace. The Scrum Master facilitates by noticing if someone is tuning out, and by keeping communication flowing in positive ways.

5. We’re focused on one goal.

Every member of your team should have the answer to “What is this Sprint’s Goal?” at any moment. Daily Scrum is about the entire team, focused on the Sprint Goal, moving together. Think of a Rugby team, passing the ball to one another as they move down the field. That’s your Scrum team. As a team member, you’re always watching that ball, ready to catch it and pass it again.

6. We are concise.

Daily Scrums are never more than 15 minutes, so each person has at most two minutes to share what they’ve worked on, ask for help, get feedback, and indicate their next move. It’s enough time to get a lot of information across. Over time, the team gets better at communicating the most important bits.

7. We can decide quickly.

Daily Scrums are a practice ground for quick decision-making. The right people are together, along with the freshest, most actionable information. For anything that can be decided immediately, another meeting isn’t needed. For anything that deserves a breakout meeting, the team members can meet immediately after the Daily Scrum.

Being there in person is really important.

Collocated teams are vital in Scrum. Even splitting a team from floor to floor causes disruption. The communication channels that work best for Daily Scrums are, in order of fidelity:

1. Face to face. Meeting in the same space, in real time is by far the very best way to hold a Daily Scrum. Everyone has the advantage of immediacy, eye contact and body language. The team shares the same air and the same light. Standing in a circle, facing one another helps. Each person has the others either in their direct or peripheral vision. People can move around and change places if they need. They can be loud or soft. They cannot use a mute button. They are visible from head to toe.

2. Videoconferencing has many of the advantages of face to face, but even with the best equipment, the experience is degraded significantly. The team still meets at the same time, so immediacy is retained. But every other measure of richness in communication is lost. Eye contact is impossible, since looking directly into a video camera prevents glancing at teammates’ faces as you speak. You have no way of getting any feedback from facial expressions, the way you do in person. Body language is reduced significantly, usually to just heads and shoulders. The best suggestions I’ve heard for making this work are “invest in the best equipment possible on both ends”, and “make sure everyone is videoconferencing, not just the remote workers.” Even people who’ve used videoconferencing successfully strongly recommend supplementing it with frequent face to face meetings.

3. Conference calling. Similar to videoconferencing, you get some immediacy by meeting at the same time. But any information the video channel would have provided is wiped out. People who’ve used conference calling successfully suggest having participants use headsets during the calls. If your company doesn’t have a good conference calling system, you can try a cell phone on speaker to include remote workers.

4. Emailing daily status. Having remote teammates email their status doesn’t provide any immediate feedback at all. It doesn’t encourage the team to engage in a conversation or help a teammate remove impediments. In fact, it puts distance between team members, and discourages them from working together.

Homogeneity.

Whatever method the team chooses, it should be used by everyone. The team’s cohesion is key. If half of the team is videoconferencing while the other half is voice only, the imbalance works against the team.

Make every Daily Scrum count.

Holding a stand-up meeting every morning isn’t doing Scrum. Scrum is all about increasing the value of the team’s time. By paying attention to certain performance indicators, you can use this one, highly focused meeting to as a foundation for building a high performing team.

 

Nourish Your Team

Team Garden
(clockwise from top left) Peony, grape, rose, hydrangea

A healthy team is like a vigorous garden: it thrives in good conditions, and it can weather adverse conditions. Nourish your team regularly. Here are a few ideas that will help keep your team healthy.

Warmth

Your human team is hard wired to respond positively to warm communications. Research supports the idea that treating each other like people is what really matters: it leads to better employee engagement. Practice listening, caring, helping, smiling, eye contact and general friendliness, and encourage all these in your team. Think of the sun that warms the ground and invites seeds to sprout.

Light

Encourage individuals on your team to shed light on the contributions each of them makes. Retrospectives are a great time for this recognition, and there are many resources that can help you get started. Here’s one based on 360-degree feedback. It really can be as simple as asking each person to write one highlight of the past Sprint on a card, based on another team member’s contribution, and putting all the cards up on the wall for discussion.

Compost

Yes, I went there. The flip side of shedding light on the successes of the team is shedding light on the problems. Most people don’t want to go there, but you need to do it. In Scrum, introspection is a regular part of the team’s routine. With practice, the team becomes better at opening up and problem solving together. Think of the rose that thrives when a good compost is mixed in with the soil. All the decaying organic matter feeds the new growth.

Attention

The idea is to tend your team as you would tend a garden. Plants and people thrive when provided good conditions for growth. Check in regularly. Remove weeds. Water as needed. Be aware of individual traits.

What Can The World’s Smartest Lake Teach Us About Building Smart Teams?

Scott K. Johnson wrote this excellent article at Ars Technica about some impressive work being done in mapping and modeling environmental data at Lake George. What’s fascinating to me, is seeing people working together so well, on a huge multi-year project that has a potential for great impact. Some things I see as contributing to this project’s success:

Cross Functional Teams

The  “Jefferson Project” is an interdisciplinary partnership between IBM, the Rensselaer Polytechnic Institute, and FUND for Lake George. Each partner brings different skills to the project, and they are collaborating together. Collaboration is a basic model for a successful team. Instead of separate teams of specialists working on their own sub-projects, the groups work with one another on slices of the same project.

Organized Around A Single Goal

The FUND for Lake George states its single driving goal as Stopping the present decline of water quality and achieving sustained protection of Lake George for the next generation. They go even further than that. They want to set the standard for restoration efforts anywhere in the world. I imagine that everyone working on this project is on board with this goal. The people at IBM are probably most interested in pushing the limits of big data. At the same time, they must understand that this work isn’t about the data, but about the data in the service of protecting the lake. On any successful team, each contributor is more valuable when they understand how their contribution provides value to the larger goal.

Information Radiators

Each sensor helps scientists study the impact of stressors on the lake in real time. For a Scrum team, radiating information in real time is also vital. Everyone should be able to see the team’s progress in the moment, without having to wait until the next progress meeting.

Always-Changing Environment / Marketplace

Nothing is static. The Lake George team is moving beyond real-time data. They’re creating sensors that will adjust the sampling size when unusual events are detected. This is just the type of thing that your project team can do. Every meeting is an opportunity to inspect the work in progress. Every Sprint is an opportunity to take a step back and see the big picture. Things will always be changing. Keep in mind the Agile Manifesto value of “responding to change over following a plan”. When you notice big changes on the horizon, it’s time to increase your observations, so that your short term plans can be informed, and you will be ready to modify your course if needed.

 

HTML5 vs Native Development

Are you starting a mobile app development project? Maybe you’re worried about the expense of native deployment. Could HTML5 deliver what you need? I’d say the programming language is not the first thing you should think about. There’s something else that needs your attention first.

Start with your customers. Take technology out of the equation. Understand the people who’ll be using your application. What are you helping them to accomplish? What would they say is valuable? You’ll want to ask them directly. Use surveys. Interview them. Watch them as they do things. Reflect on your observations. How does this fit in with trends in the industry? Assume that things are changing, and keep reassessing.

  • Do your customers demand super speedy performance? Are you sure? Maybe you are optimizing for performance that your customers won’t even notice. A game may need performance, whereas a news reader… not so much.
  • Where will your customers use this thing you are building? A subway trip without Wifi could be a massive failure. Or not. Maybe that is an easily survivable use case.
  • How important is security to your app?
  • Do you know what devices your customers use? Does it include iOS, Android, Windows Phone, Kindle, Nook? Do they move from one to the other? If it includes wearables, which ones?

All the things that you normally look at when building a new product apply, whether you’re looking at initial development or you’re considering porting to additional platforms. It’s not always cut and dry, is it?

Now, look inward. Again, look beyond the technology to determine a path forward.

  • Pure native apps are rare. Most developers use a non-native language even when building “native” apps. HTML is in the compiled code. HTML and web protocols communicate with supporting servers. Are your back end services mobile-friendly?
  • More than one production line gets expensive. Does your business case justify that? What would be your costs for bringing in new resources or for training? How long would it take? Think about separate toolsets, designs, assets, releases and maintenance. Every bug fix and release is a cost.
  • How flexible do you need to be? How far into the future do you need to plan? Do you really need a strategy for five or ten years out?
  • Understand where your organization is now. Are your apps opportunistic (one-offs), strategic (mobile implementations are driven by business factors), or mobile-first (mobile is driving the business)? This mobile application maturity assessment will help in setting expectations going forward.
  • You can also get actual data for a comparison of one platform vs the other, by building only part of an app in more than one technology.

I wish you all success!

Scrum Timeboxing Is Like Doing 15 Pushups Every Day

To keep on track physically, I do a “minimum daily requirement” routine of exercises. No matter what, I do at least 10-15 minutes every single day. I allow myself to vary the exercises, but I never vary from doing this minimum. This daily goal is in addition to my weekly exercise goals. It keeps my momentum going, and inevitably, when I need to take time off from my weekly goals, it’s easier to get back into my routine, and continue to progress towards my long-term goals. It’s worked so far—it’s been about two years since I started, and I’m still at it.

Some days, the routine doesn’t feel very challenging, so I add more reps or add some weights, still keeping it to under 15 minutes. This morning, it was one of those days for pushing myself harder. It occurred to me, as I did my pushups, that my routine works a lot like timeboxing does in Scrum.

If you’re not familiar with the Agile process Scrum, it segments chunks of work into Sprints of equal lengths of time, as determined by the team. Instead of fixing the scope of a project, the iteration time is fixed. Something demo-able is delivered at the end of each Sprint.

So, you may ask, how is my couple of sets of pushups every morning like a two-week Sprint for a software development team?

Well, just as I do my exercise set every morning, the development team gets into a rhythm of delivering something tangible every single Sprint. As time goes by, I have stronger muscles, and similarly, the development team grows stronger as a team. The developers, Product Owner and QA all get better at setting realistic deliverables for a Sprint. Over time, they plan better and deliver more in the same time period, just as I can do more pushups now than I could when I started!

If you want to read more about timeboxing, this article is a good place to start. It has more than you could possibly ask, including links to some information about Temporal Motivation Theory, as developed by Piers Steel and Cornelius J. König.

Automagically Created Photo Albums

Here’s some very clever research from Disney into making photo albums automatically from all the thousands of photos we shoot.

I can imagine this technology being used along with geolocation APIs to create beautiful keepsakes of vacation trips!

logo-disney-research

Drones Herding Cows!

This is such a cute video. I’m originally from dairy farm country in upstate New York, so I have an affinity for this sort of thing.

From the research above, drones seem to be at least as effective as dogs for herding cattle … but clearly out of their league if you’re going for prize in cute:

By the way, Urban Drones (@UrbanDrones) is worth following for everything you ever wanted to know about drones. They’re active on Cyber Dust, where I originally found them. Here’s the link to use from your phone to add them: +urbandrones

More on drones

Pretty Visualizations From R, Explained

If you’re interested in learning what people go through to create beautiful graphics from basic statistical output, then spatial.ly is a site worth bookmarking.

This post, Improving R Data Visualisations Through Design, is especially worth reading. It has a handful of well-explained examples from geographer Dr. James Cheshire’s new book, London: The Information Capital. I haven’t worked with R, but data visualisation is dear to my heart. In a former life, I created animations in Flash to demonstrate things like data flows for a security network. If I ever delve back into that sort of work again, I will definitely count on Dr. Cheshire as a resource.

commute_flows_before_after