Deliver Solutions, Not Code

While it might sound like a good idea, giving your customers what they ask for might be doing them a disservice.

Often times the customer will come to us with a solution already in mind (“We need a single screen where you can enter your order and do your checkout AND print your receipt!”). Ideally though, the customer would present a problem instead (“There are too many steps to our ordering process and it needs to be less cumbersome”). An experienced development team has probably solved similar problems before and will have ideas that the customer may not have even considered. Usually these solutions end up being better and may even be less work. The development team will also have a broader understanding of the capabilities that technology brings to the table.

Regardless of how the problem presents itself, solving the problem should be a collaborative effort. The development team should be able to propose multiple solutions from which the customer can choose and tweak. Even if your customer(s) always present problems in the form of premeditated solutions, it is a moral obligation of the development team to counter-propose better solutions if one exists. Nobody understands the problem better than the customer; therefore, the customer should ultimately be responsible for selecting (or at least accepting) the solution.

Admittedly, not all development teams are staffed for this model of collaboration. However, development teams should strive to collaborate with the customer to deliver solutions, not just code.

Prioritizing Technical User Stories

As with most software development teams, we struggled with the notion of “technical” user stories early in our Agile adoption. By technical user stories, I’m referring to stories that are difficult to express in the form of a business case that is easily understood by a non-technical person. Usually these stories provide some benefit that isn’t in the form of a new feature. Some types of technical user stories could include:

  • Refactoring code to reduce technical debt
  • Infrastructure or framework upgrades
  • Researching the latest technical hotness

Attempting to write a business case for these stories in the usual fashion often times ends up something like this:

As a Developer I can use the latest version of Java so that I can use it’s cool new features.

— OR —

As a Developer I can refactor the MngrHelperObjectUtil class that was created 9 years ago before we knew what we were doing so that I don’t have to be terrified for my life and take 3 months every time I need to make a change in that godforsaken code.

These business cases aren’t usually very compelling to the product owner as they are difficult to explain and are in direct competition with normal features. So how do these stories ever get worked in?

Not Everything Deserves An Independent User Story

First let me address the problem of stories around refactoring code. It has been my experience that this kind of work usually does not deserve an independent user story. The business case of “so that it’s easier to maintain in the future” is a tough sell unless “the future” means tomorrow.

If you’re already planning on making changes to the code in question then you have a stronger case for refactoring as the payoff will be more quickly realized. As an alternative to creating a new story for this refactoring work, try bundling it with another story that requires you to make changes to this code anyway.

When trying to determine how much refactoring to do, a good rule of thumb is that it should be proportional to the size of the change you are making in the first place. In other words, if you are making a small change then do a small amount of refactoring. This way, you don’t end up with low-value features costing too much; this won’t fly with the Product Owner.

What About Work That Does Deserve An Independent User Story?

As I mentioned already, we struggled with this early on. We tried to take care of these stories under the radar. We didn’t bother prioritizing them with the Product Owner and just understated our capacity so that we would have at least a little bit of time to work on these stories each iteration.

This is clearly the wrong approach for a number of reasons. Your Product Owner needs to be aware of these stories. Some iterations may require more capacity devoted to these stories, and other iterations may not require any technical stories at all. Not accounting for these stories would cause variations in your velocity that make it difficult to plan.

Another approach we tried was just carving out X points each iteration to be devoted to technical stories. This was similar to what we first tried, but at least this way the Product Owner was aware that it was happening and we had a better picture of our velocity. Once again, we found that this approach didn’t work well as the number of points needed for technical stories varies from iteration to iteration. For example, upgrading from Java 1.5 to Java 1.7 probably isn’t going to happen in just 5 points.

After many months of evolving our process we ultimately realized that we just needed these technical stories to be prioritized like any other story. This means that the Product Owner has to understand the benefit of these stories.The development team (or perhaps the Scrum Master) needs to champion these stories and sell them to the Product Owner. It has been my experience that any reasonable Product Owner has no trouble prioritizing these stories.

Going through the prioritization process also has the added benefit of keeping the development team honest. As developers, we have a tendency to want to upgrade to the latest and greatest — but sometimes we need to really think about why and justify taking the time to do it.


Where possible, include technical work as part of a related story rather than making an independent story. Refactor code when you are already modifying code in that part of the application. When technical work warrants its own story, make sure that you prioritize this work with the Product Owner just like any other story. You’ll have a better picture of your velocity and it will help ensure that you only take on work that actually needs to get done.

Communication Without Disruption: A Manager’s Quandary

In the early days of being a Development Manager, I used to make the rounds four to five times a day asking each member of each team: “How are things going? What can I do to help?”.  Sometimes I would get the opportunity to assist, but most of the time the response was something along the lines of “Everything is going well, no help needed”.

My intentions were good and were totally in line with my responsibilities. However, I think it was around the first time that I heard Scott Hanselman’s talk on productivity (see his blog post on the topic) that I really started to realize the cost of these interruptions. Even something as simple as a yes/no question (“Need help?”) can break somebody out of “The Zone”.

It is important that team members get uninterrupted time every day. Part of not interrupting someone is being able to tell when they actually are in The Zone. This isn’t usually rocket science; if you see that someone is really intensely focused, then don’t bug them. If you have trouble telling when someone is in The Zone then work out a signal like wearing headphones, setting something out on their desk, etc. as a visual cue.

Another disruptive but convenient communication technique — and one that I am guilty of overusing myself — is instant messaging. Although we may not realize it, sending someone a message can be almost as disruptive as walking up to them and asking a question. A little blinky window at the bottom of the screen can be enough to break someone’s concentration. A phone call is even worse.

Ok, so how can we communicate with team members without disrupting? That is, how can we communicate without having to worry about breaking people out of The Zone? The most obvious way is to approach someone when they are clearly not in The Zone. What if you don’t have the luxury of sitting right next to the team member? Try email.

Yep. Good old fashioned email. Email is a great way of issuing an asynchronous request that says “hey, when you get a minute I need to talk to you about XYZ”. There are three benefits to this approach. 1) Your team member will likely only be checking their email when they are at a good stopping point. 2) Giving some sort of context as to the topic can allow them to mentally prepare. 3) They can choose to reach out to you when convenient for them.  As Paul Graham’s blog post suggests, a manager’s schedule is more conducive to interruption, so this approach won’t cost you as much time overall.

It takes discipline and patience to avoid disrupting your team(s). I often times struggle with adhering to these ideas myself, but it’s a work in progress.