Scrum and the Customer

Agile Development /Scrum is a great process for many reasons some of which are indirect and not really apparent when you are reading about the process and considering implementing it into your own organization. One of these indirect benefits is the forced improvement in customer management, especially in the area of customer expectations.





In many development shops the urge to make the high profile, or in some cases the high maintenance customer happy side tracks development cycles and introduces schedule risk that are hard if not impossible to audit in the post mortem for the project. Product Managers/Product Owners are quick to point out the product shipped 4 weeks late but exhibit a surprisingly short memory about events that caused the schedule to slip. Pulling off an engineer to fix a bug and deploy it for a customer for 1/2 a day adds up. It also derails the performance of that engineer in the development cycle. A good rule of thumb is take the amount of time the engineer was derailed and multiply it by 4, this is the real cost of the bug fix not the actual time it took to fix the bug and deploy it for the customer. It might be smart to build this into the estimate to fix the bug, quoting 2 days to fix the bug rather than 1/2 a day may cause the bug to be deferred until the next development cycle, which is probably what should happen in most cases.




The factor of 4 takes into account the engineers intensity in the development cycle, let's call it in "the zone" level of performance that produces optimal efficiency and quality for the engineers work. When this is derailed it takes time for the engineer to get back to where they were and back into "the zone". In development shops where this is common practice, schedules are rarely met as the estimates that made up those schedules didn't include the interruptions. It's also important to consider the issue of the ROI of fixing the bug. Now in the case you have 2 customers the math is easy, losing 50% of your customer base makes the case a 'no-brainer'. In the case where you have 2000 customers, fixing the bug and derailing the development cycle for the 1999 customers who haven't complained about it doesn't make sense.


So how does Scrum force the improvement of customer management. One of the immutable laws of Scrum and one that becomes apparent to all the stakeholders, product owners included is that you never, ever, interrupt a Sprint.





The nature of Scrum is full body contact. Everyone involved in the Scrum is fully involved, including the Product Owner. He has ranked the Product Backlog Items to make sure the most important items are considered in the planning meeting first. He is involved in the planning meeting so he understands which items made it into the Sprint and why others couldn't be included because of effort and time constraints on the Sprint. He can understand that it may take a few more Sprints before the full feature is complete. But he is also comforted by the knowledge that he may chose to forgo some of the later Sprints containing the lower ranked Product Backlog Items so he can ship the feature earlier. That's because of another immutable law of Scrum at the end of every Sprint the Product is shippable.


So a pleasant side effect of Scrum is that the Product Owner is forced to manage the customer, rather than the other way around. If a customer calls with a bug or enhancement request, rather than hang up the phone and walk into the Software Engineering Managers office to request work start right away, the Product Owner manages the customer and informs them that it will be a high priority for the next planning session but it can't be addressed immediately. Even then the Product Owner may not commit to a date because he is mindful of taking away time in the next Sprint that could be used to implement his next stack of Product Backlog Items.


By managing the customer, the Product Owner improves the efficiency of the machine producing his product, getting features and other enhancements out faster. This can be a win for the customer as well, by managing the customer expectations they are satisfied they have been heard, they have been told it will be given priority and worked into the development schedule, and they will be pleased to see new features and enhancements coming out in the application faster than they were before.

Scrum it's not a Fish it's a process.

Our Best Practice du jour is Scrum lightly sauteed served over a bed of TFS.





So Scrum isn't a fish, it's actually a very British term describing a disordered or confused situation involving a number of people. And this is a pretty accurate description of what Scrum looks and feels like when you first get started. But after some practice you will realize that Scrum is actually an elixir for itself, Scrum actually brings order and clarity into situations involving teams.

Scrum succeeds where other development methodologies fail because it is light weight yet rigid. Scrum defines a set of simple, common sense phases and ensures each phase is successful by declaring immutable laws for each phase.

Scrum is an Agile process that forces teams to continuously realign their projects to deliver a shipping product that has been enhanced with real business value in a pre-determined period of time. If you read this too fast it comes out sounding like a fancy way of saying they meet their estimated schedule, but the key is the word realign, the team realigns itself not to just meet the schedule but to meet the schedule with as much real business value as possible. And this is where Scrum gets very interesting for the non-technical business leaders.


In software development projects it's pretty common for features and functionality to be jettisoned in order to meet the schedule. The problem with most development projects is that the scope is defined by the release which can contain many features. The project gets loaded up with features at the start.


It's like ballast in the big old sail boats of long ago, sailors would load up the big boats with extra weight (usually rocks) to weigh down the boat in the water, this made it ride through the water at the optimal depth. The rocks for a development project are the features, and the optimal weight is what product owners perceive as real business value.



Ballast in the big old sail boats became a problem at the end of the journey, usually at the ports of call. The ports were generally shallow and required the ship to ride higher in the water or else get stuck on the bottom. So the ballast would be discarded to reduce the draft of the boat and enable it to sail in safely.


Right before a project docks for shipment it's usually obvious its riding too low in the water, it's going to bottom out before it makes it to port, so Ballast (features) is jettisoned, usually in no particular order, to reduce the projects draft so it can make it to port (shipment).

So how does SCRUM address this problem. Before the planning of a software project SCRUM dictates that the Product Owner creates a Product Backlog, a list of all the things the Product Owner feels are important to get into the product to increase the value proposition to the customer. These are called Product Backlog Items or PBI's. Before the planning meeting the Product Owner must rank these backlog items, ensuring those with the highest business value are done first.

The development team than assigns a weight (related to effort) to each PBI based on previous experience with similar items. After a certain total weight is achieved the Sprint is full. A Sprint is basically a development cycle post planning phase to shipment. Sprints are defined by a total weight, or level of effort that cannot exceed a certain short time period, usually 30 days. Not all PBI's in the backlog will make it into the Sprint. They may be deferred to following Sprints. And a large feature may be split across several Sprints.

The planning activity of generating PBI's and ranking them based on business value, and the selection of a set of PBI's to fill a Sprint, increases the success of the project or Sprint. What is basically happening is the Product Owner is very carefully selecting what ballast needs to go into the ship before it is launched, with the understanding that it won't be jettisoned before making port. It won't be jettisoned because the development team is carefully considering each PBI and weighting it based on previous experience and than only signing up for a Sprint's worth of weight, not a monolithic projects worth of weight. Margin of error is restricted to the Sprint and not multiplied by the number of Sprints it may take to complete a larger feature much less a shipping version.

It is also important to note that another immutable rule of Scrum is at the end of each Sprint the product must be in a shippable condition. So if a feature is being added that spans multiple Sprints the Product Owner has the flexibility of deciding whether to ship the partially completed feature, and wait on the remaining enhancements for a subsequent release. Or it may be that the PBI's for a feature that didn't make it in were not that important and the Product Owner is good with shipping what they have.

Once a set of PBI's are assigned to a Sprint the development team than reduces each PBI into Tasks. These tasks become the Sprint backlog, which is basically an execution plan for the development team. Eash task is assigned an estimate of effort by the developer who owns it. The percent completed is updated daily and reported at a daily meeting called a Scrum. This data also becomes available if you are using an environment like Microsoft's Team Foundation Server to produce burn down charts so everyone can see if the ship is going to make it into port.

In conclusion, I'll reiterate that Scrum succeeds where other development methodologies fail because it is light weight yet rigid. There aren't many of rules but the rules that are defined in Scrum make it a successful process on large or small projects. We have used Scrum successfully for more than 6 months now, across multiple product lines. It is a full contact development process with everyone at the table and engaged and aware.