Sometimes we overthink solutions. We become convinced that a particular approach is the only approach. We forget to question assumptions openly and honestly.
It's very difficult to see this problem when we are deeply involved in it. And once we invest time into an approach, loss aversion, or sometimes just "face-saving" will cause us to double or triple down before we take the time to re-evaluate (to begin the diverge/converge process again). But when we're not deeply involved, when we are new to an organization, it can become clear that this is happening. Such was the case at Agilysys and the "release" problem they were facing.
Situation: Agilysys had grown through acquisition. The company consisted of 12 "legacy" products and 4/5 new "true" SaaS products intended to eventually replace several of the legacy products. Largely independent teams worked the legacy products from different locations around the US and with remote development support. Tools, methodologies, and team maturity was radically inconsistent. The newer SaaS products all followed the same development and release methodology. The issues there were much different, but no less daunting. For example, the organization never reconciled the realities of agile development with executive-level financial planning. As a result, no standard release process was possible technically, and no one had any idea what was shipping, when, how and why - including customers. Sales, support, and marketing were rarely prepared for a release.
Several attempts had been made to fix the problem including costly (hundreds of thousands of dollars) project planning tools and even the development of an ambitious proprietary expert system. A lot of money had been spent. More was planned. Nothing had worked.
The failure can be attributed to believing that the release processes across products had to be brought into alignment before any release planning could be rationally pursued. Because it simply wasn't reasonable to insist on major changes across product development processes, the strategy had been to impose another layer of planning on top of them all. This additional layer was to act as a wrapper, hiding the underlying differences.
Resolution: Following the principles of lean/agile, and coupling them with a working knowledge of effective patterns in cross-functional communications, we designed a simple exception-driven notification mechanism, coupled with a single optional monthly meeting. This took the form of a structured email that listed every upcoming release. Next to each release were columns corresponding to each team requiring notification. We used colored Harvey Balls to describe the status of each department and required the department leads to update the color of their Harvey Ball for any release they were not prepared to support. (The structured portion of the email was a snapshot of a confluence page to which the players all had read/write access.
The email was sent to every lead, and the executive team. A glance down the page told anyone where issues existed. All green Harvey Balls meant everyone was aware of every release and that there were no blocking issues. A red Harvey Ball signaled a potential issue. Hardly rocket science, hardly innovative, but entirely effective.
Outcome: By sending this email out weekly to the players, this ensured that everyone knew when a release was coming. Questions could be asked and planning conducted. This worked because the issue was not uniform release processes, it was simple awareness. Once the players were aware of what was coming, they could work together to prepare. Smart people, working together, can solve problems without a lot of unnecessary structure. By emailing everyone at once, no one had any excuse for claiming they were caught by surprise. We had one 30-minute scrum style meeting per month to list any outstanding significant issues.
Because the solution did not require another layer of planning, training on new tools, and literally no net new work (the hassles this simple solution avoided more than made up for the need to occasionally update a few Harvey Balls) it was relatively easy to obtain buy-in. The old thinking didn't go away without a struggle, but it did eventually fade away. Managing that process was one of the more challenging aspects of the project.
Comments