Tax Software

This company was a large fortune 500 company. Our team was part of an acquisition based in Omaha, NE. Our division employed approximately 75 people overall.

Quarterly Estimated Taxes

This was a newly offered web product that allowed customers to pay their quarterly estimated taxes online.

Slightly Distributed

The team consisted of 1 Product Owner, 1, Scrum Master, 6 developers, 1 BA/UX, 2 QA. 1 developer was located in the San Diego office while the rest of the team was located in Omaha, NE.

Predictability

I became the Scrum Master of the team after the initial release. There were many problems with the production site that caused the following issues:

An extreme number of customer support calls resulting in an high cost for our call center.

The inability to predictably deliver new features to our customers.

The team was spending most of their time working on production support requests and was not able to work on delivering enhanced functionality.

Step 1 – Stabilize the Current System

The team proposed to the Product Owner that we spend a full iteration stabilizing the current application without delivering new functionality. The Product Owner agreed and our team spent the next iteration focusing only on stabilizing the application so it would not crash.

Step 2 – Develop Strategy to Handle Production Support Requests

The team successfully stabilized the application which dramatically reduced our call volume. However, there were still many problems that had to be fixed, meaning that the team had to continue to complete production support items that could not wait until the end of the sprint.

The approach the team took was to dedicate one team member to working only on production support requests. Since many of the requests were simple to fix yet highly valuable to the customers, the team chose a junior developer to work on these support requests with the guidance of the senior developers, freeing up the rest of the team to work on new functionality.

Additionally, instead of working on every production support request in a first in, first out approach, the Product Owner would prioritize each support request, and if possible, slot them into future iterations.

Predictability

The application was stable, and the team was predictably able to deliver new enhancements along with working on production support requests. The significantly reduced costs and improved our ability to deliver.

Regulated Software

This company employed about 400 people, split into two divisions. The division in this case study consisted of about 75-100 people.

Local Deployments

This was an application which was installed at local governmental jurisdiction offices. All installations required an implementation team to travel to the location to deploy the application. Once deployed, the application could be upgraded and maintained for the most part. There were some locations where this was not possible due to the lack of available infrastructure.

Distributed Team

The team consisted of 4 developers, 1 Product Owner/BA, 2 QA, and 1 Scrum Master. 2 of the developers and the Product Owner/BA were in remote locations.

Missed Deadlines & Lack of Prioritization

The two primary problems this team was experiencing were:

Contractually obligated deadlines for functionality were being missed resulting in potential litigation or contract cancellation. The team could not determine whether the deliverables would be missed until it was far too late to renegotiate contracts.

A steady stream of critical production support requests were being submitted not allowing the team to work on features that were required to be delivered under contract. The team was at approximately 75% capacity working only on break/fix items.

The team was working on all work items as they came in without determining whether they “should” be working on them at that moment. There was far too much work in progress that consisted of items that were either “nice to haves” or items that could have completed at a future date.

Step 1 – Team Retrospective

With any Agile process, one of the most valuable things is to get feedback from the team.  Since they are the ones on the front line, they will have the best ideas as far as how to improve the overall process.  The team introduced many improvement items that could be implemented such as:

1. Improved remote collaboration tools.
2. Spend more time face-to-face as a team, including the remote team members.
3. More collaboration with the Product Owner.
4. Greater team visibility into the overall goals of the project.
5. Greater team visibility into contractual obligations.
6. Prioritization of the work to be accomplished.

Step 2 – Release Planning

To provide a timeline and visibility into the work, the team went through a multi-day release planning exercise.  This provided us with a prioritized list of requirements that needed to be accomplished, along with the effort required to deliver each requirement.

This provided us the ability to determine a realistic timeline, given the current capacity for new feature requests (approximately 50%) and constraints (limited overtime, no additional head-count, tight budget), as to when the requirements could be delivered.  After the release planning session, leadership had the information needed far in advance of deadlines to be able to renegotiate deadlines and deliverables with the clients.

Priortization & Work Flow

With the Release Plan, the requirements (along with production support requests) were prioritized by contractual impact.  This gave the team visibility into what the most important items to focus on were, along with the ability to de-prioritize non-critical items that came to the team.

A step forward was also made by assigning the bulk of the production support requests to a different team.  While the current team still had to include production support items in their development cycle, the majority of the effort was accomplished by the other team.

Let’s Talk Today