Senex Rex at Work: February 2014

You may be interested in what Senex Rex does. Our mission is to help clients become highly profitable long term. When our clients make more money, they have greater freedom to innovate and their employees and shareholders have more freedom to enjoy life. We happen to think agility helps in many cases, so we often teach and coach agile theory and practice. Few contractors teach clients how to sustainably retain and improve agility; we specialize in that. We have many other tools in our tool box. Here’s a snapshot of the work Senex Rex did in February 2014. Continue reading

Exponential Case Study: 3 Benefits from Agility

Senex Rex case studies help clients better understand the benefits and challenges of agility. Here is a perspective from Pablo Martin Rodriguez-Bertorello, Chief Innovation Officer of Exponential. Senex Rex trained Exponential’s executives, managers, engineers and product management staff to deeply understand agile theory and practice, so Exponential could stand alone with no further external training or coaching. Our mission is to effect permanent change, not maintain change. We are proudest when we leave the building and our clients advance rapidly on their own. —Dan Greening, Senex Rex Managing Director

Exponential adopted Scrum in July 2014, and rapidly achieved three great outcomes. We dramatically increased the rate we completed features, reduced our bug density and reduced our release duration. These outcomes followed a mass company training by Senex Rex, and deep executive commitment. No external coaching following Senex Rex training was required. Continue reading

The Goal Revisited

The Goal by Eliyahu Goldratt is a business novel that recounts how a factory manager shakes off complacency and isolation to save his factory and its employees. Many MBAs, system scientists and agilists have read it.

I read The Goal 7 years ago. I was so excited I sent our CEO an email. “Have you read it? It has so many messages for us!” I said, breathlessly. “Yep. I’ve read it. Great book,” he said.

 

My coach friends and I have lately been trying to inspire executives and managers to sustain agile practices, to become competent agile coaches themselves. To help managers understand organizational agility, we have distributed copies of The Goal, foisting it on managers and begging them to read it. I felt I had to refresh my memory of it. On this, my second reading, I am inspired again, but for different reasons. Continue reading

Forecast Horizon: Does Your Team Communicate?

Good communication between product manager and team, between value appraisal and product development, leads to success. It helps you build the right thing at the right time. When the Product Owner and Development Team communicate well, the Product Owner can forecast feature delivery dates with a statistical likelihood. It promotes great architectures. The Development Team can build, but not over-build, a resilient architecture suitable for likely future needs.

I developed the Forecast Horizon metric to measure team communication. Forecast Horizon is the sum of work estimates from the top of the backlog through the first unestimated Product Backlog Item. Since many Product Owner put unestimated Backlog Items at the top of a Backlog, you may choose to skip unestimated backlog items that have been modified since the last Sprint Planning or Grooming meeting. Forecast Horizon can be expressed in team-time, by dividing by a recent average velocity and multiplying by sprint duration. In my work, I usually talk about Forecast Horizon in weeks. Continue reading

Four-part User Stories: Functionality that Matters

Four-part user stories improve communication between Product Owner and Development Team. They include context about the user and the sponsor of the work, which inspires creativity and better architectures from the team. They also make Grooming and Sprint Planning meetings faster, they yield more successful outcomes, and they facilitate Product Owners making better trade-offs. Are they better than sliced bread? I’ll let you decide.

Story Template

User stories are a short, structured format for Product Backlog Items in Scrum; descriptions of the functionality a Product Owner wants implemented. Explicitly naming the user and the value the user obtains forces Product Owners to consider users and helps developers rapidly understand what needs to be built. Historically, user stories have had three-parts: a stakeholder, a description of the functionality and a description of why the user wants it. I’ve found that adding a fourth part greatly improves ordering in the Product Backlog. Continue reading

Daily Mantra: Contribute 10× the Value You Capture

I have a little mantra I say to myself whenever I walk in the door of an employer.

“How will I save or gain at least 10 times my daily salary for my organization today?”

This question challenges us, especially if we are buried in the beast of a large organization. We might not even know how we add value. But the confusion just points out that we have a responsibility to figure it out.

Once you figure out how you contribute, you should say to yourself, “Well how do I measure that?”

Once you measure yourself, you might wonder how you can do better. You start experimenting with what you are doing, and measuring outcomes. Continue reading

Pair-Author Backlog Items for Faster, Better Results

Product Backlog Item (PBI) writing in Scrum is best done by pairing a Product Owner with an architect or team member. The Product Owner brings a stakeholder perspective to the table, and PBIs should include that “value perspective” in every case. When the PO is not “primary”, you get PBIs that have no demonstrable stakeholder or business value.

However, some POs think they are the only people who can initially author PBIs. They think they must wait to talk to the whole team to get them into better shape. As a result, the whole team must edit confusing PBIs tied to an uncertain architecture.

When the Product Owner waits for the whole team to meet to incorporate developer insight, Product Planning slows, at very high cost to the organization. Continue reading

Agile Resolutions

January is “New Years Resolution Month” for me. I plan what I’ll improve in the rest of the year and how I’ll do it. Roughly 88% of people who make New Years Resolutions fail [Lehrer 2009]. Twenty years ago, software projects had extremely high failure rates like this. The software industry started adopting “agile” management practices, bringing project failure rates down to less than 50%.

Continue reading

Velocity Variance: Should we seek consistent velocity?

Abstract

Rhythmic experimentation defines Scrum. A good Sprint experiment seeks to improve important metrics, such as increasing velocity or decreasing bug count. Some managers claim consistent velocity is important. Percent velocity deviation, σ(V)/E(V), is a reasonable metric to compare teams’ consistency. However, software companies usually look for innovation and profitability. Staid, old companies recreating boring stuff can get very consistent velocity. When innovating teams are asked for consistent velocity, some may game the metrics by padding, or stop innovating. Therefore, use consistency only as part of a collection of metrics that describe a team’s behavior, but not a target.

Continue reading

Ad Hoc to Agile, Scrum and Scaling

tortoise-hare

A colleague recently asked whether a team he encountered was agile.

  • The team is managed by a smart computer scientist with deep architectural understanding.
  • There are two specialist engineers on the team: one with database knowledge, and the other with Javascript/CSS/HTML.
  • Periodically team meets with the manager and product manager to plan. Together they decide the overall functionality to be delivered by the team, and decide how long they need, typically two to four weeks, which they call “sprints”. They select functionality that they believe they can finish in that time. These are not user stories, but a collection of requirements that seem like they should go together. The work is not directly releasable.
  • Since the manager is smart, the team usually defers to the manager’s architectural approach, which consciously considers team member skills. The team decomposes the requirements into tasks, carefully constructed to reduce the need for member interaction. They try to minimize source code clashes in advance, assigning tasks to people carefully.
  • The team members typically work in isolation. Although they do not have daily stand ups, they are co-located, so they can always ask co-workers for advice and help. Each is responsible for the tasks he or she was assigned.

Some team members want to use Scrum, but the manager has said, “No. Scrum involves too much process, too many meetings, team members will feel micromanaged.” Continue reading