For the better part of the last 20 years, I have worked on the business side of the great divide between IT and the business. My experience working with IT professionals ranges from strong strategic partnerships to hostile and deliberately antagonistic politics. Reflecting on both the good and the bad times, I have identified several patterns that I believe are critical to enabling the trust required to grow true partnerships. Taking my cue from such business storytellers as Patrick Lencioni, Eli Goldratt, and Gene Kim, what follows is the tale of a business executive with no IT qualifications, who in a strange twist of fate ended up leading an IT department at one of Australia's largest companies. This may sound like an unlikely story, but as Mark Twain once said, "Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't."
WORKING WITH IT: THE GOOD, THE BAD, AND THE UGLY
My early experiences working with IT professionals were very positive. In my late teens and early twenties, I worked for a small but successful market research company with an IT department of one. That one IT guy was endlessly patient with me as I riddled him with questions about the software packages we used. He always had time to explain to me how things worked and encouraged me in my quest for knowledge. This pattern recurred as I moved from one company to another, until I first encountered the world of enterprise IT. These "IT guys" were a whole different breed. They played hardball. Their motto appeared to be "take no prisoners." Working with them was a continual struggle.
There were, of course, a handful of exceptions -- open, transparent relationships based on trust, where we truly felt like we were "in it together," both bailing water out of the same sinking boat! By pooling our energies into delivering the best possible business outcomes, we could leverage the strengths of both the IT and business organizations to remove blockers. We never blindsided each other. We forewarned each other about imminent escalations, even sometimes colluding on escalations to put pressure on organizational constraints that were impeding our ability to deliver results.
Reflecting back on these relationships, I believe that the trust we formed was born from mutual respect. We understood each other's areas of expertise. We were respectful when challenging each other's point of view, and we were not afraid to speak our minds. Some of this was probably good luck as well as the right combination of personalities and intellects. In my view, these relationships were helped along by periods of colocation. The closer we were physically located, the stronger the relationships were. I cannot speak highly enough of the power of business people being colocated with their IT partners. Often this requires business leaders and their teams to relocate to be, as management author Jurgen Appelo puts it, "closer to the work that is important to them." 1
Unfortunately, colocation was not enough to prevent one of the most hostile environments I had the misfortune to experience. The deeply ingrained culture of deflection and blame seemed to be immune to the collaborative effects that normally accompanied proximity. 2 More energy was invested in defending the status quo than in delivering business outcomes. Determining fault was at the heart of every disagreement, scope change, schedule slippage, and cost overrun. Without exception, the number one issue on every project status report was "lack of business engagement." If the technology team made a mistake and couldn't blame the business, the vendors would be next in the line of fire. To add insult to injury, the antagonism almost never resulted in business outcomes being delivered.
AGILE AS THE ANSWER
The environment was toxic, but blaming IT was getting me nowhere. If I wanted things to change, I needed to step up to the plate and take responsibility. After all, it takes two to tango. I might have been "just the business sponsor," but I also had a commercial and ethical responsibility to the organization to ensure the capital investment in the projects I was sponsoring delivered the promised benefits. Sitting back and blaming IT for all our combined failures was not going to help anyone; we needed to find some common ground.
While my IT counterpart and I didn't agree on much, we did agree that the corporately mandated systems development lifecycle (SDLC) was not working for us. We also agreed that we needed a more iterative approach, customized to suit our context. We even agreed that the answer was Agile; unfortunately our definitions of Agile were poles apart.
Beginning to Close the Gap
We took our combined leadership teams on two days of Agile fundamentals training, and I walked out hopeful that Agile was going to improve both the business-IT relationship and our delivery outcomes. Imagine my surprise when, a few days later, half a dozen Agile "coaches" arrived on the scene to support IT. I was so baffled. I can clearly remember asking the corporate Agile enablement team if I had misunderstood the bit about Agile being a more business-aligned approach to delivery. Despite this disconnection, the transition to Agile did start to close the gap between IT and the business.
The first lesson we learnt was trust the team. It was the practice of Agile estimation that enabled this first shared learning. Our first Agile project had originally been scoped and estimated using our traditional SDLC. When the Agile team estimated the same scope using estimation poker, the projected cost and time frame doubled. This was alarming for both the business and IT teams. Initially there was some talk about interrogating the team with a view to reducing the estimate. In the end common sense prevailed, and we knew we had to collectively bite the bullet, accept the team's estimation, and progress our Agile experiment. This first leap of faith was rewarded with the slow but steady building and demonstration of working software. For an organization that had previously struggled to deliver, the regular showcasing of the capability as it was evolving started to build trust. The teams were making commitments and delivering on them. It is so much easier to trust people who deliver on their promises.
The second lesson we learnt was the value of understanding the environment that our collective teams were expected to operate in. As management guru W. Edwards Deming said, "The workers are handicapped by the system, and the system belongs to the management." 3 While I realize Deming was referring to the organization as a system, in this particular case, the teams really were handicapped by both the organizational system and the physical system. When this first pilot project deployed to production, performance was dismal. The software that had worked so well in the development and test environments no longer performed. Sadly, this was not the first time a project had struggled once deployed to production, but it was the first time we had tried to build a solution collaboratively and regularly demonstrated our collective progress to the CxOs.
Joint Problem Solving
This more transparent approach to delivery was game-changing when it came to addressing postdeployment issues. There was no time for pointing fingers and assigning blame; what we needed was a fix -- and fast! Two streams of activity kicked into gear: one focused on what could be done immediately to enable the capability to be rolled out to the business and the other focused on understanding the root cause of the problem. Within a couple of weeks, a solution to the immediate problem was proposed for discussion. In a strange twist of fate, the solution included using a technology that the business had been wanting to use for a number of years but the architects had viewed as technically undesirable. The root cause turned out to be a number of systemic issues with the physical application, such as an overcomplicated overnight batch schedule that ran 24x7 and a fundamentally flawed approach to version control. These problems were not new; it was likely they had been the root cause of a number of previous failed projects such as the aforementioned waterfall one. We just had been too focused on assigning blame to spend time understanding the problem.
Inspired by our modest success, we continued to launch Agile projects. The timeboxed delivery cycles and short-range planning horizons enabled everyone to understand how the work "worked," in a manner that had never been apparent before. Impediments that had been present in the system of work for years started to become clear to both the IT and business sides of the organization. In addition to the practices already mentioned, Kanban-style visualizations played a key role here, especially when I got introduced to the concept of "going to the gemba." 4 (The practice of the gemba walk was developed by Taiichi Ohno, father of the Toyota Production System. The idea is for leaders to "go to the place where the work is done" and see it with their own eyes.) By visiting the development teams and asking them to explain their work to me, I could start to see the non-value-adding waste riddled throughout the system of work. Reams of documentation and heavy, slow technical governance dominated.
Agile had opened up the IT organization to me and the broader business in a way we had never previously experienced. We were welcome and encouraged to attend daily stand-ups (as chickens, 5 of course). We could visit team spaces and talk directly to the delivery teams about how things were going. Team members could communicate directly to us the challenges they were having. This new style of communication was invigorating.
Unfortunately, some of my IT colleagues were less comfortable with the level of unfiltered dialogue between the people doing the work and the people sponsoring the work. It didn't take long before one of the teams got told off for being too transparent with me. I was mortified. The last thing I wanted to do was get anyone in trouble. It would be a number of months before I was prepared to try going to the gemba again.
WELL, THAT WAS UNEXPECTED
Approximately one year after our first foray into Agile, an organizational restructuring resulted in me, a business person with precisely no IT qualifications, being invited to lead the same IT organization I had been the primary customer of for the past five years. Personally, I was not convinced this was a great idea. While I was passionate about Agile and the technology we worked with, I was by no means qualified to be the general manager of an IT department of over 150 people. However, I figured this was a once in a lifetime opportunity. It is not every day that a business general manager is invited to lead an IT department.
The day my appointment was announced, my predecessor accused me of being a "poacher turned gamekeeper." This did not sit well with me. After almost 20 years in senior leadership business positions, it seemed unlikely to me that my perspective would change overnight. He was quick to provide advice on how to be a better "gamekeeper," but I wasn't interested. In my view, my mission was straightforward: improve the organization's ability to reliably and sustainably deliver business outcomes. Neither poachers nor gamekeepers had a place in this equation.
I suspect my lack of experience in traditional IT project/program management was actually an asset. I had not been indoctrinated in Prince2, PMBOK, or ITIL. I was not technical. I didn't code. My sole value to the organization I now led was my ability to make it easier for the people who do the work to deliver to our customers. My only qualification was my years of experience as a customer of the process I was now responsible for. My perspective was what systems thinking author John Seddon would call "outside-in," a position that makes it easier to identify waste and opportunities for improvement. Thankfully, as Seddon observes, "The job of management is to make the work 'work' better." 6
"Riding That Train ..."
My going-in position was to challenge everything and, as martial artist Bruce Lee counseled, "Use only that which works, and take it from any place you can find it." 7 To date, what had worked was Agile. So my first order of business was to cease outsourced, offshore, waterfall development and transition the organization to using Agile as its only delivery approach. While Agile had been working better than anything else I had experienced, we were going to need to improve our Agile implementation if we were to reliably deliver business outcomes. Having read Scaling Software Agility 8 by software methodologist Dean Leffingwell, I was inspired to reshape the organization as an Agile Release Train. 9 (This is a long-lived team of Agile teams, of 50-150 people, aligned to a common vision and mission, working from a single backlog on a common and synchronized cadence.)
A side effect of a successful Agile Release Train is the birth of a one-team culture. As marketer Seth Godin states in his book Tribes, "Human beings can't help it: we need to belong." 10 One of the outgrowths of labeling people "IT" or "business" is the way it reinforces people's sense of belonging to those groups. The virtual team of teams making up an Agile Release Train helps organizations move away from the idea of business and IT as separate entities and toward becoming one team with an all-inclusive sense of identity. One way to reinforce this sense of identity is to give your Agile Release Train and its teams names and symbols, just as professional sports teams have. After all, as Appelo observes, "It is very hard to have a sense of belonging to a community when the community doesn't have a clear name or image." 11
My first Agile Release Train had a train theme, and each carriage (team) was named after something train-related, such as Soul Train, Hyperloop, Green Hornet, and Astrotrain. Another train I worked with took the name StAART (see Figure 1), a reminder "to start where you are" and an acronym for the value stream they support.
Figure 1 -- The StAART mascot.
My time as an IT general manager eventually led me to enter the world of management consulting. With this change came new opportunities to expand my application of Leffingwell's Scaled Agile Framework (SAFe), a free, online knowledge base of proven success patterns for applying Lean and Agile development at enterprise scale (see Figure 2). 12 As I launched more Agile Release Trains, SAFe continued to resonate with me. It contained many principles that fostered the sorts of behaviors I had learnt were key to building successful partnerships between the business and IT. In particular, the regular cadence of all-hands release planning meetings, with full participation from all the IT and business people with an interest in the outcome, reinforced the notion that we were all in it together. Business executives sharing their vision created shared understanding. Collaborative planning using Agile estimation techniques provided transparency, enabling all parties to trust the teams. The management problem-solving sessions created opportunities to find common ground, and the process of "ROAMing" 13 risks provided the perfect platform for leaders to take responsibility. Of course, all of this was underpinned by teams making commitments to reliable delivery and then delivering on those promises. 14
Figure 2 -- The Scaled Agile Framework.
The Value of Vulnerability
These days my world revolves around helping IT and the business to bridge the great divide. I have found time and again that the number one enabler of trust is the transparency shown by the leadership on both sides. Of course, that is easy to say, but living it is a whole different matter. Transparency takes vulnerability, and vulnerability is tough. Vulnerability researcher Brené Brown once tweeted that this phenomenon is "The vulnerability paradox: It's the first thing I look for in you and the last thing I want you to see in me." We trust people whom we see as human and fallible, but we perceive these same traits as weaknesses in ourselves.
On multiple occasions I have had the privilege to witness the power of leadership vulnerability in closing the gap between IT and the business. Recently, I watched in awe as a business leader stood in front of a large combined IT and business team and spoke to them about her struggles with the changes taking place in the business and her commitment to making them work. On another recent occasion, a usually serious IT director dressed up as Santa and read out wishes from both the IT and business teams. These simple acts may be personally difficult, but they are also infinitely rewarding in breaking down the barriers between IT and the business.
FREE YOUR MIND (AND THE REST WILL FOLLOW)
In conclusion, as Seddon says, "Unless you change the way you think, your system will not change, and therefore, its performance won't change either." 15 The "great divide" exists because we let it exist. We can bridge it or even eliminate it altogether if we choose to. This change will not be easy. Our current worldviews have been influenced by our previous experiences. The more we are aware of this, the better placed we are to challenge our existing perceptions and assumptions. 16
There were many people who thought it unlikely that a business leader would be successful as the general manager of a struggling IT organization. Certainly no one thought that I would be more successful than the many far more qualified IT managers who had gone before me. Perhaps I was just lucky. Or maybe it is possible that a change in perspective was what was needed. In the words of Decisive authors Chip and Dan Heath, "Success emerges from the quality of the decisions we make and the quantity of luck we receive. We can't control luck, but we can control the way we make choices." 17
ENDNOTES
1 Appelo, Jurgen. #Workout: Games, Tools & Practices to Engage People, Improve Work, and Delight Clients. Happy Melly, 2014.
2 Appelo (see 1).
3 Deming, W. Edwards. Out of the Crisis. MIT Press, 2000.
4 For the full story of my introduction to the gemba, see www.prettyagile.com/2013/07/leading-through-vulnerability.html.
5 There is a long-running joke in the Agile community about a chicken and a pig that is often used to illustrate the different roles of people involved in a project. It goes something like this: A pig and a chicken are walking down the road. The chicken says, "Hey, Pig, I was thinking we should open a restaurant!" The pig replies, "Hmm, maybe. What would we call it?" The chicken responds, "How about 'Ham-n-Eggs'?" The pig thinks for a moment and says, "No, thanks. I'd be committed, but you'd only be involved!" Members of Agile teams are often referred to as pigs, while their business stakeholders are considered chickens.
6 Seddon, John. Freedom from Command and Control: Rethinking Management for Lean Services. Productivity Press, 2005.
7 Lee, Bruce. Tao of Jeet Kune Do. Black Belt Communications, 1975.
8 Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley Professional, 2007.
9 For a more detailed explanation of how this Agile Release Train was shaped and launched, see www.prettyagile.com/2014/03/launching-agile-release-train-while.html.
10 Godin, Seth. Tribes: We Need You to Lead Us. Portfolio Hardcover, 2008.
11 Appelo (see 1).
12 The Scaled Agile Framework can be viewed at www.scaledagileframework.com.
13 ROAM stands for Resolved, Owned, Accepted, or Mitigated. When "ROAMing" risks, the intent is to assign each risk to one of the four categories.
14 For a more detailed example of a SAFe Agile Release Train Planning Meeting, see www.prettyagile.com/2014/09/SAFe-ART-PSI-release-planning.html.
15 Seddon (see 5).
16 Covey, Stephen R. The 7 Habits of Highly Successful People. 25th anniversary edition. Simon & Schuster, 2013.
17 Heath, Chip, and Dan Heath. Decisive: How to Make Better Choices in Life and Work. Crown Business Books, 2013.
