I was working late. Really late. It was around 9:30 p.m. and only a couple of people were left in the office. I had just been transferred to a failing project and was trying to salvage what I could from the work that had been done.
The guy who had been working on it for the last three weeks went crazy and then got sick, or maybe got sick and went crazy, or both simultaneously.
To be fair, it was a really complex project. It aggregated sports data from various APIs, had a social component with a Facebook app, and required near real-time alerting and data sharing. I didn’t blame the other guy for locking himself in an office. The API for the sports data was so abstracted you needed a degree in Latin to make sense of the class names.
At the time I thought I could save the project by finishing it. I didn’t realize it then, but what would have saved the project was stopping, not finishing.
The client had built a few similar apps and was expanding on their earlier success. This project was bigger than what they had done in the past. A lot bigger. But that was okay. They were following the same formula as before. Build it out, market it like crazy, and boom, success.
I was focused on delivering code when I should have been focused on delivering value.
Eventually, the project launched. I moved on to another project. The client did the same. At the end of the day I wouldn’t exactly mark the project’s
FinalizedEventOutcome as positive. In other words, we didn’t win that game.
When a team is focused on delivering value, they solve problems differently. They approach the work with a different outlook. And they seize the opportunity to do less work for the same result.
Being focused on value during planning means the team delivers value, not code.
When I’m focusing on value, I seek to understand the following:
They were proud of the implementation. The views they created beautifully displayed all the data. You could search, sort, and filter too. It even progressively loaded the page with fancy animations sprinkled on the page.
It took the team two sprints to finish the work, but it was some of their best work. They reviewed it with a designer and fixed some usability issues. It had a suite of automated tests. They even added browser-based tests using Selenium.
Effective planning focuses on adding value for the people using the software
So, you can imagine the look on their face when their customer, an internal business analyst named April, asked how she could get a CSV export for last month.
“A CSV export? What for?” asked a Catarina, one of the developers.
“Well I need to load it into Excel, so I can do all of my calculations,” replied April.
“Your calculations?” inquired Catarina, perplexed.
“Right. See I take the data from last month, I load it into the Excel spreadsheet that Jerry created over the years and it spits out some other data, which I put into a different spreadsheet, I think Jerry made that one too, and anyway, once I have that…” she continued with a lengthly explanation of her process.
All eyes shifted to the product owner, Lamar.
“If only there was some way we could have found out about this earlier,” someone mumbled sarcastically.
“Thanks for the feedback, we’ll get started on the CSV export and let you know when it’s ready,” the scrum master said diplomatically.
Effective planning focuses on adding value for the people using the software. Before we can add value, we have to understand what’s valuable. To understand what’s valuable we talk with the people who are using (or buying) what we’re building.
This role is sometimes reserved for the product organization. “We can’t have developers talking to customers!” or so the thinking goes.
But this lack of direct access to the customer is detrimental to the team. We can’t deliver value if we don’t know what’s valuable.
In the example above, the team did not understand enough about a day in the life of April, the business analyst. They were unclear about how and why she was using the software and missed the value she received from exporting the report.
In this case, a simple conversation would have uncovered this hidden process April performed with the export. Another good technique is just simple observation, watching the end user use the software. More advanced techniques can be found in a framework like Anthony Ulwick’s “Jobs to Be Done” framework described in his book Jobs to be Done: Theory to Practice.1
Deeply understanding the customer and their world is key to delivering value with our work. When we know how they work, what problems they have, what frustrates them, and what delights them, we can plan to deliver value.
A great way to ensure you’re focusing on what’s really valuable is to define, up front, how you will measure the success of the work. This exercise usually uncovers two things. First, that there isn’t a clear understanding of how to measure the outcome of the work. Second, that the team’s idea of success is divorced from the needs of the user.
By specifically defining success, we can help focus the team’s effort on reaching that goal. In the example above, the team’s measure of success was a new report, better test suite, and better usability. April’s measure of success was easier and faster access to the exported report.
During planning, I like to ask myself the following:
The team had already spent a couple of weeks gathering requirements and designing an architecture when I arrived. They had been tasked with adapting an existing product for new markets in Europe. This product had been around for years, and these guys had spent a lot of time on it.
Judging by the proposed architecture, they didn’t like the current system. In fact, they wanted to completely rewrite it. This proposal was being pushed by the most vocal of the three, Erik.
Effective planning focuses on building the simplest thing that could possibly work
Erik spun around is his chair to face me. “You know what a state machine is, right?” he asked.
“Yes, I am familiar with state machines. Is that the proposed architecture?” I replied.
The quiet but opinionated member of the team, Bryce, interrupted. “He’s just trying to do some fancy thing he read in a book, so he can get promoted.”
The other member of the three-developer team, Todd, laughed.
“Whatever, dude. I talked to the architects, and they agreed with me,” said Erik.
I was hoping to avoid wasting more time. “Do either of you have a better idea for the architecture?” I asked Bryce and Todd.
“Yes!” they said almost simultaneously.
Bryce stood up and went to the whiteboard. He proceeded to map out the existing components of the system, explained how they were connected, and circled two of the five.
“All we need to do is extract the language files out into a separate component. If we decouple that, we can just translate and localize, and we don’t have to touch the rest of it. It already works,” Bryce said confidently, spinning the marker in his hand.
Erik was visibly frustrated. “The whole thing is a huge mess, if we try to pull out the language files, who knows what will go wrong!?” he said in frustration, “I’m telling you guys, if we just use a state machine, it will be more stable.”
“I’m going for a smoke break,” said Bryce.
“I’ll join you,” said Todd as they headed for the elevator.
Effective planning focuses on building the simplest thing that could possibly work 2. This deceptively, simple, question from Extreme Programming Explained hits on a key aspect of how we plan our work.
It’s not so much what we plan to do, but what we can avoid planning at all. What could we avoid building? What could we avoid designing, testing, documenting, and maintaining?
Imagine all the effort we can avoid expending if we just “keep it simple stupid.”
I’ve seen many sprints fail because someone on the team decided that it was a good idea to experiment with a new technology, design pattern, or third-party library. Yes, sometimes we need to try something new to deliver the outcomes we seek. When this is the case everyone on the team, including stakeholders, should be made aware of the risks involved.
I’m a huge advocate for learning and experimenting, and encourage developers to first spend their own time becoming effective before bringing new concepts to the team. When there is a known pattern, existing tool, or familiar concept already being used in the system, we should first reach for that before experimenting with the new and interesting.
During planning I like to ask myself the following:
To end this discussion on simplicity, I’ll reiterate that idea creating something simple is very difficult. It’s much easier to make a complex ball of mud. We all do that without even trying.
There were about twenty people in the big conference room. The small talk had run dry and one of the product owners had moved on to their presentation. It was a project plan mapping out the work to be done in the next quarter. Sprint by sprint, the product owner told a compelling story.
First they would build out the core architecture, then the APIs required to connect to the existing system, next they would move on to the services layer, after that they could start the foundations of the user interface, with that in place they could bring in a designer.
The last two sprints were just finishing touches. Then it was time to launch.
The presentation came to an end, the product owner fielded a few questions from the audience, and we moved on to the next topic.
After the meeting, I was approached by the VP of product, Oliver.
“What’d you think of the plan for next quarter, pretty good, eh!” he exclaimed.
“Well, I’m afraid you’re going to spend the next two and a half months without shipping a full slice,” I said expressing my concern.
Puzzled he laughed and asked, “a full slice? Like pie?”
“Not pie. Like a cheeseburger, I’ll explain on the way back to your office,” I said as we started down the hallway.
Effective planning focuses on delivering a complete slice of value for the customer
While the idea of “slicing” features was pretty commonplace in the SCRUM community at the time, I had always heard of it using cake as the metaphoric food of choice.
It wasn’t until I read Gojko Adzic’s article3 on splitting user stories that I realized his hamburger metaphor was far superior.
Using Adzic’s example, I explained to the VP that if I gave him a slice of tomato, a little piece of lettuce, and half of a bun he might assume I was serving a terrible tomato sandwich.
If I instead gave him a bit each of bun, lettuce, patty, cheese, tomato, ketchup, mustard, and pickle. He could eat that bite and know exactly what it was. A cheeseburger.
The small slice might not be enough to satisfy our customer’s “appetite,” but it is enough to find out what they don’t like, what they might prefer, or what we might not even know to ask.
Not only can we learn a lot about the value we’re adding with this approach, it can also be the basis for negotiation with the business.
Is the work too much for the team to complete in the iteration? Perhaps we can create a “thinner” slice. Is there some threshold until which the customer experiences no value, then suddenly does? Let’s make the slice a bit “thicker” to cross that line.
When there is uncertainty about the work, find a thinner slice and get feedback on that before proceeding.
It takes a lot of experience to know how and where to strategically “cut corners” with our work. But, when trying to achieve a thinner slice of value through the entire stack, we have to make tradeoffs.
In some systems, a simplistic user interface might be acceptable for a first version of a story. It doesn’t look great, but it works, and we can enhance it later if this feature delivers the value we expect. In other systems, we might avoid making the feature as performant as it could be, in an effort to find that thinner slice. Perhaps we limit the full capabilities of a feature to just one or two core concepts before building out the entire thing.
No matter the system, there are ways to creatively slice the work such that we deliver more value and faster. Understand and agree on what’s acceptable to “cut out” and you will find it easier to work iteratively instead of incrementally.
Effective planning focuses on delivering a complete slice of value for the customer. Instead of splitting work along technological boundaries, we slice through these boundaries. We slice the work like this in order to:
Decomposing work into smaller pieces is one of the more challenging activities in software development. But when faced with work that’s too big to fit in the iteration, it’s the only responsible choice.
During planning I like to ask myself the following:
Delivering value to the customer is our primary responsibility. It’s easy to think we’re making progress by delivering code. But real progress comes from delivering value.
Being focused on value means understanding what our customers find valuable, building features that add that value, and frequently shipping small batches of work.
Effective planning focuses on: