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.
Getty Images discusses their product management transformation in The Value of Co-Creation
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.
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.”
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.”
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.
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.
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.
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.
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.
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.
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.