Outcomes

Financial Data Modeling

Before a DevOps Dojo

A  ten-person product team spent 3-months developing a suite of dashboards for financial analysts. They developed in 2-week sprints and demonstrated what they finished to their Product Owner. They felt confident about what they developed based on feedback from the Product Owner. 

Some Financial Analysts did user acceptance testing at the end of every month and others pushed it out quarterly. Their feedback was much different. They claimed that the dashboards they received were over-engineered and too complicated to use. The dashboard did not tell the stories they needed them to tell.

The Product Owner assumed the Financial Analysts were too busy to attend the team's end-of-sprint reviews to provide critical feedback. The Product Owner, who was an expert in the technology, said the Financial Analysts didn't understand his team's capabilities. He also claimed that the Financial Analysts don't know what they wanted.

The Development team members were frustrated. They spent 3-months developing a suite of dashboards that were not being used. They were worried about their reputation. A few team members were pursuing other opportunities in the company.

After a DevOps Dojo

Organizational learning accelerated between the Financial Analysts and the Product Team. The team gained empathy for the problems the Financial Analysts needed them to solve. The Financial Analysts learned what kinds of information they needed to provide to the team.

The Product Owner uses rapid prototyping tools with the Financial Analysts to validate key assumptions about product backlog items before he adds anything to the product backlog.

The Product Owner and the development team value feedback from the Financial Analysts. They found ways to shorten their sprints down from 2-weeks to 1-week so they get more regular feedback.  

The Financial Analysts were happy to provide weekly feedback to ensure they receive dashboards that tell the right stories and are easy to use.

The development team demonstrates completed dashboard increments to the Financial Analysts at the end of their 1-week sprints. They gained the confidence to do these demonstrations because they already demonstrated their completed work with their team and Product Owner. The quality of their product increments improved because they know they have to demonstrate completed increments to the Financial Analysts. 

When the Financial Analysts provide valuable feedback to the development team during the demonstrations, the team members ask the Financial Analysts qualifying questions. Through this back and forth exchange, the Financial Analysts learned what information the team needs from them. 

The team enjoys collaborating and skilling each other up over competing and working independently. The team actively promotes coaching to other teams who are not happy with their outcomes.

Sales Data Visualization

Before Coaching and Consulting

A 28-person team composed of members from two different vendors and direct-hire members. Each vendor had a designated system architect leader. During the team's sprints, these architect leaders directed the work of every team member who reported up through the architect's vendor. The time each team member spent on tasks was tracked by the system architects. All vendor team members felt like order takers who had little say in what was being developed.

The team delivered product increments to their Product Owner every two weeks. The company's operational leaders who used what the team developed did user acceptance testing on a quarterly basis.

The team was forced to work in a war-room environment until they fixed all the problems discovered from the most recent quarterly user acceptance testing activity. They worked nights and weekends to fix everything for an important upcoming business event.

After Coaching and Consulting

All members from newly formed teams grew their empathy for the operational leaders who used the solutions they developed.  All members also feel like they have a say in what they develop and how they develop. War-room working is in their review mirror and they work normal work schedules. 

The team was broken down into 4 teams, 3-cross functional product teams and one shared services team.  Each product team had a mixture of members from both verdors and direct-hire employees. 

The two system architects were moved to a shared services team that supported the 3 teams as needed. They were integral for decoupling the teams' codebases so the teams could set up team-specific continuous integration pipelines. The architects also assisted the Product Owner with portfolio-level decision-making and epic planning.

The Product Owner flowed epics of the product backlog to the 3 independent product teams.  The Product Owner's product roadmap was regularly informed by the operational leaders who used the solutions the three teams developed. Impacted operational leaders attended the weekly sprint review demonstrations. to provide regular feedback directly to the teams who developed the solutions delivered. 

Team members were able to ask qualifying questions when they received feedback directly from the operational leaders who used the solutions the team developed. Through these exchanges, the operational leaders learned what information they needed to provide to the teams. 

The Product Owner formed a Product Owner Community of Practices for his division of the company. The Scrum Master joined the existing divisional Scrum Master Community of Practices.  Team members from all four teams actively promote coaching to other teams in the company.

 



Stereoscopic and VR Educational Products

Before Enterprise Coaching

A product roadmap did not exist

The enterprise had one partially co-located product team that was responsible for:

The company landed a multimillion-dollar contract to develop a new platform with new product lines for a publishing company. This effort was monumental and overwhelming. It required the company to:

All development was directed by the President of Engineering who required polished solutions before they could be demonstrated. Months went by before anything was demonstrated to the publishing company stakeholders. Testing waited until a polished solution was ready. Enterprise leaders were very concerned that they would not have anything to deliver in time for the back-to-school sales season

The publishing company continuously requested demonstrations.

The core product team had not adopted an agreed-upon agile framework. Each team member worked on whatever the President of Engineering directed. Sometimes team members would be working on multiple disparate efforts at the same time. The team members worked separately in parallel 

Team members were regularly and unexpectedly pulled away from what they were working on to fix problems with legacy products or develop last-minute marketing prototypes.  

After Enterprise Coaching

A product roadmap emerged through collaboration with enterprise stakeholders, external business stakeholders, and the product teams. A backlog funnel evolved, filtering out development efforts that did not align with the agreed-upon product roadmap. 

Legacy product enhancements and fixes along with marketing prototypes became development efforts that were planned in advance. As much as possible, these efforts were included in the product roadmap.

The core product team adopted a  hybrid of Scrum, Extreme Programming and Kanban. They were able to stay focused on developing the new product platform for the publishing company. They built quality in with unit testing that grew in their continuous integration platform. They paired up and did regular demonstrations of their work to each other as part of the definition of done they all agreed on. Their velocity and ways of working informed the enterprise of the need to scale up. We added three additional 100% remote product teams. 

The publishing company stakeholders welcomed being present for product increment demonstrations at sprint reviews every 2-weeks. The publishing company and enterprise found ways to get feedback from the students, teachers, professors, and librarians who used the integrated product. The publishing company learned over time, what information they needed to provide to the teams. The teams grew their empathy for the student's wants needs and expectations of the stereoscopic and virtual reality software they developed.

The enterprise was able to integrate its products into the publishing company's searchable system of educational products in time for the back-to-school sales season. The publishing company earned New Horizon and EdTech awards for the new platform. Students who use the new platform perform thirty-four percent better on tests than students who don't use it.

Enterprise Desktop Services

Before Product Family Coaching

After Coaching