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

One Watermelon at a Time, One Bite at a Time

The beginning of July is a perfect time to have a slice of watermelon and consider the benefits of working together, in small batches!

If you’ve heard the adage “you can’t hold two watermelons in one hand”, you know it’s about asking for help, instead of trying to do too much, by yourself, all at once.

Scrum Teams are designed to handle complex work. Two qualities that contribute to a Scrum Team’s ability to handle big, watermelon-ish features are collaboration, and working in small increments.

Collaboration

Does your Scrum team work together as a unit?

By design, Scrum Teams are cross-functional. Each team member has skills in more than one area. The advantage is that no single team member needs to handle a complex, whole watermelon-ish piece of work all on their own and risk dropping it. The best writing I’ve seen on the topic of cross-functional teams is from Jason Yip: https://medium.com/@jchyip/why-t-shaped-people-e8706198e437.

In fact, collaboration is infused throughout Scrum. Here’s a quick list of how:

  • Product Owner plus Development Team plan together what work will be done in a sprint
  • Scrum Team coalesces around a Sprint Goal or objective for each sprint
  • Development Team works together continuously, and syncs up at least daily
  • Stakeholders collaborate with the Scrum Team via a feedback loop at the end of each sprint
  • In larger organizations, multiple Scrum Teams collaborate to resolve dependencies and deliver a complete, integrated increment every sprint
  • Scrum Master works in collaboration with those outside the Scrum Team, to ensure the team’s needs are met and impediments to progress are removed

Working in small increments

A Scrum increment is already a small slice of work, restricted by the timebox of a month or less. To improve the value of the increment, in the watermelon analogy, we want to deliver bite-sized pieces of watermelon, or maybe bowls of them. But they should be fresh, bite-sized pieces. The point is not to hold onto that big watermelon of work for a really long time and try to deliver the whole thing at a much later date.

Here are some techniques my teams have used to deliver higher value product in more readily consumable pieces:

  • Smallest possible user stories. Slicing stories is an art form. It’s important to do what makes sense for your product and your team. I like to ask my teams “what does the smallest unit of customer satisfaction look like for this product?”
  • A Definition of Done that includes everything: all the QA and user acceptance and regression testing, and everything else that’s needed to bring this story all the way into the actual customer’s hands. The idea here is that you don’t have “developer ready” work that is waiting around to be validated while it is losing its freshness. You’re going to need attention to good organizational collaboration unless your team works only on smaller isolated products.
  • Shorter sprints. In each sprint, the Scrum Team produces a releasable increment. When an increment is shorter, the value delivery checkpoints are more frequent.

Delivering small increments

If very large, undefined work items are like watermelons, then slicing them up and cutting them into well-defined, bite-sized chunks will make them easier to process, and ultimately easier to consume. Remember, it’s only when those bite-size pieces of work hit the tastebuds of the customer that we learn for real how much all our work is worth.

Bite-sized watermelon
Smaller work items are more “digestible”, and able to be delivered quickly. Only by delivering can we unlock the value that comes from customer feedback.

Basic Transparency

An organization with good communication is like a clear pool, where people can see to the bottom of things.
Organizations with good communication are like clear pools, where people can see to the bottom of things.

Agile processes are famous for transparency.

For anyone who doubts this, or is new to Agile,

  • Transparency is implicit in the first item of the Agile Manifesto. Individuals and interactions are valued over processes and tools, and the best interactions happen when communication channels are open.
  • Transparency is the first of the “three pillars” of Scrum (transparency, inspection, adaptation).
  • Transparency also features prominently in the scaled frameworks built on top of Scrum. In the Nexus (Scaled Professional Scrum) framework, transparency is called for in all artifacts, dependencies and the state of the increment. I’m not personally as familiar with SAFe (Scaled Agile Framework) as I am with Nexus, but transparency is a core value of SAFe. I know even less about LeSS (Large Scaled Scrum), but you can read about transparency in LeSS here.

The benefits of transparency

Here’s what happens when groups work in a transparent way:

  • Quality improves. When more people see a product during development, more imperfections are brought to light, and can be addressed before the product is released to customers. An open and safe platform for raising and resolving issues also incentivizes teams to perform better and improve quality.
  • Metrics improve. When everyone can see first hand what’s happening in an organization, data and reporting are confirmed by observation. You may even discover better performance indicators when you have open communication and when data is collected directly at its source.
  • Risks are mitigated. Transparency allows you to see ahead and gives you the opportunity to fix small problems before they become big ones. Risks, internal and external, are easier to spot. Planning is better, and the organization is more likely to see its way towards the most profitable path ahead.
  • Product improvements are realized. Ideas find their way into the open where they can affect positive change. Confident teams that communicate well do better and more innovative work.
  • Quality and productivity work hand in hand. An experiment published in the Harvard Business Review demonstrated that when cooks and customers could see one another, customer satisfaction improved over 17 percent, and service was 13 percent faster.
  • Waste is reduced. Transparency saves you energy and time. When you synchronize with reality, less energy is wasted trying to be something you’re not. That energy can be used to fix anything that you would have wanted to hide. Spend less time re-framing stories and more time fixing things.
  • Culture change. There is a snowball effect when you start being more open in your organization. People who are doing well are proud to share their success. It spreads. High performing teams model success and other teams improve.

How can organizations get better at transparency?

Scrum comes with transparency built-in. For teams who are brave enough to adhere to it, adopting the Scrum framework makes it easier to work transparently. Scrum teams use information radiators to display up-to-the-moment metrics. We meet daily to update one another on work in progress, collaborate and overcome issues. Product Roadmaps, and to an even greater extent, Product Backlog stories are openly discussed. Stakeholders and development teams flesh out product direction and specifications together. The team’s work is demonstrated at the end of each Sprint at the Sprint Review. If you practice the Scrum ceremonies, you are well on your way to reaping the benefits of transparency.

If you’re not using Scrum, you can still create room for mutual transparency to grow by bringing open practices into your daily routine. Encourage candid discussion during your regular status briefings. Simply listen. Hold meaningful feedback sessions after every increment that’s released. Involve the development team in roadmap discussions. Acknowledge that everyone working on the project has a vested interest, and when the project is a success, it is to everyone’s credit.

Aim for a pristine pool of shared information, and reap the rewards of transparency!

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.

HTTP/2 For Faster Web Page Loads

HTTP/2 is in the news lately because it’s just been approved as a standard! This is good news because HTTP/2 offers more efficient and potentially more secure ways for your browser and server to send information back and forth. An ultra-simplified explanation of one part of it, multiplexing, is that it allows multiple browser requests to be processed together. So, a slow-loading image at the top of a web page won’t necessarily hold up the rest of the page.

For web programmers, it’ll no longer be necessary to jump through certain hoops to get the best performance. We can all look forward to the freedom to find newer, better ways to improve performance. Mattias Geniar and Iliyan Peychev each provide some good technical reading for developers (e.g., no need for CSS Sprites and domain sharding).

See HTTP/2 In Action

To see HTTP/2 now in Firefox and Chrome, just look for the “h2-14” protocol identifier.

Here’s how:

On Firefox:

  1. As of Firefox 34, since about August 8, HTTP/2 was enabled by default! Still, maybe you want to confirm, so enter ‘about:config’ in the address bar and search for the option named “network.http.spdy.enabled.http2draft”. It should be set to true.
  2. Enable “Web developer > Network”.
  3. Check the response headers from the server. For sites using HTTP/2, you’ll see a response is “HTTP/2.0”, and also Firefox inserts its own header “X-Firefox-Spdy: h2-14”. For example, load up https://http2.akamai.com/

Using “Web developer->Network” to see HTTP/2 in Firefox
Using “Tools > Web Developer > Network” to see HTTP/2 in Firefox

On Chrome:

  1. Download Chrome beta at https://www.google.com/intl/en/chrome/browser/beta.html
  2. Enable on the protocols column from “Inspect Element”. Mattias Geniar provided excellent instructions here, already: http://ma.ttias.be/view-httpspdyhttp2-protocol-google-chrome/
  3. Also, in Chrome, HTTP/2 isn’t enabled by default, so you’ll need to set a flag. Mattias Geniar helps out again, http://ma.ttias.be/enable-http2-support-chrome/.
  4. Then load up an HTTP/2 site such as https://http2.akamai.com/, and check it out!

Using the Protocol column from “Inspect Element” to see HTTP/2 in Chrome

More Info

For the latest information about which browsers and products have implemented HTTP/2, follow the link for known implementations from here: https://http2.github.io/

http2.github.io/faq/

Here’s a useful chart showing which browsers and applications support HTTP/2, along with the popularity of each: http://caniuse.com/#feat=spdy

 

Internet of Things In My Garden

Image from page 16 of "Currie's farm and garden annual : Spring 1917" (1917) Source: U.S. Department of Agriculture, National Agricultural Library
Source: U.S. Department of Agriculture, National Agricultural Library Page 16 of “Currie’s farm and garden annual : Spring 1917”

Talking to your plants might make them grow better. I haven’t come across the evidence that confirms it. I’m more interested in the day my plants talk to me.

Tell me, sweet blueberries, is the pH too high for you in here? Is the sunlight enough or is it too much? Roses, are you thirsty? How are your roots doing? My dear tree, are you seriously considering running a root that close to the surface of the freshly paved driveway?

I want the lawn service to be notified of everything the plants have to say. I want to set preferences with the lawn service, too. For some things, I want the service to propose a date and let me confirm. For other things (bugs!), I want them to show up as soon as possible.