This is Part 1 in a series about improving communication between programmers and the business.

Audience: Programmers and Project Managers

Estimated Reading Time: 4 minutes

---

Software development teams often face significant challenges with inter-role communication. I’ve noticed a recurring pattern of programmers wanting to focus their energy on changes whose value is difficult for the business to understand. We often capture this work as Tech Tasks and prioritize it based on how vocal people are, not on its return on investment.

The Problem

When the business asks questions like, “What are you working on?”, they are usually trying to understand why programmers are choosing their current work item. They are seeking visibility into how the team is investing time and the business’ money.

Often the answers to these questions lead to clumsy and uncomfortable conversations. The programmers feel unfairly judged and the business feels powerless to steer their project.

The Solution

An effective way to increase the effectiveness of these situations is for the programmers to share the why behind this work with the business. If programmers don’t understand the business value of the work they are doing, then they can’t understand the Return on Investment (RoI) of the Task and thus can’t safely prioritize it for the business. If developers can discover the business value of these Tech Task by asking themselves, “Why?”, then they can share this information with the business and work with them to prioritize these Tasks the same way the team does User Stories.

How To Do It

We are seeking the core business value behind our technical tasks. To discover this value, ask yourself 5 Whys and your answers will lead you to the value this Tech Task provides to the business. The 5 Whys is a Six Sigma technique for Root Cause Analysis and the root cause of our desire to do this Tech Task is what we want to better understand.

Once you can explain the business value of this Tech Task, you can either work with the Business to prioritize it as a Tech Task or even reframe it as as User Story.

Example of 5 Whys

Suppose while you’re in the process of finishing your last User Story, you discover that it was difficult to test interactions between the Order and Customer classes. In particular, it is difficult to “add” an Order to a Customer and you believe the solution is to fundamentally change how Customers interact with Orders.

I want to refactor the Customer class.

Why?

So our code is easy to test

Why?

So we write better automated tests

Why?

So we find defects quicker

Why?

So we have fewer defects

Why?

So our product is more usable

Reframing Tech Tasks as User Stories

If you want to invest in improving communication between programmers and the business, you can write your Tech Tasks as User Story.

Mike Cohn says that User Stories take the form:

As a <type of user>, I want <some goal> so that <some reason>.

Getting these three parameters right is critical to writing great User Stories.

We can’t know the what (<some goal>) or the why (<some reason>) until we understand the who (<type of user>).

Our choices for the who are As a programmer or As the product owner. If we look at the 5 Whys listed above, we see that the topmost answer is from the programmer perspective and the bottommost is from the business perspective and the answers in the middle are a combination of the two.

If you intend to write Tech Tasks as User Stories, I’d advocate for having an Epic User Story or Theme that relates to the highest level Why. This means that the Epic is written in purely business language. Next, we can write finer grained User Stories that are written using more technical language, but still have a “So That” clause that relates to a business concern.

This allows us to honor both perspectives while still being able to capture simple Acceptance Criteria.

The Epic

We can write the Epic User Story for our example as:

As the product owner, I want my product to have fewer defects, so that my customers find it more usable.

The User Story

As a programmer, I want to refactor the Customer class, so that our code is easier to test.

User Story Hierarchy

At this point we could choose to stop writing User Stories and just get to work. We could also create tiers of User Stories, on for each level of the 5 Whys. Each tier of User Stories would be the so that clause for the level of User Stories below it.

These hierarchies are more useful for clarifying the business value of Tech Tasks and Non-Functional Requirements (aka Cross Functional Requirements) and are generally not helpful for conventional stories.

• Usability – As the product owner, I want my product to have fewer defects, so that my customers find it more usable.
• Quick Defect Discovery – As a Quality Analyst, I want to find defects quicker, so that we have fewer defects.
• Test Automation – As a Quality Analyst, I want better automated tests, so that we find defects quicker.
• Easy to Test Code – As a programmer, I want our code to be easier to test, so that we write better automated tests.
• Refactor Customer Class – As a programmer, I want to refactor the Customer class, so that our code is easier to test.

Tags

We can also tag our User Stories with all of the Themes or Epics that they support.

As a programmer, I want to refactor this class, so that our code is easier to test.

Tags: Usability, Time-to-market, Maintainability

Have the Conversations

The real key here is to have the conversations between programmers and the business where you truly try to understand the perspective of the other and you work hard to present your perspective in a language that the other can easily understand.

I originally posted this in 2009 without the sub-title and received a lot of feedback that helped me understand that my title was leading readers to think that I am anti-Scrum or anti-Agile. For context, I am a long time agile zealot and think that Scrum can be a great agile introduction or transition for non-agile teams.

Audience: Anyone involved in software development

Estimated Reading Time: 5 minutes

Scrum is often promoted and adopted as a holistic software development methodology. It simply isn’t. It doesn’t help us manage our project goals, and it encourages us to build software that grows increasingly hard to change. Scrum is great at what it is intended to do, but it only provides a subset of the Agile practices we need to succeed.

Scrum fails to acknowledge the entire scope of software development. To demonstrate this, I’m going to break down the levels of scope the same way Scrum does. Project: This is about deciding what the project goals are and steering towards those goals. Milestone: This is a sub-interval of the overall project in which part of the project is delivered. Feature: A change to the software that has value to the client. This is often described as a requirement or user story. Features are usually intended to fit within a single Milestone. Scrum does a great job of addressing the Milestone level of scope but mostly punts on the other levels.

Project At the project level, Scrum calls for a product backlog, but doesn’t describe how to create or manage the backlog. The benefit of this is that it helps projects transition from the expensive Big Design Up Front of Waterfall. The major drawback is that many teams feel they can change the direction of the product without cost, because Scrum largely ignores that cost.

Milestone (Sprint) This is where the heart and soul of Scrum lives. It teaches teams good habits with regard to dynamic steering and continuous improvement.

Feature (User Story) This is where Scrum breaks down. It focuses entirely on finishing the user story (as defined by the Product Owner at the beginning of the Sprint). While this is a good contrast to development that is focused entirely on creating ‘systems’ as defined by programmers, it does not do a good job of honoring the complexity of software development. In particular, it doesn’t account for the cost of removing duplication in code, data, or concepts. This leads to ‘code debt’, which means future features will be more expensive to implement than they need to be.

Dissonance Scrum tells us that we can steer projects as though they were speed boats while allowing us to turn the project into a barge. At the project level, we are told that changing our project design is as easy as changing the backlog. At the feature level, Scrum encourages practices that make changes to the project become more expensive as each feature is completed.

The Story Some well intentioned person in product management, looking for ways to improve their process, discovers Scrum. It is the answer to their prayers; no more late projects that don’t perform the way the client expects!

Three of the managers from the team go to a couple of days of classes and become Certified Scrum Masters. Now they know what they’re doing! As the new project is ramping up, they teach everyone on the team how Daily Scrums, Sprint Reviews,and Sprint Planning meetings all work and everyone starts doing them.

Everything goes great: valuable features get finished, the product backlog changes without a hiccup, and the team spends much less time planning and writing documenting while spending more time making progress.

Some time passes…

Things are a little tougher now. Programmers occasional mumble about re-factoring, engine work, etc. They ask to work on things that are clearly not user stories. Some features start slipping, or are perceived as ‘hard’ where just a month ago they would have been easy.

More time passes…

Things are definitely worse now. Most estimates are higher than the Product Owner expects. People are falling back into their old development patterns (e.g. wanting to write a technical design before they will make an estimate). Bug counts are increasing. What used to be easy is now hard.

The Advice Ensure that there is resonance between the way you plan the project and implement the features. While there is the Scrum layer between them, they are still tightly coupled. For example (and this is not what I recommend), if you use Waterfall to build your product backlog, then you might want to have your programmers do more Big Design Up Front so they can benefit from the large amount of project planning that you did up front.

An example of good resonance would be: Project planning using Agile Estimating and Planning by Mike Cohn Milestone planning with Scrum Feature implementation with Extreme Programming (XP) All three of these methodologies are Agile, and support the flexibility and discipline of the others. Agile project planning is still in its infancy, but Agile Estimating and Planning will get you started on the right foot. Remember to take care when you steer your project, because change is rarely free. Make sure that you integrate all relevant perspectives before you make a significant change to your product backlog.

Get the right developers, product designers, and client in a room and let them candidly discuss the change. Ask the developers what changes they think would be good to make. They know what is easy to change and probably have a pretty good idea of what is valuable to you. Extreme Programming is a great match for Scrum (they even share a lot of the same practices). XP has two main effects on a project: The programmers get better at programming faster than they would without it. Change in project direction is less painful because the software itself is easier to change. XP also fixes some of the outdated concepts in Scrum by bringing the client and developers together and by allowing user stories to change as soon as the client realizes they should.

Scrum is definitely an improvement for many projects, but you should not switch to it lightly. Make sure you understand how it fits together with the way you plan projects and the way your developers implement features.

Audience: Everyone

Estimated Reading Time: 2 minutes

I just read this excellent blog post and it reminded me of something I tried to describe to some of my teammates.

Quintessence: The fifth element for the Agile Manifesto

My story goes something like this: A marathon runner realizes that they have a couple of small stones in their shoe right before the race begins, so they takes off their shoes to remove the stones. While doing this, the race starts.

The runner’s coach has always trained them to run the race “10 feet at a time”; just focus on getting through the next 10 feet and the race will take care of itself.

Since they are very literal, they considers how to run the next 10 feet the quickest: 1) Spend 1 minute putting on their shoes 2) Just start running.

The runner decides to just start running and they are happy with how much progress they make in the first 5 seconds of the race.

After a couple of miles, the runner is starting to slow down. Their feet are cracked and torn from running on the rough pavement. They are BEHIND! They consider stopping and putting their shoes on, but DO NOT HAVE ENOUGH TIME. They are behind and just need to keep running for the next 10 feet.

And so it goes…

This is exactly what focusing on the short term at the expense of the real time-frame of the project feels like to me. We make decisions that help no one and that we know are dumb just to get something done this week, even when it puts us further away from our real goal.

This is also relevant: The Tyranny of the Urgent (over the Important)