Client Success Stories

Case Studies of our Clients

JPMorgan Chase Transitions to Lean-Agile

Northwestern Mutual Case Study by Scaled Agile Inc and another by us.


Articles by Net Objectives' Clients

We've been helping companies become successful for over a decade! Here are some articles and seminars from our clients describing how we've helped them.


Call Outs by Our Clients

Getty Images discusses their product management transformation in The Value of Co-Creation

Case Studies from our Lean-Agile Coaches

During our courses and coaching engagements, we have had some “aha” moments that have given us significantly deeper insights into Lean-Agile thinking. This section offers a few of our choice insights in the hope that they will help you, too. These case studies highlight the reasons for selecting Net Objectives to help you maximize the business value returned from your software development and maintenance.

Focusing on One Project at a Time

Company profile: Develops software used by insurance companies

Challenges: Lots of projects, sometimes little clarity on requirements, looming deadlines, overworked development team

Insight: One software development director said, “I have two projects. One is for a key client who knows what they want and the enhancements we are working on will make a big difference to them. The other client is not as big, but more importantly, aren’t as clear about what they want. I see that instead of having my team working on both at the same time, I should have them work on the project for the client who has clarity, but keep the work focused on the Minimum Marketable Features so I will get it done quickly. In the meantime, we can be having our product managers talk to the other client and attempt to get better clarity. Then we can focus on them. At the least we’ll get value to our more important client quicker while being more efficient.”

Initiating Fewer Projects Instead of Imploring Teams to Work Better

Company profile: Health Insurance Company

Challenges: Lots of projects, non-co-located, non-matrixed teams

Insight: After a presentation on Lean’s view of software development as fast-flexible-flow and underscoring the waste of pushing too many products through the development pipeline, a vice president of the company present declared, “Oh, I see, I should be giving my development teams fewer things to be working on instead of imploring them to work harder.”


Shortening Batch Times

Company profile: Large software development company

Challenges: Lots of bugs with long cycle times to fix

Insight: The truly Lean approach would is to get to the root cause of the bugs. Two directors were trying to figure out how to address and prioritize the great number of bugs facing them. Doing a root cause on all of them felt overwhelming. They realized that if all they did was work in three month batches instead of six month batches, they would get many more high-prioritized bugs fixed. While not getting to root cause, improvement was available by simply changing batch size. Sometimes it’s worth getting what you can get when that is virtually free.

Getting to the Root Cause

Group profile: Member of a support group for a large IT organization

Challenges: Lots of internal customer calls

Insight: After understanding that more problems are of a systemic nature than of the person using the system, one member of the team re-considered how they were doing support. Instead of just answering questions, he started asking, “What is the root cause of this question?” Since he was not able to change the computer system that the users were having troubles with, he answered the question in terms of the support system that was available to the users to get their questions answered. He realized that he could improve the support system by getting to the root cause of why manual intervention was required. After one year of doing this and improving the automated support, he found it took one-half the time to handle twice the number of users – a fourfold increase in value add by his group.

Knowing Where You Are: Minimum Releasable Features

Group profile: Makes administrative software used by large healthcare organizations

Challenges: After committing to deliver a large program (two-plus years, US$ 5 million), the organization could was not confident on their progress after five months

Insight: The organization was focused only on the end date, which was two years away. There was no sense of priority for any of the work that was underway, as it “all had to be done”. Without this priority (sequence of business features), the teams had no control over how much work was started, and no visible work was being completed. Once the organization came together and visibly sequenced features that were committed to, the teams began to utilize iterations to deliver the features one by one. The key insight gained by the organization was that by working this way, they did NOT have to wait until the far off date to release. Instead, they prioritized and sequenced the features so that smaller releases could begin, which allowed them to keep key customers happy without having to wait two years to deliver the program.

Priorities and Work-in-Process

Group profile: Creates reporting software used by large healthcare organizations

Challenges: Integrating across functional areas and technical debt

Insight: After struggling with integrating different functional areas, the organization was seeing the waste due to delays. This was being manifest by the large number of defects that were discovered toward the end of their lifecycle, which did not integrate and test until it was too late to do anything accept manage the bugs that were being found too an acceptable level of technical debt (classic thrashing). The group’s next release was organized into a Lean Portfolio of prioritized features, and Agile release planning was undertaken. The organization got huge insight when they discovered that the only work-in-process was the lowest priority features as defined by the product management team.  The functional silos were reorganized into cross-functional teams, and much shorter cycles of integration were achieved. For the first time, this organization was able to fully regression test and get a completed User Acceptance Test cycle prior to releasing to their clients.

Productivity and Quality

Group profile: Administrative Software for large enterprise Storage Array Networks

Challenges: Seeking productivity and quality gains in releases that had to deliver features into a complex matrix of different OS’s, DB’s and hardware environments

Insight: After re-organizing into cross functional teams that pulled work from a well-managed Product Portfolio, the teams began to focus on incremental completion of features in order defined by the User’s view of the system (Administrator). The product team could easily validate specific flows for their clients and give the teams quick feedback. With 10-day iterations, the team completed its release commitments in 3 months ahead of regular allotment of time for releases this size, with a third of the defects normally found in releases this side.

Product Coordination Team

Group profile: Web Applications for large Healthcare Insurance Company

Challenges: Multiple scrum teams unable to coordinate using Scrum of Scrums

Insight: Multiple cross-functional teams were having challenges with coordination. As they pulled work from merged backlogs, teams began to step on one another as they touched the same code baseline. Product Coordination Team was created using Architects and Technical Leads. The multiple teams synchronized their iterations to start and stop on the same schedule. This allowed the teams to Demonstrate, Plan and Retrospect together. Having the multiple teams together (with the PCT present), allowed the teams to present their upcoming iteration plans to each other. It was much easier to identify opportunities for encapsulating effort when the teams presented their committed stories. As the PCT identified these duplicate efforts, they created stories that were distributed to the appropriate teams so that each group could safely focus on implementing code with minimum overlap. This model also allowed for the teams to recognize when they were potentially duplicating effort, so the PCT was able to guide effective abstraction so that duplicate code was avoided.

Cross-functional Teams

Company profile: Software for Healthcare Data and Intelligence

Challenges: Growing business finding it difficult to scale

Insight: Increasingly larger releases were creating a disproportionate number of defects. The development teams had grown significantly beyond a core group of developers – yet deep knowledge of their codebase had not. The individual developers were very comfortable in their silos, but the increasingly complex system was becoming unwieldy. Big batch thinking was believed to be as basic as breathing air. We determined a Minimum Releasable Feature and defined the stories and tasks to accomplish that one feature. The team rallied around this concept aggressively distributing knowledge and discovered blind spots between the silos that had been contributing to the higher defect count.