You may be interested in what Senex Rex does. Our mission is to help clients become highly profitable long term. When our clients make more money, they have greater freedom to innovate and their employees and shareholders have more freedom to enjoy life. We happen to think agility helps in many cases, so we often teach and coach agile theory and practice. Few contractors teach clients how to sustainably retain and improve agility; we specialize in that. We have many other tools in our tool box. Here’s a snapshot of the work Senex Rex did in February 2014.
Agile organizational development
In February, Senex Rex consultants helped develop a program to train managers to become effective systems-thinkers and agile coaches. This included training modules for root cause mapping, metric driven coaching, Manager Scrum Teams, and agile architecture. We are about to test this approach; we’ll let you know how it goes.
Measuring it so you can manage it
We continue to see strong evidence that a metrics focus helps Scrum Teams and agile enterprises improve more rapidly. For example, about nine months ago, one Senex Rex consultant coached a manager and ScrumMaster, for about a week, to use Forecast Horizon to measure the depth of engagement between Product Owner and Development. The team operated independently following this, with chat and voice based counseling as needed. After they achieved their Forecast Horizon goal, they continuing to maintain a 2-month Forecast Horizon. The team has doubled its software production rate. Team members talk enthusiastically about their visibility into the future and their ability to innovate.
Promoting agile career paths, job descriptions and compensation
We are seeing demand for sample agile career paths, job descriptions and compensation plans for agile managers, ScrumMasters, developers and product owners, from virtually all of our clients. Agile practices require significant effort and cultural support to maintain. When personal interests are well-aligned with company agile goals, the company can sustain agility for longer, with less effort. Career paths and compensation plans play an important role. Companies hoping to maintain agility long-term must tackle this issue. We helped guide a company to create its own “operations career path” that includes ScrumMasters, Release Managers and Operations Managers, whose role is to reduce risk and increase speed.
Adapting a shipment with Monte Carlo modeling
Another client was running into serious quality problems with a release, while also under deadline pressure. The saying goes, “Resources, quality, scope and date: pick three and let us vary the other,” but this client’s managers thought they could constrain all four. The client (like many so-called agile companies) has Scrum teams assembled in a waterfall component-team structure. As a result, the organization ship slightly more frequently than with its previous all-waterfall approach, but with unpredictable quality and many deferred risks.
We asked the client’s development managers: Was the deadline feasible? The managers responded optimistically, “Yes, we can make it.” At Senex Rex, we’ve been around the block. We believe data, not enthusiasm.
We tracked the throughput and lead time of 42 Scrum teams from historical data, modeled their dependencies, created a cumulative flow diagram, identified and estimated sources of delay (statistically, not with fixed estimates), put all this stuff into a Monte Carlo model and produced a forecasting machine. The beauty of this approach is we didn’t need developer estimates (they help, but we don’t need them, and in this case didn’t have them).
We put the data into our Monte Carlo model. We wanted to know if the client was actually burning down feature work, or were feature requirements continuing to grow? With only weeks until the deadline, the model showed feature requirements were only then starting to drop as developers completed more requirements than requested.
We asked our Monte Carlo model: Was the deadline feasible? Based on objective data, the model said the project would ship 60 days late. Hiring was frozen, so the project had no resource latitude. Quality needed to be high, because the product is installed in enterprises. So, we concluded only scope could vary.
To our client’s credit, with objective data and statistically sound modeling as fuel, managers started throwing features out. They used our model to forecast the newly-lowered requirements. They changed from a “fix-all-bugs” approach to a “focus on level-1 bugs only” approach. The model said we could squeak this project out, barely, by the deadline.
And the reality? Our client shipped it, one day before our model predicted they would ship.
Rearchitecting a legacy system
One client asked for our help rearchitecting and prototyping a replacement for a legacy system, to use off-the-shelf and open source software. This would dramatically reduce their long-term software development costs. The legacy system had quality and scaling problems. The client had built a many components that didn’t exist when they started years ago, but now have competent open source equivalents. The legacy system had been built incrementally, locally optimized for yesterday’s challenges, not for the future. We think of this as a pivot-or-persevere moment; in our experience, doing a pivot for the wrong reasons or the wrong way can waste millions of dollars. Sound familiar? We’ve seen this situation several times, and few cases end well.
Working with trusted partners, we built a proof of concept in two 1-week sprints. The first sprint shipped a paper prototype with components, constraints and target scalability goals. We described how the product would work, estimated the capacity of different components in a real implementation, and showed communication paths and outcomes. We walked the client through a paper-demonstration, took questions, and asked the client to propose use cases. We then showed how the paper prototype would handle each use cases. The client loved this approach and said it exceeded their expectations.
The second sprint produced a command-line implementation of the most difficult use cases (which were never successfully implemented in the legacy system). We used Lean Startup principles, employing validated learning to establish metrics to objectively measure success and hypothesize an outcome. This discipline helped us scope the problem responsibly, and made sure we addressed the client’s top concerns. We pleasantly surprised the client with a great outcome, and we won a contract to implement the production replacement.
Stabilizing agility under re-organization
One of our clients reorganized with several high-level management changes. Agility often suffers in such situations, with new, agile-inexperienced leaders throwing babies out with bathwater. Senex Rex consultants have been in leadership roles, and we can communicate directly and effectively with corporate leaders. We believe high-level managers are the key to stabilizing and nurturing agility, so we focused our attention on coaching them to promote agility (rather than suggesting that companies hire an army to coach teams). We coached several directors and managers during this time, showing them the benefits of an agile mind-set and helping shape the outcome to promote agility. We helped adapt existing, well-running processes to continue to work while the organizational structure radically changed.
Restructuring component teams to deliver faster
Too often, clients casually divide projects into “obvious component teams” without understanding how that might degrade agility. To help improve the results of re-orgs, Senex Rex consultants often construct team dependency diagrams of proposed organization structures. Thesy diagrams, particularly in Scrum-based companies, can help compute rough estimates of time-to-value (sometimes called “concept to cash”).
One client, with 200 teams, was having difficulty shipping products frequently, so we constructed a dependency diagram. It revealed that combining just two component teams, each with different Product Backlogs, into two “Scrum of Scrums” feature teams, sharing a single backlog, would reduce the organization’s time-to-value by about 3 weeks. We asked managers, Are the teams able to work on each others’ code bases? They were, and furthermore there were two more teams that could participate.
To their credit, the managers merged all 4 teams together and then created a “Scrum of Scrum” organization with 4 teams pulling from a single backlog. We tracked the progress of bug fixes and features through the teams, before the reorganization and after. The graphic above shows the results. Before reorganization, the average time these teams took to complete a bug-fix or feature implementation was roughly 35 days. After reorganization, the average completion time was 12 days, a 2-week improvement. Notice, too, that the delivery times are more predictable with the feature team organization.
These results combine with the organizational time-to-value improvement to yield a likely improvement of roughly 5 weeks. Shorter cycle times mean companies can repair problems more rapidly and satisfy markets better than their competitors. We think it’s important to point out how easy this was. Team members are happier with the new approach. All it required was taking a step back and thoughtfully analyzing the throughput effect.
Also in February
- Dan Greening’s talk “Metric-Driven Enterprise Coaching” was accepted for the worldwide Scrum Gathering in May 2014.
- Troy Magennis’s work was highlighted in InfoQ.
- Dan Greening and Jeff Sutherland issued a call for papers for the Agile and Lean Organizations track at the influential Hawaii International Conference on Systems Science.
Summary
This is a typical month for Senex Rex. Our consultants are former corporate leaders—CxOs and Vice Presidents. We consider ourselves organizational scientists. We contribute not only to process improvement and software, but also human resources, finance, organizational development, product management and management training. If you could use help in these areas, drop us a line.
