Digital transformation is generally understood as the digitization of a company’s business processes. In this context, agile transformation is the adaptation of the work methods and tools needed for running the digitized company and leveraging the potential of the digital transformation: becoming more efficient, effective and customer friendly. From an operations perspective, such an adaptation enables a company to process digital input and to produce digital output, satisfying customers’ needs in the best possible way.
Fig. 1: The agile approach seen from an operations perspective
Many small- and medium-sized enterprises (SMEs) struggle with the digital and agile transformations. This is often due to the assumption that Scrum is for start-ups and incubators only. But what really causes the frustration are the greenfield approaches to agile methods copied from start- ups, along with an all-or-nothing attitude that, unfortunately, the Scrum Guide seemingly promotes for the innocuous reader: “Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.” (Schwaber, Ken/Sutherland, Jeff (2017): The Scrum GuideTM, p. 19)
In practice, following Scrum to the letter is much less important than finding work methods that fit the company, its business, and the people who work there. This requires a thorough analysis, leading to a deeper understanding of the way departments and people previously interacted and completed their tasks. In the following, this will be illustrated based on the experience from several recent consulting cases.
The customer in question might be a family business in a traditional industry. The in-house IT comprises about 50 people. It has only recently been established as a single department under a newly-hired department head. Before that, there had been two sub-departments: one responsible for the IT infrastructure as well as software development, and the other acting as a kind of project and requirements management (PRM). The latter sub-department occasionally turned over development tasks to a long-standing supplier. As a particular challenge, all new features and change requests had to be implemented on a system that worked according to mainframe logic. There were a lot of interdependencies between different sections of code and databases, and this made it highly likely for even the smallest modifications to produce system-critical errors.
By the time the consulting mandate started, the entire IT was considered completely unproductive by the other departments and the management. Interviews with management and staff confirmed the assessment, and also shed light on what was causing the problem. It turned out that even the tiniest modifications of the software, which other companies would classify as high priority change requests, took an average of 6 weeks to complete. In addition, many demands made by the specialist departments had been waiting to be implemented for more than a year. Even worse, when a demand had finally been implemented, no one in the relevant department remembered why the change had become necessary in the first place. As a formal approval process was lacking, virtually none of the modifications asked for ever went live.
The causes of the IT’s perceived inability to deliver became very clear during the discussions with staff: Even the smallest tasks were labelled as “projects”; at the same time, no employee knew what a project really was, let alone what made it different from a change request. The same was true for the specialist departments, and for the management. There was no for- mal process for initiating a project or asking for a change request.
As a result, all tasks were initiated the “Hey-Joe”-way: employees from the specialist departments simply passed their demands on to someone from PRM, be it by e-mail, a casual phone call or a chat over lunch. Prioritization was by hierarchy only, so that the owners could overrule any task IT was working on in no time. None of the demands underwent any detailed analysis regarding their usefulness and technical feasibility, nor were they prioritized based on any conceivable criteria. Ultimately, both the way the IT department received its input, and the way it delivered its output, were severely disturbed. This explained the general impression of IT’s inability to deliver.
Fig. 2: Disturbances on the input and output sides of the process leads to the almost complete inability of the IT to deliver
To counter this unsatisfactory state, the consulting team decided to cautiously introduce some puzzle pieces from agile approaches. Clearly, much of the problem hinged on the fact that requirements were not transmitted in a comprehensible and comprehensive manner. Also, responsibilities were not clearly assigned, as mirrored in the RACI-matrix below.
Fig. 3: RACI-matrix of the IT-department before the introduction of agile methods
The same few employees from the PRM sub-department were usually ascribed the “Responsible”-role, whereas the whole amorphous team doing infrastructure and software development was seen in a subordinate role. Executives, on the other hand, were not “Responsible” in the perception of the interviewed employees but were frequently classified as “Consulted”. This was one of the causes for requirements to become inflated.
Agile methods offer the advantage of making transparent the links between requirements and their implementation, as well as the responsibility of individuals and teams. In the case presented here, it was particularly important to emphasize responsibilities. Up until then, nobody had ever thought about footing the bill caused by their respective demands. To put an end to the “Hey-Joe-hierarchical”-approach, executives and managers were made aware that they had to describe what they wanted in a comprehensible way and estimate the prospective business value of their demands.
Scrum and user stories come into play here. After lengthy but ultimately fruitful discussions with the management, the consultants received per- mission to introduce a kind of check- list, which all departments should use when transmitting new tasks to IT. A person from the PRM sub-department was installed as point of con- tact, whose job it was to act as a kind of overall Product Owner (PO) for the central (mainframe-like) IT. Note that this person’s primary task is not technical at all. She is supposed to help fill in the check-list and formulate user stories based on the information given, and to facilitate a meeting we called Round Table.
For Scrum experts, this was nothing more than Planning Meeting 1, and the consultations with the Product Owner were actually backlog grooming and story estimation. One observation from many consulting cases, however, is that agile terminology often meets with resistance in more traditional companies. Poor knowledge of English is often volunteered as a reason, but an underlying desire to set oneself apart from the start-up hipsters in the hotspots of the New Economy may well be at play, too.
As might be expected, management needed a certain amount of support to transition to the new way of working. The same was true of the newly appointed PO, who had to get used to the new role as an adviser and facilitator. To meet this need, in addition to extensive on-the-job coaching, off-the-job trainings are very helpful. They foster the further development of necessary methodological and personal competences, and show the potential of agile methods outside employees’ concrete working contexts. A company reaching for an agile transformation should train as many employees as possible – from the shop floor up to the management level – to implement agile methods. This way, employees can drive change from within, ultimately reducing the need for external consulting.
The first Round Table was a success. Based on the check list, user stories were formulated. The participating managers quickly grasped the need to make the costs and benefits of a requirement transparent. From the magic wallpaper and cards that acted as the newly–installed Scrum board, they also saw with their own eyes why prioritization was an absolute necessity: the software development team (who we named “agile team – at”) had limited capacity and needed an indication as to which requirements were the most important.
Following the Round Table, the agile team would have a meeting with the Product Owner, where they committed to the requirements they would churn out within two weeks (in Scrum terminology: in the current Sprint). This made possible a perk for managers: they now received a commitment that the highest priority requirements would definitely be delivered within two weeks at the most. Additional items would be approached as fit the capacity – and there would reliably be another meeting after two weeks, making it possible to react quickly to new and changing priorities. This meant a notable change from the former state of the “unproductive” IT.
In addition, the method brought about a normalization of the RACI-matrix: PRM (now the Product Owner and two Co-Product Owners) and the agile team became “Responsible”, managers became “Accountable” for requirements from their respective departments. At the same time, managers from the other departments were “Consulted” during the Round Table, or even before that, when the check-list was filled in for any given requirement. Ultimately, executives were really only given a rough overview and not bothered by overwhelming technical detail.
Fig. 4: RACI-matrix of the IT-department after the introduction of a few agile methods
* with respect to their own department
** with respect to other departments
*** as a substitute for the head of department
During daily work, it quickly showed that IT had regained its ability to deliver. This was made possible by the simple fact that requirements were now explicitly formulated and prioritized. Also, instead of assigning 10 or even 20 poorly formulated requirements to a single person, there was now a team of 4 working on 3-4 tasks at a time, giving developers superior focus.
The agile team’s tasks were tracked on the Scrum board, and tasks iterated through the status “To Do”, “Development”, “Technical Test”, “Test Product Owner” and “Acceptance”. The final status was tied to cooperation from management: With the introduction of the method, it was agreed that a department asking for a certain requirement must be available for questions that might arise during development at very short notice. They also had to be ready to do an acceptance test, which meant there was now a formal approval process in place. As a result, the process around the IT department improved on the input as well as on the output side. The agile team now used a rudimentary form of Scrum. Through the simple Scrum board on the wall the method acquired a visibility that might well outweigh the advantages of a sophisticated tool, such as jira. Tooling was actually postponed, as its complexity and cost represent typical agile aspects that make traditional business people cringe.
Fig. 5: New methods and clear roles restore IT’s ability to deliver.
To conclude, IT’s ability to deliver was restored thanks to two immediate effects of agile methods:
– clearly defined responsibilities (shown in the figure by the person pictograms)
– visibility and transparency of requirements / tasks
Together, they provide some concrete “material” based upon which every- body (e.g. all the roles in the RACI matrix) can learn the method and practice the new way of working together. This shows that, contrary to popular belief, agile methods can be introduced with a minimum of “theory” (a frequent criticism in smaller companies), and produce tangible results even in the first phases. In the present case, the company still chose to have the learning process supported by two experienced Agile Coaches.
This article does not suggest that agile methods are a panacea. The intro- duction of a rudimentary Scrum did not immediately generate customer-oriented output in the style of a start-up (this is what the yellow flash in Fig. 5 indicates). And, of course, there were also some negative reactions from management and employees, which must be used as feedback for the next steps in the agile transformation process. Also, the measures described in this article are really only the very first steps towards the “agile threshold”. Many more aspects, like the hardware and software, test and quality management, cooperation with standing and potential suppliers, need to be addressed subsequently. The agile team needs time to “get into the groove” before they can serve as a nucleus or example for introducing agile puzzle pieces in additional departments.
The path to an agile attitude, which is the organizational matrix for digital transformation, can take a long time to complete. This article has recount- ed the first steps of the journey and highlighted its first results. In any case, the question of whether to call any of this “Scrum”, or not, should not be the primary concern, and it is certainly no obstacle to taking on the agile trans- formation.
Author: Christiane Zehrer
She first learned about Scrum in 2007 and has been hooked since. She worked as a bid manager and consultant in the automotive industry before turning completely agile, becoming a full-time product owner and coach. She holds a PhD in applied linguistics and presently teaches technical communication and project management at the university level.