Agile 2020 Preview

Agile Adoption and Transformation 327 today (Kanban, Poka Yoke, JIT, PDCA, etc.). Based on this and other work, Jeff Sutherland and Ken Schwaber created Scrum and published their work at a software industry confer- ence in the mid-1990s. Both later participated in a workshop that documented and published the Agile Manifesto in 2001. Sutherland published the Scrum Guide, and various other participants from that original group went off to write books about Scrum or Scrum-related activities or disciplines. Some of the methodology variants focused on scaling of Agile/Scrum processes across many teams. It’s been almost 20 years since the Agile Manifesto was published, and Agile processes frameworks/methodologies/techniques have multiplied like little rab- bits ever since. However, at the core of many of the process frame- works/methodologies that are floating under the big Agile Umbrel- la, almost all use Scrum at the team level. Lots of terminology noise, but very few practical differences. With Agile/Scrum, You Do Not Need to Plan Any Longer Wrong. In a nutshell, you plan just as much as you did with other methodologies, but you plan differently—the biggest difference being that instead of big, upfront, planning, you now plan “as you go.” Also, Agile planning turns traditional planning on its head. In- stead of defining a plan based on upfront requirements (which may or may not hold true) that results in a cost estimate for a project, Agile fixes the cost and schedule and delivers against a flexible list of features.

328 Brian Will Old style waterfall methodologies try to plan everything in advance (define the requirements) to establish a planning and cost baseline upfront. Agile, on the other hand, takes a fixed budget and schedule and asks: How many of the top priority features can we fit into availa- ble money and time? Kanban is better than Scrum Wrong. If you look at a Kanban board and a Scrum board, you will be hard pressed to see a difference. The biggest difference is that Scrum is time bound (say, for example, to a 2-week sprint), which means that everything on the Scrum board is supposed to get done and move from the leftmost column over to the rightmost “Done” column. Kanban boards, on the other hand, flow; there is no time limit, and things get pulled into the board as needed, and drop off the board when done. They are different, but related. For a more detailed descrip- tion of the differences, see the chapter in this book comparing both. Scaling is hard. That is why most Enterprise Agile Transformation or Digital Transformation efforts fail! Anybody telling you that an enter- prise-wide Agile Transformation is easy simply has never done one before. It is easy to jump on the Agile bandwagon and end up wrapped

Agile Adoption and Transformation 329 around your own knickers. Many organizations jump into an Agile Transformation effort because of its advantages—desired market re- sponsiveness, embracing change, competitive pressures, decreased time-to-market, evolutionary architecture, and so on—only to get stuck. To make things worse, there are several levels your organization can get stuck in; the following sections will go through some of the most common failure patterns. Starting without a clear goal in mind Any coach in any discipline (be it soccer, golf, tennis, basketball, suc- cess management, financial management, college prep, or business level coaching) knows that the first step is to understand the desired results of the transformation. What do you want out of the Agile Transformation? “Being Agile” usually is not a goal. Some valid business reasons might be: When starting an Agile Transformation, pick no more than 3! Why? Because picking 5 or 8 or all is the equivalent of quitting smok-

330 Brian Will ing, losing weight, starting a new job, getting a new baby, moving, and taking care of your elderly parents all at the same time. It is not going to happen! Pick a few key areas you want to improve on, and quantify by how much you want to improve in each area. Be specific. For example: 1. Accelerate product delivery, from yearly releases to releases every 6 months. 2. Enhance software quality by 50%, measured by defects that leaked to production. 3. Reduce project cost by 20%. You need to know what you want to achieve; otherwise, why do it? Doing agile vs. being agile What if I told you I once worked for a custom software house that followed a traditional waterfall development model but was able to deploy builds to their test environments daily—in 1989? Unit tests were fully automated. The build process was fully automated. System and Integration tests were fully automated. We were agile! Agile be- gins with attitude. The point is to be agile, and truly understand what makes that happen. Following a new process methodology called “Scrum,” stand- ardizing that process across all projects, big and small, software inten- sive or not, will not get you the transformation you are looking for. The goal is to push responsibility down to the teams, to enable

Agile Adoption and Transformation 331 them to make the right choices for their projects; to shed useless cer- emonies, administration, and paperwork; to produce working code; and to go through fast feedback cycles. Enable teams to self-organize, self-examine, and self-optimize. Self-organization does not mean anarchy. Companies can still set standards, but the team needs to be empowered to make the “on the ground” decisions. This is the one area where strong, demonstrated support from the top executives can make all the difference. Underestimating organizational culture As mentioned earlier, everybody talks about Agile. Every major con- sulting firm hustles their Agile Transformation or Digital Transfor- mation service. And just like every football franchise owner thinks they will go to the playoffs, every CEO or executive thinks they can transform their organization. However, the CEO or executive view of what their organization is capable of is based on what their middle management reports to them—very few experience their organization “Undercover Boss” style. Any assessment of cultural impediments will therefore pass through and be shaped by the system itself. There is a reason doctors do not self-diagnose, but in the business world that approach is rare. The information they receive about the organization, from the organization, will be inherently self-serving. Agile Transformation is deep and pervasive, and understanding that it “involves” cultural change is not enough. Reading about running does not make you a runner. Reading about climbing Mount Everest

332 Brian Will does not make you a climber. Only experience does. Practice beats theory. Doing over reading. And therein lies the problem—unless the CEO or sponsoring executive makes the transition herself, organiza- tional change and Agile Transformation will remain elusive. The way executives personally interact with their organizations must change too. Thinking it’s another tool or tweak Agile is a fundamental change. Executives—especially those who have been successful and have survived multiple methodologies, fads, de- velopment or management approaches (Zero Defects, Capability Ma- turity Model, Rational Unified Process, etc.)—must realize that this one is different, for no other reason but the fact that your competitors that successfully transformed into agile organizations will outperform you by a wide margin. This can easily mislead stakeholders, including senior executives, into thinking that Agile Transformation is essentially a technical con- cern. The reason it is not just technical is simple: Your value stream most likely consists of many other activities, departments, partners, suppliers, etc. that require synchronization and coordination—and your technical departments make up only a small piece of the overall value stream. If you make only the technical side of your business more agile, you will simply not realize the advantages that you are hoping for. You are optimizing a small percentage of your business. It’s incumbent upon senior executives to realize that if the benefits of agile change are indeed to accrue, then change must be demanded from—and sponsored across—the whole enterprise.

Agile Adoption and Transformation 333 Come yourself or send no one I am amazed when executives push back on the suggestion that they need to personally lead their organization’s Agile Transformation. The implication of their pushback is that “Agile is for those technical people.” The heading above is based on a story (possibly fictional) that circulated about Dr. Deming during the late 80’s. Computer manu- facturers were still struggling to figure out how they were going to store data and had temporarily settled for magnetic media known as floppy disks. One of the US companies manufacturing floppy disks was Nashua Corporation, headquartered in Nashua, NH. Supposedly the CFO of Nashua Corp heard Dr. Deming speak at a conference in Washington, DC. The CFO returned from the con- ference on fire and convinced the CEO that Dr. Deming could help Nashua Corp. resolve one of its most significant problems. The CEO agreed to see Dr. Deming and to initiate conversations with him via an introductory letter. It was signed by the CEO and suggested a time and place for the meeting. A few days later a reply arrived by mail. It was addressed to the CEO and stated tersely, “Come yourself or send no one.” Besides being humorous, why is this significant? The answer is that Dr. Deming knew that if senior leaders weren’t willing to lead an initiative from the start, then it would be stillborn. He refused to par- ticipate in such activities. There is a similar story about him hanging up on the VP of Quality for Ford Motor Company several times before explaining the same rules to him. Most organizations, especially large ones, are hierarchical, so it is natural for executives to want to delegate

334 Brian Will tasks. Unfortunately, an Agile Transformation cannot be delegated. Everyone must be involved in enterprise transformation, and the re- sponsibility for managing its success cannot be passed on to someone else—the CEO and her most senior leadership team are on the hook. Underestimating organizational gravity Just like a fighter jet taking off, it is likely that organizational gravity (and people!) will pull really hard in order to revert to traditional ways of working. Just like the jet engine stalling, it’s easy to fall back to earth. Change on a personal level is hard—think about how challeng- ing it is to quit smoking, lose weight, or start exercising—at an organ- izational level it is infinitely harder! Employees may observe old pro- cedures and protocols while emulating new agile practices as well— this is the common pattern of doing agile without being agile. Think of it as eating salad but craving steak! Then there is personal pride, prejudice, and uncertainty—people might behave defensively when faced with the expectation of genuine change to their job, their influ- ence, the size of their office. There can be a great reluctance to see existing roles undergo change. Ignoring Human Resource considerations I have seen countless Agile Transformations where Human Resources completely ignores Agile/Scrum Adoption considerations, especially around job descriptions, career paths, and career development. HR usually ignores an Agile Transformation initiative (to their de- fense, most times nobody tells them!), while the Engineer-

Agile Adoption and Transformation 335 ing/Software Development organizations happily proceed to focus internally, as if there are no other considerations. But there are many HR-related considerations that, if not taken care of, seriously impact the long-term viability of any Agile Transformation process. Executives need to drive the HR considerations as soon as they commit to an Agile Transformation. This is a highly sensitive area that can derail the initiative unless things are communicated clearly across the board. Not providing an ideal office setup An Agile Transformation will require reconfiguring your work space to match the Agile/Scrum process. This sounds simple but can be very challenging. When we talk about Facilities, what do we actually mean? Basical- ly, how teams and people sit and work together, considering the op- timal office layout, conference rooms, break rooms, rest areas—in general, the best appropriate physical environment. The sad truth is that many companies miss the boat on this one— because the executive isn’t pushing it. One reason is that tearing down existing office space and reconfiguring it is not that simple, most like- ly costly, and a logistical nightmare. The balance you need to find is between creating an environment that allows for open communication and flow of ideas while avoiding the trading floor style pandemonium that distracts software engineers from creating good code. Optimizing communication while maintain- ing a quiet work environment is the devil in this detail.

336 Brian Will An environment I have seen work is an environment with cubes (not the trading floor “everybody can see you from everywhere” kind, but full height ones), where team members sit in close proximity to- gether while still affording the privacy of your own space. Combine this with lots of conference rooms, and you have the op- portunity to create a work space that provides for open communication. Conference rooms need the latest communication equipment, vid- eo conferencing technology, and lots of white boards. Conference rooms need to range in terms of their usefulness from full-blown au- ditoriums to dedicated team meeting rooms to “phone booths” where people can step out to take a call. Not going all in Not all senior executives are Steve Jobs. Popular culture has proliferat- ed this picture of the CEO or senior executives as fearless leaders akin to General Patton—riding the first tank into battle waving the flag. But the corporate reality can be quite different. Some executives got to where they are because of the Peter Principle, and they are barely hanging on. Not every executive is an entrepreneur—many are steady- as-you-go operators. Some might see retirement on the horizon— why rock the boat? Or, despite the best of intentions, the company is challenged by current market conditions and the CEO and her execu- tives just don’t have the bandwidth for another big strategic change. Some might be too detached from the enterprise and its work to be truly bothered about a change initiative. They might intellectually understand the need and approve an Agile Transformation attempt

Agile Adoption and Transformation 337 when pressured by certain factions of the leadership team, but they will leave any handling to their direct reports to sort out without really fully supporting the change and not going all in. Without full out, strong, unwavering, massive action and agile sponsorship at the ex- ecutive level, organizational gravity will suck the organization right back into the black hole it came from. You know this instinctively. How many of us have tried to learn a foreign language one hour at a time? Didn’t work, right? I promise you, if you move to Italy, without a safety net, you will learn the lan- guage. Going all in and taking massive action will yield results. Dip- ping your toe, sort of, kind of, won’t. Not communicating a sense of urgency If you haven’t heard your CEO talk with urgency and specificity about the Agile Transformation underway, well, then it probably isn’t. A failure to communicate this imperative across the enterprise, and to set expectations accordingly, will stop critical momentum from building up. Change will “fizzle out.” Executives must take care to ensure that Agile Transformation is given top priority, communicated effectively, and driven hard toward clear, measurable, goals. After all, the end game is to be agile, and deliver real, tangible improvements—not spend 5 years trying to do that agile thing. Driving Agile Transformation as part of another program This one commonly occurs when companies are trying to piggyback

338 Brian Will the Agile Transformation as part of another program. For example, trying to leave their old legacy systems behind by employing a lift and shift initiative, trying to move from their old data center to the cloud. Oh, and by the way, we’ll do that while going through an Agile Transformation. Right. This is the equivalent of having a newborn, starting a new job, quitting smoking, and losing weight—all at the same time. Not going to happen. The focus of the Agile Transformation will be diluted by the other program’s challenges, and if the overall technical exercise experiences problems, the agile focus will take a backseat to “just get- ting it done.” Agile change is deep, pervasive, and must be expected to transcend all existing work and associated programs. Sponsorship for agile practices must reach beyond one program manager or a set of senior managers occupied with other deep technical challenges—it can only really come from the very top. Not understanding “plateauing” and “zigzagging” The good thing is that Agile/Scrum lends itself to empirical meas- urement. The bad thing is that many times executives expect linear improvements and do not understand the zigzag and course correc- tions and plateauing (or flatlining) that a massive Agile Transfor- mation goes through. Improvements will most likely plateau (flatline) at one time or the other, looking something like this:

Agile Adoption and Transformation 339 Or, even worse, you slide back and forth and you see measurable productivity loss, like this: Frequently, executives (and middle managers who were critical to begin with) immediately panic when they hit the first bump in the road. “You see, this Agile thing will never work”! This is akin to call- ing off the D-Day invasion as soon as you encountered the first set of casualties off the boat. What did you expect? A walk on the beach?

340 Brian Will It’s critical to stay the course, and work through these rough patches. Things will improve, and you will reach another high before you revert again. Continuous improvement over sustained periods of time does not happen in a linear fashion. Overlapping or mapping Agile into an existing process framework All established companies have existing methodologies and process frameworks. When embarking upon an Agile Transformation, it is tempting to overlap or map the new Agile/Scrum process into the ex- isting methodology. Why not keep everybody happy? For example, in the traditional waterfall model, you have the usual phases: Requirements Design Implementation Verification Maintenance Before you know it, you might hear something like “We are in sprint 12 of the requirements phase!” or “In this sprint we do Re- quirements; the next sprint we’ll focus on Design.” No, no, no! Don’t do this. You will create a mess of a hybrid, with none of the benefits you are looking for.

Agile Adoption and Transformation 341 Changing the company culture is too difficult; let’s change Agile/Scrum! Every employee, regardless of company or industry, truly believes that their company is unique, special, and not comparable. Many will openly state that straight up Agile/Scrum just won’t work. This kind of atti- tude is human nature; everybody wants to be special. For many em- ployees the existing processes (the ones you hope to replace by going through an Agile Transformation) oftentimes represent their “babies.” And just like any good mother would do, they will defend their young. This is the kind of organizational gravity that is a challenge to deal with unless executives completely buy into the Agile Transformation, including the fact that the company culture must change too—trying to change the Agile/Scrum process itself is a copout. Any kind of half-baked solution or compromise will essentially prevent the com- pany from realizing the benefits that an Agile Transformation promises. Not understanding value stream mapping and flow Agile practice is really about understanding the basics of empirical pro- cess control in a complex and uncertain environment. Agile/Scrum is essentially a feedback loop that establishes empirical facts—done right, you know what the team’s velocity is. Therefore, you can predict, within a margin of error, how much work can be accomplished in the future. Those iterative and incremental techniques are geared toward ex- perimentation. Agile practice helps an organization to learn about the business context in which it truly operates.

342 Brian Will Value stream mapping allows executives to understand where there are critical bottlenecks, work-in-process limits, and flow that allow for a realistic assessment of what can be put through the system. It never fails to amaze me to see a CEO or senior executive turn pale when you explain that 98% of a project’s time spent is “wait time,” not “process time.” These are usually eye-opening discussions that help focus the executive ranks on the benefits of an Agile Transformation. Not reconsidering reports and metrics Executives often depend upon reports to give them an idea of what is going on and the decisions they ought to make. Reports, charts, and numbers provide them with essential information, and they interpret these sources using the indicators and measurements they think best re- veal the underlying truth. Their views of the organization, the challenges, the projects, and the people are shaped by these reports and metrics. Not adapting old reports, charts, and metrics to a new Agile envi- ronment sets you up for a lot of pain. However, executives who look at standard Agile burnup and burndown metrics, familiarize them- selves with the standard Agile information radiators, and focus on in- novation accounting and the elicitation of actionable rather than vani- ty metrics achieve multiple wins at the same time. They make reporting more effective, they avoid transcription issues that might occur if old reports and metrics stay in place, and they send clear message to the Agile teams that the executive ranks are se- rious about the Agile Transformation.

Agile Adoption and Transformation 343 Lack of empirical process control I have been part of countless Agile Transformation efforts where the end goals just were not clear. “Do that Agile thing”! “Coach team X.” Undertaking a massive Agile Transformation requires due diligence and serious consideration about how to measure success. Empirical process control is typically lacking. A myriad of agile techniques will be introduced, with no clear target. Teams will be asked to deliver faster, but nobody will take the time to do value stream mapping to understand where time is spent. Usually teams end up doing agile by following all prescribed motions, but productivity doesn’t improve. Empirical data is not gathered, analyzed, and dis- cussed. Consequently, true improvements remain elusive. Organiza- tional gravity is more likely to assert itself, and to bend change to the institution’s current will and shape. Executives must look for empirical evidence of improvement, and not reports or other promissory notes, to be assured that an agile change initiative is indeed “on course.” Enterprise agility really means empirical mastery of innovation at scale. Senior executives must spon- sor transformation across the enterprise, and advocate the empirical process control that always underpins agile practice. Project instead of product focus Most large organizations act like they are in the business of running projects. Documents are passed around that are promissory notes for some value as yet unevidenced and undelivered. Projects are by defini- tion temporary endeavors. They have a beginning, a middle, and an

344 Brian Will end. Much effort is expended in setting them up, monitoring their supposed progress in the absence of regular useful deliverables, and tearing them down afterwards. They are known to be a poor vehicle for sustaining the flow of value, and for retaining the institutional knowledge and team skills that allow value to be optimized. The latest agile mantra is to rethink the enterprise not in terms of projects, but rather in terms of the genuine products that allow value to be released and empirical lessons to be learned. Establishing a product-focused organization is undoubtedly a step forward to under- standing value streams of any type, and it is a significant improvement on project-execution mode. Senior executives should therefore take care to ensure that products rather than “projects” are being sustained, and that they are clearly owned and represented at all levels. Lack of executive change As mentioned previously, the CEO and executives cannot delegate the Agile Transformation effort. Nor can executives just keep doing what they are doing prior to jumping into the agile ice water. Are they prepared to get up, stop looking at reports, and see for them- selves what is really happening in the company? Are executives convinced that agility is a must for the company and consequently make Agile Trans- formation their top priority? Do they really want enterprise change? Are executives willing to flatten the 12-level organizational structure? Are they willing to challenge, and be challenged on, the very idea of what value means to the organization? Do they see the importance of flow, and the futility of making projections without empirical evidence?

Agile Adoption and Transformation 345 Reluctance of senior managers to change themselves is one big challenge for any Agile Transformation effort. CEOs beware—if you and your direct reports don’t fully buy in, the Agile Transformation effort will fail. Which brings us back to the blue pill or the red pill. The choice is yours.

CHAPTER 27 METHODOLOGY FATIGUE Not to quote Donald Rumsfeld, but too many companies never ever think about the “unknown unknowns”; they assume that Agile/Scrum is simply another development methodology, another fad, just like the others before it. After all, anybody who has done this for a while knows that after Waterfall came V-Models and iterative methodologies, then the Ra- tional Unified Process, various frameworks that testified to solve the world’s problem. So why should Agile/Scrum be different? Here is a quick refresher of the most commonly used development methodologies.

Agile Adoption and Transformation 347 Figure 98 - The Waterfall Waterfall The waterfall model is a sequential (non-iterative) design process, used in software development, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of concep- tion, initiation, analysis, design, construction, testing, produc- tion/implementation, and maintenance. The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impos- sible. Because it was created in a time when no formal software devel- opment methodologies existed, this hardware-oriented model was simply adapted for software development.1

348 Brian Will Figure 99 - The V-Model V-Model In software development, the V-Model represents a development pro- cess that may be considered an extension of the waterfall model. In- stead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the develop- ment life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.

Agile Adoption and Transformation 349 Figure 100 - The Spiral Spiral The spiral model is a risk-driven process model generator for software projects. Based on the unique risk patterns of a given project, the spi- ral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping. This model was first described by Barry Boehm in his 1986 paper “A Spiral Model of Software Development and Enhancement”.2 In

350 Brian Will 1988, Boehm published a similar paper to a wider audience.3 These papers introduce a diagram that has been reproduced in many subse- quent publications discussing the spiral model. These early papers use the term “process model” to refer to the spi- ral model as well as to incremental, waterfall, prototyping, and other approaches. However, the spiral model’s characteristic risk-driven blending of other process models’ features is already present then. Figure 101 - The IBM Rational Unified Process (RUP)

Agile Adoption and Transformation 351 IBM Rational Unified Process The Rational Unified Process (RUP) is an iterative software devel- opment process framework created by the Rational Software Corpo- ration, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, in- tended to be tailored by the development organizations and software project teams that will select the elements of the process that are ap- propriate for their needs. RUP is a specific implementation of the Unified Process. The RUP determined a project life cycle consisting of four phases (Inception, Elaboration, Construction, Transition). These phases al- low the process to be presented at a high level in a similar way to how a waterfall-styled project might be presented, although in essence the key to the process lies in the iterations of development that occur within all of the phases. Also, each phase has one key objective and milestone at the end that denotes the objective being accomplished. The visualization of RUP phases and disciplines over time is referred to as the RUP hump chart.

352 Brian Will Figure 102 - Agile/Scrum Agile Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.4 It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.5 These principles support the definition and con- tinuing evolution of many software development methods.6 The term Agile was adopted by the authors of the Manifesto for Agile Software Development (often referred to as the Agile Manifesto for short).7 As mention above, iterative and incremental software development methods can be traced back many decades. Evolutionary project man- agement and adaptive software development emerged in the early 1970s. During the 1990s, a number of lightweight software development

Agile Adoption and Transformation 353 methods evolved in reaction to the prevailing heavyweight methods that critics described as heavily regulated, planned, and micro- managed. A parallel technical development in software engineering that facilitated this discussion was the rapid adoption of PC technologies and the general adoption of object-oriented programming paradigms. Lightweight development frameworks or methodologies included: from 1991, rapid application development (RAD); from 1994, the unified process and dynamic systems development method (DSDM); from 1995, Scrum; from 1996, Crystal Clear and extreme program- ming (XP); and from 1997, feature-driven development. Although these originated before the publication of the Manifesto for Agile Software Development, they are collectively referred to as Agile soft- ware development methods.8 And these are just the big flavors! One could easily list 50 varia- tions, about 15 for Agile alone (XP, SAFe®, Kanban, TDD, etc.), which basically resulted in “methodology fatigue” across many industries. Also, be aware that each old methodology that was replaced by the most current one left behind a tail of methodology artifacts, sometimes referred to as “methodology junk.” Just like junk in the real world, these remnants are no longer useful, but they linger on. Some examples in- clude UML diagrams (specific to RUP), arcane ticketing systems that have waterfall built into the process, requirements documentation tem- plates that do not match the commonly used Agile/Scrum user story format, or management reports that reference metrics no longer relevant. The point is that oftentimes Agile/Scrum is adopted as the new methodology but it is expected that old systems and processes remain

354 Brian Will in place—often resulting in Agile/Scrum being forced into the old process framework—limiting the level of success that a new Ag- ile/Scrum process could actually deliver on. This is a typical scenario and usually ends with somebody commenting sooner or later that “…after all this Agile stuff, nothing changed; we still can’t get things done faster….” Which should not really be a surprise. Consequently, when companies start Agile/Scrum efforts they of- ten do not think through the challenges (“… yeah, it’s one of those new methodologies…”) and jump into the adoption with: • Lack of buy-in at the right levels – Agile/Scrum adoption only works if it is sponsored and supported from the executive level, top-down, and from the line level, bottom-up. The rea- son for this is simply that an extensive process and culture change represented by an Agile/Scrum adoption cannot be achieved by only forcing it top-down or by trying to stage a revolution bottom-up. Everybody has to buy into the process for it to effectively improve productivity. • Lack of professional transition support – “Start doing Ag- ile!” is a common battle cry trying to fast track the adoption, instead of starting an Agile/Scrum adoption process with a good pilot project and the assistance of knowledgeable Agile coach- es; start small and scale up virally by demonstrating success. • Lack of training – Both at the executive/managerial as well as at the engineering/line level, many companies do not train their employees about what Agile/Scrum actually means. Let

Agile Adoption and Transformation 355 me be clear: everybody needs to be trained on Agile/Scrum in order to make it work, and to guarantee that expectations are aligned; rinse and repeat training sessions frequently, with new hires and current employees, in order to solidify their under- standing. You know you have done a good job training the or- ganization when the CEO, the Director of HR, and the line level Tech Support Engineer can talk about sprints, user sto- ries, and retrospectives. • Lack of process review and adjustment – basically simply plugging in Agile/Scrum as just another methodology without reviewing and adjusting supporting systems or processes (such as management reports) will not work. Thoughtfully reviewing and streamlining the current process in a way to optimally uti- lize the benefits that Agile/Scrum requires a dedicated effort. • Lack of support for learning – Agile/Scrum assumes that teams “self-calibrate” and continuously learn. As such, Ag- ile/Scrum teams sometimes fail, and failure is a big part of learn- ing. If the company does not support learning this way, Ag- ile/Scrum efforts are doomed. Frequently, instead of embrac- ing failure as a way to learn, companies immediately start criticiz- ing the new Agile/Scrum approach as the most likely culprit. • Unrealistic expectations – executives, managers, and line level engineers often go into an Agile/Scrum adoption process with completely unrealistic expectations—all with different unreal- istic expectations, though! Executives expect magical produc- tivity gains in short order; managers often assume that Ag-

356 Brian Will ile/Scrum will not impact their functional responsibilities (nothing could be further from the truth); and engineers fre- quently hope that Agile/Scrum will mean the end to tedious analysis and documentation tasks—often a direct reaction to the previous methodology not having worked so well. Setting these expectations and creating a common understanding is imperative to success.

CHAPTER 28 LACK OF ORGANIZATIONAL REALIGNMENT The previous chapter covered methodology fatigue; this chapter will deal with the lack of organizational realignment. What does that mean? Why do you have to realign the organization to become more Agile? And what do you have to realign? There are really four main areas that require serious cross- functional and cross-departmental review when jumping into an Agile adoption process. These four areas represent core company processes, assets, and values that need to be adjusted for realignment if the Agile adoption process is to be successful. The reason we refer to them as core company values or established

358 Brian Will processes is because many companies, especially established ones, fol- low a set of practices without necessarily understanding why—the his- torical perspective and original reasons for doing things one way or the other have been lost. These are areas that impact many aspects of the business or the relationship between a company and its employees. Agile adoption oftentimes exposes all those challenges, so rethinking these areas is critical. So, what are the four main areas? They are: 1. Human resources 2. Facilities 3. Communications technology 4. Product & business strategy Let us review each in detail. Human Resources Human resources – especially job descriptions, career paths, and ca- reer development—completely ignores Agile/Scrum adoption consid- erations. HR usually ignores an Agile/Scrum adoption initiative (to their defense, most times nobody tells them!), while the Engineer- ing/Software Development organizations happily proceed to focus internally, as if there are no other considerations. But there are many HR-related considerations that, if not taken care of, seriously impact the long-term viability of any Agile/Scrum adoption process. For example:

Agile Adoption and Transformation 359 Reviewing functional organizations, their job descriptions, and ca- reer paths, you will find that many are based on older Waterfall/V- Model/Iterative models; you will most likely see job titles such as: • Technical Support Analyst I, II, III • Quality Assurance Engineer I, II, III • Product Manager • Program Manager • Sr. Program Manager • Software Engineer I, II, III • Software Architect • Software Project Lead • Team Lead • Test Lead Once you go into an Agile/Scrum adoption initiative, you will see job titles like this 1. Scrum Master 2. Product Owner 3. Developer 4. Agile Coach So, the core question is how to transition traditional jobs, such as Software Architect or Project Manager, to new Agile/Scrum job de- scriptions. The answer is: very carefully—you need to design the new

360 Brian Will job descriptions with great care considering the mode of operation that Agile/Scrum introduces. There is no standard list of job descrip- tions that will fit all companies, big and small. However, there are common themes to consider: 1. In order to redesign job descriptions, make sure to train HR on Agile/Scrum principles. Without basic knowledge of Ag- ile/Scrum, HR will be lost on how to go about this. 2. In Agile/Scrum, the team takes precedence over individual contributions. Job descriptions have to reflect the fact that some team member will primarily focus on making the team more productive instead of focusing on individual “quarter- ly/yearly accomplishments.” 3. Career progressions from junior to senior to principal still ap- ply, including training and cross-promotion opportunities. 4. Review current employees for their “fit” and assign them new roles. If people do not fit the new roles/job descriptions, lay out training plans to get them up to speed. In some cases you might not be able to transition people into key roles, so you might need to consider hiring new people with the right skill set. 5. Last but not least, you can backfill open spots temporarily with knowledgeable consultants, especially in roles focused on Agile/Scrum transition and training. The result of all this job description redesign is that you will most likely create “pods” of scrum masters, “pods” of team members, “pods”

Agile Adoption and Transformation 361 of product owners, and “pods” of specialists. Beware that in order to make this transition, you need to explain the logic and intention be- hind all this—meaning you need to explain, explain, and explain again. Do not assume that everybody is happy with the transition to Agile/Scrum, especially outside of core engineering functions. There are some job transitions that come more naturally that oth- ers. All of them require individuals to refocus from a “document- centric” world view, where things are documented and passed on to the team downstream, to a “communication-centric” world view, where folks work closely with each other to discover what needs to be built and resolve problems immediately. Here are some high level fits that have been observed: 1. Program managers make good scrum masters because they are used to running interference across multiple departments and are good at moving the teams along toward delivery. 2. Project managers often do not feel comfortable managing an Agile/Scrum project because they miss their tight-knit Phase Gate Approval Process and their Gantt Charts. This is not to be facetious here, just to point out that the author has ob- served many traditional project managers struggle with the Agile/Scrum approach. This is especially difficult for organi- zations that have large, established PMO groups, with heavy reliance on PMI certifications. Agile/Scrum upends much of the project management gospel that is preached. 3. Software team leads usually can play various Agile/Scrum roles,

362 Brian Will capable of acting as both scrum masters and product owners. 4. Software architects can act as product owners. 5. Product managers can act as product owners if they feel comfortable with the real-time elaboration process; product managers used to writing extensive Requirements Specifications Documents often struggle with the tight and straightforward user story format or the sprint-by-sprint refinement process. Please do not take these observations verbatim. You need to assess who fits what role for your specific environment. However, it is strongly suggested that organization stay away from “Wagile” (Wagile = Waterfall + Agile). Too many times one can come across job titles such as: • Project Manager/Program Manager/Scrum Master • Agile Project Manager • Scrum Master Manager • Program Agile Leader • Product Marketing Manager/Product Owner • Director of Engineering/Scrum Master • Etc. The above job titles are surefire signs your organization is on the wrong path in your Agile/Scrum adoption process! You are basically pretending that you can fold the new Agile/Scrum process into what- ever you already have, with minimal changes, and achieve stellar

Agile Adoption and Transformation 363 productivity gains. Unfortunately, it’s not that simple. Also, once you have redesigned the titles and job descriptions, do not forget to rethink and reassess your incentive programs—old mod- els do not work any longer. How do you incentivize “team orienta- tion”? Again, there is no magic list here that you can simply follow; your HR team and your management team need to put their thinking hats on to come up with creative solutions. In terms of incentive pro- grams, it is recommend to tie them to “business value created,” which is at the core of Agile/Scrum. Facilities Facilities – reconfiguring work space to match the Agile/Scrum pro- cess. This sounds simple but can be very challenging. When we talk about facilities, what do we actually mean? Basically how teams and people sit and work together, considering the optimal office layout, conference rooms, break rooms, rest areas—in general the best appropriate physical environment. Sad truth is that many companies miss the boat on this one. One reason is that tearing down existing office space and reconfiguring it is not that simple. The balance you need to find is between creating an environment that allows for open communication and flow of ideas while avoiding the trading floor style pandemonium that distracts software engineers from creating good code. Optimizing communication while maintain- ing a quiet work environment is the devil in this detail. One thing that has been observed to work is an environment with cubes, where team members sit in close proximity together while still

364 Brian Will affording the privacy of your own space. Combine this with lots of conference rooms, and you have the opportunity to create a work space that provides for open communication. Conference rooms need the latest communication equipment, vid- eo conferencing technology, and lots of white boards. Conference rooms need to range in terms of their usefulness from full-blown au- ditoriums to dedicated team meeting rooms to “phone booths” where people can step out to take a call. Also helpful is a mobile phone policy that stresses that it’s unac- ceptable to take your mom’s phone call next to the engineer trying to code up the latest device driver. Take the call outside; or even better, the company should provide enough conference rooms of abovemen- tioned “phone booth” size. What does not seem to work are “old style” office layouts that are based on functional titles—the bigger the title, the bigger the office. Fact is that oftentimes you do not have enough offices to accommodate eve- rybody, so cubicle setups are more common now. And, you need to plan for reconfiguring space as projects develop; Agile/Scrum office layouts are more project focused, not permanent. Again, it’s not uncommon to see decent office layouts that would make Agile/Scrum teams highly productive, but people refuse to move, resulting in team members of a new team being spread over multiple locations. This is really a manage- ment and expectation settings issue—if you work in Agile/Scrum teams, be prepared to move as you progress through projects. If you expect to stay stationary in the same cube for years, Agile/Scrum is not for you.

Agile Adoption and Transformation 365 Communications Technology Communications technology and communications approaches are often ignored. It cannot be stressed enough what big differences exist in productivity between companies that go all out with their commu- nication technology vs. the ones that try to save money. Here are some concrete examples: • WiFi connections – if your WiFi is slow, go and invest in the best possible WiFi solution you can get; nowadays, every Ag- ile/Scrum team member can easily have four devices that con- nect to the WiFi network, so saving here is counterproductive. • Internet speeds – get the fastest possible internet connection. • Poor VPNs – along the lines of poor internet speeds, VPNs frequently end up being too slow to enable effective work from home or while traveling. As with WiFi and internet speeds, companies need to bite the bullet and invest in the fastest VPN technology/configuration available. In terms of communication approaches, one must train all Ag- ile/Scrum team members to communicate in order of effectiveness (from 1, best, to 5, worst): 1. Face-to-face – nothing beats face-to-face communication. 2. Video conferencing – if you can’t meet face-to-face, video conferencing comes in second, but only if you turn on the camera! The face and body communicate most of the infor-

366 Brian Will mation in a conversation, so if you cannot meet face-to-face, video is the preferred second approach. 3. Phone – if you cannot see your counterpart, at least hear them live; again, the live voice communicates nuances that are im- portant to observe and understand. 4. Text – text messages/chat are preferable to email because you still have a live connection to your counterpart, although with- out a visual or audible way of discerning if your message is re- ceived or how your counterpart’s message was intended. 5. Email – the least effective way of communicating is written email or snail mail. You lose all immediacy. And email com- munication frequently turns a 5-minute discussion into a 7- day email thread. Product and Business Strategy You jumped into Agile/Scrum, you worked with HR to redefine re- sponsibilities and job descriptions, you tore down walls and reconfig- ured your work space; but did you think through all the necessary changes in your product and business strategy? Every business is different, but you really need to consider the fol- lowing areas in order to marry the Agile/Scrum benefits with the business: 1. Upgrade cycles, from yearly releases to on-demand, monthly, or quarterly software updates due to cloud technology, contin-

Agile Adoption and Transformation 367 uous integration, faster cycle times—how does that change your business? 2. Constant support needs – with faster release cycles, support models change. 3. Revenue generation – old, traditional models relied on differ- ent revenue generation models; how does a yearly upgrade model change to a subscription model? 4. Cloud technology – away from IT to hosted services; how does the cloud help you scale? Do most of your servers sit idle simply to deal with the Thanksgiving or Christmas business spike two days of the year? Do you save money by using the cloud or spend more? Agility changes everything!1 Thinking that Agile adoption was going to be easy is one of the biggest misconceptions of all! In conclusion, this chapter tried to show that there are many factors that influence and, in most cases, determine the successful outcome of an Agile adoption initiative—factors that have nothing to do with Agile/Scrum, the projects, the technologies used, the teams, or the pro- cess. But those factors have everything to do with how your organiza- tion accommodates the changes that are necessary to be successful.

CHAPTER 29 AGILE BURNOUT DEATH SPIRAL In many ways this pitfall is the easiest one to spot, and the hardest one to stop—because of the momentum that builds up with it. The Agile burnout death spiral is akin, and closely related, to what Ed Yourdon described in his classic, and still highly relevant book, Death March.1 Also relevant to this discussion is another classic by Frederick P. Brooks Jr., The Mythical Man Month: Essays on Software Engineering.2 These two books are timeless classics that describe common man- agement dysfunctions when doing software projects, and to a large extent explain why software projects are so costly and have such high cost and schedule overruns. So, what is a common Agile burnout death spiral scenario? Here is

Agile Adoption and Transformation 369 an approximation: 1. A project gets initiated – “We need to do XYZ; otherwise we <will lose market share><won’t be able to raise more mon- ey><will lose credibility with the business stakehold- ers><etc.>.” 2. Usually, right along with the project kickoff, somebody will announce a completion date that is completely devoid of any basis in reality. At this stage, scope has not been clearly de- fined; nor has the team been assembled to do any estimation of what is involved—“XYZ needs to be done by September 15th.” 3. A team is hastily assembled. A part-time project manager is dedicated as the scrum master, and the project start date is to- day. Because team members aren’t available, a mix of perma- nent employees that can be pulled off other projects, contrac- tors, and third-party consultants are assembled. This results in a geographically dispersed team across five different interna- tional time zones (LA, NY, Slovakia, Belarus, India). 4. As there is no knowledgeable product owner available, the VP of Marketing will act as the product owner whenever he has time. 5. Planning, user story definition, and estimation efforts start off chaotically, due to a lack of experienced team members who have worked with each other before and a lack of clear guid- ance from the product owner, who is barely available to pro- vide clarifications. 6. Time zone differences are the cause for major communication

370 Brian Will challenges, some of which the team members try to overcome by having late night/early morning conference calls. But coor- dination efforts are difficult, resulting in many questions and answers flowing through email, which causes major delays and in some cases misunderstandings. 7. Because of the preset end date (September 15th) the scrum master “backs” the sprint planning into the end date and loads up the sprints with user stories regardless of team capacity or realistic estimates. 8. Because sprint planning was driven by the end date and not by estimates, sprints come up short right away—basically the team is not able to deliver at the velocity necessary to achieve the sprint goals. 9. After missing several sprint goals, the scrum master discusses the possibility of slipping the end date. “It doesn’t look like we are going to make September 15th.” 10. Management panics and gives the go ahead to add additional resource and do “whatever it takes” to make the target date. 11. The scrum team grows to 29 people. 12. Instead of starting to deliver faster, velocity actually decreases, and confusion increases. 13. The death spiral spins out of control. After reading this, you must be asking “Why would anybody in the world do this kind of stuff?” The above set of bullet points probably have at least 20 cardinal sins that every scrum master and software ex-

Agile Adoption and Transformation 371 ecutive should be able to list. So why do things like this happen? Well, it’s a matter of perspective. Yes, sometimes management just does not know how to adopt to Agile/Scrum, and you can see dys- functional behavior like the ones outlined above simply because peo- ple do not know better. However, management sometimes is completely aware of the bad practices that are used; they often understand perfectly well that one, two, three teams will be burned out, people will be lost to resigna- tions, nervous breakdowns, and burnout. But the business end of achieving a certain goal at whatever cost might justify the means. There are always multiple sides to a story. Software engineers want to design the best software, in a decent work environment, on the lat- est technology stack, with all the relevant buzzwords to build up their resumes for the next job. Business stakeholders, on the other hand, often are not concerned at all how the solutions they are delivering are built as long as they are available on time. Business executives usually are date sensitive, quarterly driven, par- anoid about the competition, driven to get things out to market. Software engineers, on the other hand, are often completely devoid of any concerns about generating revenue or being profitable. Ultimately, the business question is this: “Is the instability that an Agile burnout death spiral creates in terms of employee turnover and burnout worth the risk in terms of potential future business?” For ex- ample, will this project give us an edge over our competition, position us in the market that makes us unique?

372 Brian Will What about the software engineers who are stuck in a death spiral project? Engineers will have to ask themselves if the experience they are gaining in terms of technical know-how, other skills acquired, and financial benefits outweighs the personal sacrifice that they have to make. For example, will this project make my 5,000 stock options worth $300,000? These kinds of death spiral projects happen all the time, some- times because of lack of knowledge, but sometimes deliberately, for valid business reasons. Oftentimes death spiral projects are early startup or new technology projects, where companies and teams go through a “forming—storming—norming” process. That is totally normal. Just beware of the companies that use this approach as the standard mode of operations.

CHAPTER 30 THE FIZZLE The previously mentioned Agile burnout death spiral is pretty easy to spot. Just as that one is easy to grasp and understand, the fizzle can be the more frustrating to interpret because the visible symptoms are not that easy to identify and understand. The fizzle is like a high school football jock who looks all promis- ing, bustling with raw talent, but then flames out on the way through college and never makes it to the NFL—you see all the great perfor- mances, you observe all the great plays, you can literally see the prom- ising future, but somehow the long-term success is denied. Here is a common scenario that shows how the fizzle often plays out: • Executive management hears a lot about Agile and Scrum and

374 Brian Will likes the idea of moving the organization into a more light- weight, productive, methodology. It announces its support by declaring “Let’s do Agile and get things to market faster!” • Development managers also like the idea of finally adopting Agile/Scrum, and developers had been arguing for years that the current process-heavy approaches slow things down. • The PMO organization is ambivalent about the idea, but re- luctantly supports it as long as “current PMO processes are still followed.” • Management dedicates a development team lead to take the lead in the new scrum master role and to assemble a team to deliver a pilot project. • After some discussion, a pilot project is picked. It happens to be a non-controversial project that might turn out be interest- ing, but nobody within the organization really has a stake in it. • Some of the best developers across the organization are as- signed to the team; not only are the developers all senior level experts in various technology disciplines, but they all also have significant domain knowledge, having all worked at the com- pany for more than 8 years. • A knowledgeable software architect with deep domain knowledge and years of integration experience with the diverse customer base is dedicated as the product owner. • The pilot project gets underway in dedicated office space, off the beaten track, and away from daily interruptions. The work environment and setup is close to ideal, allowing for teamwork

Agile Adoption and Transformation 375 and quick decision making. • Tools are selected, scope is defined, user stories are written, estimation poker is played, and sprints are defined. In short, the pilot is off and running. • Sprints last two weeks. • Sprint reviews show good progress. • Team velocity increases over the first four sprints to steady out around 38 story points; once stabilized, the project predictably delivers each sprint goal as promised, much to the surprise of observers. • Sprint retrospectives resolve obstacles quickly, increasing team productivity. • After 5 and 1/2 months, the project is delivered, with excep- tional quality, a full feature set, and apparently right on target with market demands. • During the final executive presentation, one VP of Develop- ment states, “This would have taken my team 2 or 3 years to produce; we should aggressively roll this Agile/Scrum thing out to the rest of the organization.” • Following the successful pilot, the company rolls out the “Ag- ile/Scrum thing” to the rest of the organization, but it does not adjust team structures, job descriptions, office setup, confer- ence rooms, telecommunication needs, or other critical sup- porting factors necessary for Agile/Scrum. • Whereas the pilot project was staffed locally, allowing for di- rect face-to-face interaction, the company decides to utilize

376 Brian Will two outsourcing partners in development center in Bangalore, India, and Saigon, Vietnam. • Existing processes, like a waterfall-oriented PMO process with excessive documentation and phase gate requirements, stay in place. Agile/Scrum teams are supposed to follow the old and the new processes. • Agile/Scrum roles like scrum master, product owner, and Ag- ile coach are not clearly defined. Consequently, various employ- ees with various backgrounds end up in roles they are not nat- urally suited for—as a matter of fact, functional job titles stayed the same, while Agile/Scrum job titles never were made official. • Two years later, during an executive review, the CEO openly says, “I don’t get it; the Agile/Scrum pilot was so successful, and now we seem as stuck in the mud as before. Productivity has not improved at all.” At this point, organizations frequently do one of two things: 1. The organization reverts back to their previous process and says “Agile/Scrum just isn’t for us” or “Agile/Scrum doesn’t work for our industry” or comes up with some other explana- tion. This is less common, as the organization has to openly admit to a failure. 2. The organization turns into an Agile/Scrum “zombie”— they keep using Agile/Scrum terms, tools, and verbiage but basically don’t follow Agile/Scrum (daily standup meetings