Client Success Stories

Net Objectives has helped many organizations achieve Agility at scale.

Learn from the experiences of our clients and coaches.


Call outs by clients

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


Insights from our Lean-Agile coaches

Here are some important insights about Lean-Agile thinking that we have garnered during our courses and coaching engagements.

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 three 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.