Improving Results Through Understanding the Requirements

September 28, 2009

As I mentioned in Those Satisfying Moments, I took up the charge of being a coach for one of our Agile/Scrum teams that was struggling. This team went from being challenged and working overtime to kicking butt, no overtime required! This post covers some simple changes that allowed this to happen.

My first day spent with the team involved a backlog review. The goal was to review the product backlog and re-evaluate the story points that had already been estimated once before by the team. (Story points are relative units of size for those who are not used to the agile vernacular.) Once this was complete we could use the team’s prior velocity determine what the release date could and should be – versus what some of us had in our heads as a release date.

As I sat with the team to review the backlog, Problem #1 immediately surfaced. The Product Owner pulled up a spreadsheet on the large screen that contained the backlog in priority order, with story points assigned. I hadn’t seen this spreadsheet prior to the meeting, but I was the only one in the room who hadn’t.

The team needed to review the items on the spreadsheet, validate or change their story points based on a (presumably) better understanding of what needed to be built because they had been building portions of the system already, and then determine their target end date. It seemed simple enough, until I started looking at the spreadsheet in detail.

I was having a difficult time comprehending what I was looking at. I listened while the team began to discuss the backlog, but part of my brain was occupied with the backlog itself. The team didn’t seem that engaged in the review, either. It only took me a brief amount of time to figure this situation out.

The backlog was a mix of user stories, which are supposed to be simple way of capturing what users want out of the software, and some very specific tasks. And some of those tasks were thoughts about how a one large user story could be handled. Stop right there!

(In fairness, we had experienced a change in Product Owners, so this spreadsheet was a mix of what a prior Product Owner had provided and the new Product Owner what the new Product Owner was still getting up to speed on.)

I made my observation to the team and suggested that we begin with just user stories, leveraging the information contained in the spreadsheet, but clarifying what the users wanted and needed in a way that was understandable to everyone. I got up on the white board and we began crafting user stories with the Product Owner, in front of the entire team.

Some stories were carried over from the spreadsheet. As I mentioned, other stories were tasks, not stories. From my standpoint, I wanted the team to feel committed, to have a sense of ownership. And in order for that to happen, the team needed to understand what we wanted them to accomplish.

As we crafted the user stories, a greater sense of the needs of the customer emerged, in my mind and in the minds of everyone on the team. Two important developments subsequently occurred.

The first involved a user story around reporting needs. Once we took a closer look, there was no real definition provided. Product Owner, that one is yours.

The next one involved working backwards and exploring what some of those tasks in the spreadsheet were designed to achieve. As we discussed the business process and condensed the tasks into a couple of user stories, one developer spoke up and said, “It seems like we’re making the user go through a lot of manual steps.”

This prompted something in the back of another developer’s mind and he said, “How about combining some of these steps and automatically generating the end statement, by-passing the manual, intermediate steps?”

Cha-ching! Now we have a better solution! If we had estimated, built, and tested the solution as presented, we would have missed a significant opportunity for collaboration and a meeting of the minds between the business representatives and the developers to produce an optimal solution. We entered that “ah-ha” zone:


Overall, this planning session helped to tighten up and clarify the requirements, improved the collaboration between the Product Owner and the rest of the team, and provided the customer with a better solution than what had been previously considered.

Everyone involved now had a greater insight on what needed to be achieved, and because of their participation they now had a greater stake in the solution. This alone paid motivation dividends, but there was more.

The conclusion in a couple of days…

Those Satisfying Moments

September 26, 2009


Like everyone else, I have my good days and my bad days. I always need to remind myself that psychologically, we all need to celebrate even the little victories that occur in our lives.

As a manager, there are times when my day is absolutely made. Like having someone that excels at something, such as being super responsive to a critical customer issue that merits a spot award (we do these as publicly as possible). Or when someone has really raised their game and I am able to provide a large merit increase or promotion.

Having your day made is sometimes a work in progress, one that starts with dealing with “issues.” Recently, we’ve had some challenges with our implementation of agile/scrum development. Two teams in particular were working on a critical product release, but the teams were clearly struggling with meeting their own commitments – they estimated the work, but each 3-week sprint always ended up leaving us stakeholders holding our collective breaths. Would they make it?

It was never certain if the teams were going to meet their own commitments; and if they did, they were working overtime to do it. Something was wrong with this picture. Even as managers who weren’t on the teams, we could tell that certain things were lacking.

Despite the fact that we had previously brought in an agile coach and that we never refused the purchase of any books on agile or software development, it was determined that we needed coaching for these two teams. Budgets and politics being what they are – particularly in this tight economy – it was determined that to designate a couple of us development managers as coaches versus spending money that we didn’t have set aside in our budget.

Within a span of weeks, the team that I was coaching went from being challenged in meeting their commitments and working overtime to do it to beating their commitments, taking on additional tasks, and working regular hours! And no, their original estimates were not modified. They simply started working better as a team. Talk about one of those “Yes!” moments!

What changed for this team? I’ll post that in a couple days…

Understanding the Customer’s Requirements

September 18, 2009

My last post, “What is the Real Problem?” discussed a simple, but real-world example of why understanding the true requirements of software is so important in achieving results . Too often, the pressure to “be responsive” to the customer translates into programming action – coding – before anyone should be writing code.

Industry gurus Steve McConnell and Karl Wiegers have articulated two statistics that are vitally important:
  • Requirements defects in software projects account for approximately 50% of product defects.

  • The percentage of the re-work on software projects due to requirements defects is greater than 50%.
Re-working software is obviously an expensive and time-wasting proposition, and it will significantly extend a project schedule. This slip in turn impacts the business’ ability to utilize the software to generate revenue or to improve productivity.

Given that requirements have a major impact on project schedules and the ultimate value provided to the customer as a result of using the software, it is in everyone’s best interest to get the requirements right. This requires discipline and thought from both the business users and the software development team.

Software development is a meeting of the minds. The business must provide the right resources – those who understand what the business needs and is capable of articulating those needs – and the software team must make every effort to understand what the business needs. And this means more than just accepting a bullet list of requirements. The requirements should be explored.

Software developers confuses the situation through the use of metaphors that lead to misunderstandings. We “design” and “construct” software, analogous to building a house. Unfortunately, software development is not just like building a house. A house is physical and has specific characteristics. When you want a 3-bedroom house with 2 bathrooms, you can easily lay the house out on a blueprint. Software doesn’t blueprint that easily.

Unlike a house, software behaves – unless you are Bill Gates, who expects paintings to change to his personal preference when he walks into a room. When you walk into a room in your house, you don’t expect anything to happen, do you? (Except for those times when you are interacting with that special someone, but you are expecting them to react, not the house…)

When users interact with software, they expect certain things to happen. “When I select this item from the list, I expect a certain set of choices with other items on the screen,” or “When I click Submit, I expect to get a quote back for my auto insurance.”

Software has rules that govern what can and can’t be done, as well as formulas and algorithms. Software chooses to take a user down one path or another based on the rules, formulas, and calculations that it performs.

This means that requirements need to be more than simple statements about a need. Many times, the customer (users) – those who don’t understand software development because they aren’t software developers – will state what they think that they need. Too often that need is centered around an immediate need, and if taken literally without examining the true goals of the user, you will design and a narrowly-focused feature that will need work and ajustment later.

Since users don’t understand what it takes to translate business operations into working code, those on the software side need to engage the customer in an appropriate dialog to understand more fully what the users are trying to accomplish. This conversation with the customer will take more time, but if you approach it from the standpoint of understanding what the customer truly needs the software to do, and engage them in a discussion about how they expect to interact with the software, the software team will gain a greater insight to what needs to be built and what will be deemed both correct and successful from the customer’s point of view.

Most users are not good at abstraction. Their perspective of software is geared towards what they see – the user interface. Use their perspective and language when discussing how software will behave by using screen mock-ups (paper prototypes or functional prototypes). But get at the underlying behavior the software needs to perform.

To do this successfully, be like a young child that is going through that “‘cause why” stage. Ask why until it hurts! Keep in mind that understanding the true business goals can help craft a better solution. A meeting of the minds also means that those on the technology side can offer up solutions to business problems that might not have occurred to the business.

For example, the business may approach a software team with the concept of automatically inputting customer data received via e-mail. The software team may take a look and determine that it is faster and easier to import the data through an already established collection point elsewhere, and that the e-mailing of this data was done to accommodate a gap in the existing software that can now be addressed.

We've also used the technique of developing personas. A persona is a fictitious representation of one or more uses of the software, but a detailed one that provides a solid, working example of an example user. A persona helps the development team keep the business goals and users in mind, and can be a great way to remind developers how the design and development of the software relates back to those that they are building the software for – without constantly engaging them in conversations. Granted, there still needs to be on on-going dialog, but a good set of personas can help limit some of need for input by the business side of the house – a win for everyone.

We’ve adopted the Agile development methodology, which captures requirements in the form of user stories. These are a simple, but effective means of capturing what users want out of the software. A basic template for writing user stories is as follows:

As a [user role], I can [software feature] so that [business reason].


I won’t elaborate on writing requirements or user stories here, but I will provide some references.

A couple of links to writing user stories:

The Easy Way to Writing Good User Stories

ExtremePlanner: Agile Project Management for Distributed Software Teams

Two books that I highly recommend:

User Stories Applied: For Agile Software Development by Mike Cohn

Software Requirements, Second Edition by Karl Wiegers

What is the Real Problem?

September 12, 2009

My life as a manager involves me with a variety of meetings and conversations every day. I hold regular one-on-ones with my direct reports, attend project meetings, management meetings, customer calls, along with engaging in conversations or meetings that are geared towards moving something forward on some front. Someone always wants to know when something will be done, who is available to work on a critical problem or new project, or to discuss overcoming an obstacle.

A major part of defining direction is to understand the problem at hand, and sometimes this means probing a little, even if the problem appears to be obvious. One example that I was faced with recently was a customer request for a report. The customer presented a 30+ page document that described the data required and the format that the data needed to be in to allow it to be sent electronically to another party, among other things.

The document was presented to me at a meeting – which started late due to other pressing issues – along with the following statement: “The customer needs this to run automatically. I know that everyone is already booked, but is this something that you can do, and if so, how quickly can you do this?”

I looked through the first few pages of the document while I asked for the background on the request. I then began poking at the particulars.

“What do they mean by automated?” I asked.

“I’m not sure,” was the response.

"Is the database configured to hold the 18 fields that are being asked for in the output?”

"Yes.”

“Well,” I said, “this seems like a simple request and a slam-dunk.”

But the fact that it seemed so easy also bothered me. I knew that the customer had in-house database personnel, so I really was curious as to why they were asking us to perform this seemingly simple task, especially since we would charge them for our time.

“Are they generating this report today?” I asked, immediately following with, “And why are they asking us to do this? Does their request have something to do with their desire for this to be automated?”

Our customer liaison indicated that the customer was in fact generating the report already through a third-party reporting tool.

My response was that while this seemed simple enough, we needed to clarify just what the customer specifically desired before providing a cost estimate. I could easily see how we could accomplish the request, but we would likely be providing the customer a solution that was “the same thing, only different” from what they already possessed – as a billable exercise. I was sure that this would not please the customer.

We had two valuable clues that pointed towards a clarifying conversation with the customer:
  • We didn’t understand the “automation” portion of the request.

  • We understood that the customer was generating this report today, but we didn’t understand what was inadequate about it. Perhaps all that we needed to do was assist them in automating what they already had available.
In this case, the quality of the solution – from the customer’s perspective – would be directly proportional to the quality of the description of the problem. The key to getting at the real crux of the customer’s desire was to keep asking why, and not stopping until the customer’s perspective – and true goal – was articulated. We needed to dig deeper, moving past the literal wording of the request to gain an understanding just what the customer wanted to accomplish.

For a quick guide to problem-solving, have a look at How to Define a Problem, an article that I found on wikiHow. As the article points out, the most important step in solving a problem is clearly defining the problem in the first place.

Is it a Defect or an Enhancement?

September 4, 2009

In their book The Art of Agile Development, James Shore and Shane Warden discuss the “bug blame game,” where a programmer responds to issue of a bug being found by retorting, “That’s not a bug. It’s a feature!” James and Shane note that there are those who have taken the definition of a bug to extraordinary heights, classifying bugs as defects, faults, errors, issues, anomalies, and unintentional features.

I’ve encountered another variation on this theme, and usually surfaces in an unproductive argument between business and development. It starts innocently enough, and begins with a query to development to “see what the code is doing” in response to some action a user is taking.

Translation: The software is behaving in a way that someone does not expect, and they want to confirm that behavior – although it is clear that they don’t like that behavior. Often times, there is an unstated hope that “looking at the code” will reveal some other option that will enable the business to perform the desired behavior.

When a programmer examines the code with respect to the issue being described, often times the report is what initiates the combative portion of the conversation, “Functions as designed!” the programmer responds.

This is when the business side grits their teeth – they’ve just heard that the software isn’t doing what they wanted it to do, and now they are hearing a phrase that leads them to believe that programmers are delighted about confirming that the software isn’t working correctly.

What is going on? Why would a programmer appear delighted?

The programmer’s point of view in this scenario is very different. The programmer was approached with a concern – there was uncertainty about how the software is functioning in a given situation. The programmer feels glad to have researched and found the "answer," that the software wasn’t designed to perform as the business user described. In the programmer’s mind, the issue is now crystal clear.

The business user, however, is disappointed. The business user responds by saying, “Well, the software should be doing X, and because it isn’t, it is a defect.”

The battle lines between business and development are drawn. Unless someone is around who recognizes what is going on and can interject themselves appropriately, a useless argument about whether the issue at hand is a defect or enhancement is about to take place. The business user will continually assert that because the software isn’t doing what is expected, it is a defect. The programmer will retort that because the software was never designed to operate in the way the business described, the requested functionality is really an enhancement.

The heart of the matter is less about the nature of the problem and more about effort required to resolve the problem.

From a programmer’s standpoint a defect means that there is a problem with how the software is operating – it performing an operation that it was intended to do, but it is failing to do so in some specific way. There is an adjustment that needs to be made, but it doesn’t violate the overall design and intended behavior that is already represented in the code.

An enhancement means something else entirely to a programmer. There is behavior that must be understood and agreed upon, and that behavior must not contradict behavior that is already present in the software. That behavior must then be designed, coded, and tested – along with tests to ensure that other, related functionality is not impacted.

From a programmer’s point of view, a defect is much easier to resolve than an enhancement. Since business users are not programmers, it is best that someone on the development side of the house explain what needs to come next, and why; it turns what could be an adversarial situation into a partnership where both parties understand and agree on the problem what it will take to resolve the problem.