Going All In: Lessons Learned in Agile IT at Harvard Business Publishing

Transcription

1 Going All In: Lessons Learned in Agile IT at Harvard Business Publishing ELIZABETH ROSS, Harvard Business Publishing This paper covers the lessons learned from re- organizing the Harvard Business Publishing Enterprise IT department into six agile teams, after the first six months of the process. This paper is from the perspective of a member of senior management on what decisions did or did not go well and the impact they ve had on our transformation. 1. INTRODUCTION Harvard Business Publishing is a subsidiary of Harvard University. Our mission is to improve the practice of management and its impact in a changing world. Harvard Business Publishing is a product development organization, an e- commerce company, a book publisher, a magazine publisher, part of a higher education institution, and a professional services organization. We publish the Harvard Business Review, the case studies for the Harvard Business School, and we are the Harvard Business Review Press. We also sell course materials and course packs to other business school programs and universities and we develop software and lead learning programs for leaders and managers in companies around the world. In short, we spend a lot of time focused on promoting good management and learning best practices, and we're not afraid to undertake experiments and innovative practices to improve our organization. HBP is organized into three market units that focus on the external customers and products. Behind them is the Enterprise IT organization that manages infrastructure, operations, help desk, business systems, etc. We support anything internal, from content hosting to financial systems and reporting. Enterprise IT is the focus of this paper. In Enterprise IT, we've always thought of ourselves as a traditional service organization. What we learned as part of our agile transformation is that we are really a product development organization, only our "products" are the systems we support and the services we provide. In 2013, when I joined the company, we were working with functional teams pooled by resource type (e.g. developers, analysts, QA, etc.). When we launched a project or simply had to solve a maintenance ticket, we had to pull people from one or more of the pools to work on it. We saw a lot of inefficiency in hand- offs between the resource groups and lag times when one group could finish quickly but the next group didn t have anyone available to pick it up. For our projects, we saw that we were estimating the budget correctly but we were generally three months late in delivery. We also had a backlog of maintenance tasks but it was very difficult to get a decision on whether the work was really valuable (and should be prioritized) or not (and should be closed). In addition to our functional teams, there is a senior management team, consisting of the direct reports to the CIO and the CIO. I joined this team last year. As a senior management team, we began discussing how to improve the time to deliver and also how to identify and work on the most valuable work. In 2014, the Enterprise Information Technology department went "all in" with agile for the 40+ person organization in a full- scale reorganization. It included everyone from the interns at the help desk to the CIO. We reorganized how we worked internally and how we worked with our stakeholders. This experience report covers the goals of the change, the process of choosing the best methods for each of the six, new cross- functional teams, the efforts to train the teams and the stakeholders, the change from line managers to practice leads, and how we went about living into the agile principles. It is not an exhaustive report about everything that has happened so far. My goal in the report is to focus on key decisions, their intention, and then how they played out in our transformation. This report is also written from my own perspective and conveys only my personal opinions about the experience. I speak only for myself here, even when I am writing about the senior management perspective. Author's address: Elizabeth Ross, Harvard Business Publishing, 300 North Beacon Street, Watertown MA, 02472; Copyright 2015 is held by the author.

2 2. BACKGROUND I joined Harvard Business Publishing at the beginning of It is a great place to work and inspiring to be a part of an organization that takes the practice of management seriously. I love being a part of how that is applied when an organization undertakes such a major cultural change as an agile transition. Harvard Business Publishing has had a long history with scrum, dating back to the first Harvard Business Review article about it in 1986 in The New New Product Development Game (Takeuchi and Nonaka) but we didn t start adopting agile methods internally until mid One of the business units decided to use scrum for the next version of their flagship product: Harvard ManageMentor (HMM). They began working with an agile coach, training their product development organization, and also training the company s executive leadership about both the principles of agile methods and what to expect from these types of changes in an organization. Adopting scrum was a great success for that team and they were energized about the new way of working. Their enthusiasm was contagious. Within six months of the HMM team s start with agile, Enterprise IT offered a two- day introductory class on scrum and Kanban for project managers and other key employees in the company. It was intended to both provide more information about what was going on inside the company and also to give other groups enough information to try it themselves, if interested. The results were great to see. Within weeks, there were multiple Kanban boards starting in both EIT and the other business units. Based on this and the positive feedback from the HMM team, senior management for the Harvard Business Review group decided to use scrum for the redesign of hbr.org, the company s largest e- commerce site. At this point, the two largest product development projects in the company were playing scrum. Other groups were using Kanban on operations teams and for smaller projects. My boss, the CIO, was hearing enough about the benefits of the approach that we began to talk about what it would mean for Enterprise IT to become an agile organization and he brought together his management team with the agile coach to talk about Enterprise IT going all in. The Enterprise IT senior management team is the CIO, the Director of IT Operations and Services and me, Director of IT Business Systems. There are six line managers, two reporting to my peer and four to me. It works out to be about 40 people, including contractors, split fairly evenly between the departments of the two Directors. The senior management team leveraged the strategy framework from one of our books, Playing to Win (Lafley and Martin), in our discussions. What is our winning aspiration? we asked. The primary goal of the transformation was, to deliver the most valuable work more frequently. We agreed that the best place to start would be to reorganize the department into cross- functional teams organized around a portfolio of systems and services that they would support. Except for IT Services, which would remain a functional pool type team, the others would draw from each of the groups: Development, Analysis, DevOps, etc. Each of the cross- functional teams would also have a Product Owner who would own the business systems and be responsible for working with our internal stakeholders and the teams to establish what the work is and its value, per the scrum guide s explanation of the role. We also organized Senior Management into a team. We had been working individually on projects and managing our people. The three of us were brought together, along with the two functions that didn t fit into the cross- functional teams, into the senior management team. So the senior management team now included both the real senior management of the organization along with the Security Manager and the purchasing assistant. We felt it was absolutely critical to the success of the transformation that we also reorganize and learn to work as a cohesive team. I don t know if we believed our throughput would increase and that we would work on the most valuable work for the department, but we were aware that it is impossible to ask an organization to take on a challenge that you are unwilling to also do yourself. We also decided that all of the teams would be made up of our existing staff. Scrum Masters (or Agile Process Managers for Kanban) would be opt- in from the existing team members (i.e. volunteers). Our Product Owners were chosen by Senior Management from our existing Project Managers and Business Analysts. We brought in our Line Managers and with them assigned each of the people in the organization to one team (with two exceptions). We agreed that (1) people should not have to split their time across teams; (2) that initially everyone would have a home on one of the teams, although we might change or reassign people once everyone understood how big/small the teams really needed to be; and (3) all work would be done through the teams. We went to a matrix organization and the Line Managers became Practice Leads. They were still responsible for the development of people; they were no longer responsible for their work. Going All In: Lessons in Agile IT at Harvard Business Publishing: Page - 2

3 We presented the changes to the EIT organization. We recognized it as an experiment and that we would all be learning as we went along. We engaged the agile coach, socialized with stakeholders that we d take a productivity hit for six months, and we started the experiment. 3. GOING ALL IN 3.1 Scrum or Kanban? When we proposed the transition project, we didn't know which methods under the agile umbrella were going to work best for our department. We'd used Kanban in some operations teams and scrum on some projects, but we really weren't sure which would work for the teams and the stakeholders. It took us a while to come to consensus among senior management. Should we present one way or more? Should the teams choose for themselves? Ultimately, we decided to teach scrum and Kanban along with the agile values and principles and the teams would choose the one that suited them best. As senior management we were very aware that being prescriptive and directive was a problem. We did not want to tell teams they had to work a certain way (beyond the agile teams). We didn t want to set requirements on when teams had to be up and running, nor did we tell teams they had to improve velocity or cycle times by XX amounts. We really wanted the teams to be self- organizing and we did not want to get in the way of that. This meant each team defined its own rules, working with the Agile coach, around definitions of done, and its rules. We did reiterate the goal, to deliver the most valuable work more frequently, and that we were expecting teams to live into the scrum guide or the Kanban model and work on continuous improvement. We trained everyone in the department on both. With their coach, each team chose scrum, Kanban, or a combination. There were two key impacts from this decision: one involved scrum masters, the second involved Kanban Scrum Masters We didn't staff scrum masters (or Agile Process Managers for the Kanban teams). We proposed an opt- in approach. Teams could rotate or a single individual could volunteer and we'd provide coaching and training (both scrum master training and facilitation training plus extra coaching time with our coach). The individual was still a member of the development team too, scrum master was in addition to their other work. Unexpectedly, we had more volunteers than anticipated on some teams: three or even more people were interested in learning about the role. On other teams no one wanted to do it. We had left it to the teams to self- organize though, so we, as senior management, felt that we couldn t step in and direct the teams on this. We felt that this was one of the self- organizing challenges that the teams would learn to resolve on their own. Was this the right decision? It's hard to play when the scrum master doesn't know the rules and sometimes might even have an unconscious interest in breaking them. What does a team do if no one is suited to play the role or if no one wants the role? There are lots of introverts in IT and stepping forward to lead a team through an agile transition isn t something that everyone is comfortable taking on. We are also an organization that values competency; would that make team members nervous about stepping up? It is very difficult to step forward and risk failure, even when the agile model says that you should embrace it. Should senior management have stepped in and changed the teams to accommodate personalities? Should we have required teams to find a scrum master? Should we have brought in professional scrum masters from the beginning? Should we have brought the teams together and asked them how they wanted to solve the Going All In: Lessons in Agile IT at Harvard Business Publishing: Page - 3

4 problem? Our decision was to see what would happen and talked through it with our agile coach to see if simply continuing support would help the situation. What emerged was that while the teams learned the mechanics of scrum, they weren't living into the values, and in fact the mechanics weren't always complete. All of the scrum teams were holding their daily stand- ups, doing sprint planning, reporting out, and sticking to their sprint cadence. But there were struggles about who was responsible for what work. We d hear, Well the scrum master should do that, but the scrum master didn t agree (or didn t know) and so nothing would happen. The teams struggled to agree on when to ask for help from the agile coach and they also struggled with interpersonal challenges. For example, one person wasn t able to meet commitments but the team wasn t willing to have the conversation about it because they were afraid to hurt the person s feelings. After six months, the teams were still struggling to meet commitments (e.g. no team completed all of the story points it had brought into any sprint, averaging well below 80% of planned points per sprint) and people still felt that playing scrum was hard, without feeling it get easier, and there were still two teams that hadn t had anyone volunteer to try out the scrum master role. Senior management decided to try another experiment. We d hire two scrum masters, to cover the four teams, for three months. The proposal was to have experienced scrum masters model the behavior. They would work with the teams daily. Teams wouldn t have to reach out to the agile coach to schedule a session if they needed help. We included team members in the interview process for several reasons. The first reason was to socialize the candidates with them. Second, it was to gain additional insight on the candidates. We also included them to get their feedback about how the entire scrum master experiment was going and what the outcome should be. The staffing decision would be made by senior management. There were three possible outcomes to the experiment: (1) we would need a longer period before we could make a decision, (2) we like having an experienced scrum master (who also isn t a member of the development team) and we want to continue this model, or (3) we don t need another person in the team and it is okay to have people only partly dedicated to the role. At the time of writing, we are four weeks into the experiment. Speaking for myself only, I have learned that it doesn t matter how much I think I am communicating, I could do a better job of it and do it more often. When is it ok to extrapolate based on a smaller survey and when is an experiment significant enough that you need buy in from everyone before you start? Without intending it, some of the people playing scrum master took the experiment as a slight to their competence; a judgment on the job they d been doing. This was completely not what was intended. The experiment had been prompted by feedback we d heard from some people on the teams. However, we hadn t asked all of the people playing scrum master individually before announcing the experiment. This lead to hurt feelings at first. I have spoken with the team members who raised the concern about the experiment. Having the experienced scrum master on staff has been seen positively and constructively Choosing Kanban Going into the agile transition, we thought that most of the teams would choose Kanban. Based on the case studies and other groups we d talked to, it seemed like an IT organization that has a lot of maintenance and enhancement work would be a logical place for it. When it came to the choice, three of the teams chose scrum, and the other cross- functional team chose Kanban plus some elements of scrum. When closely examined, most of our work is not interrupt driven, with the exception of restoring service from outages; we and our stakeholders were just used to working through interrupts. The real key for the teams in making the decision was that we do not function in a first in, first out environment; we always prioritize the most valuable work. In the IT Services team (help desk services) their flow could be more of the first in, first out style. In the end, the teams that chose Kanban were IT Services, Infrastructure & Tools (more scrum- ban), and Senior Management. This section focuses on the Infrastructure and Tools team s choice. Infrastructure & Tools has the responsibility of supporting the company s infrastructure (data centers, network, etc.) and operational systems such as Active Directory, Office365, Box, etc. They are mostly systems that were supported either by the old Operations team or IT Services. By design, the new Infrastructure and Tools team was staffed with several members from those two groups. The team felt that the first- in, first- out approach of Kanban was more appropriate for the operational tasks that were unplanned, simply responses to requests or alerts. The team also had work that had to be prioritized, planned, and shaped as the team is responsible for about forty systems that need maintenance and enhancements. They chose to manage this type of work as stories, in a way similar to scrum. Going All In: Lessons in Agile IT at Harvard Business Publishing: Page - 4

5 The team started out remarkably strong. They spent more time than the scrum teams thinking through process and how everything would work because they had to build their process from the agile framework and could not adopt one approach completely. They spent a great deal of time talking through the work that was coming to them, cross- training team members, and focusing on how best to deliver the work. It was notable how quickly and well they got through many of the initial challenges the other teams struggled with. As time went on, the team struggled through several challenges not faced by the scrum teams. Operational (unplanned) tasks were taking up 80% of the team s capacity so only 20% was dedicated to planned work. This meant that the lead and cycle time for the planned work was very long. There was also the challenge of adding Work in Progress (WIP) limits when dealing with the different work types. Some felt that the planned work should be measured in stories, not lead/cycle time. The combination of types meant that the report- outs from the team were confusing to the stakeholders because there were no established metrics that could be measured over time. In meetings with the team and its stakeholders, senior management heard about the struggle of managing so many systems and their competing priorities as well as the difficulty in trying to balance both the Kanban style tasks with the need to complete planned story work. It would be difficult to identify this team as playing Kanban and although they are certainly leveraging many of the agile techniques and values they are not playing scrum. At the time of writing, the team has lost three of its six members to promotion or attrition, which requires to Senior Management to engage and determine what to do: should we rebuild the team? Is the work more appropriate in other teams? Should it actually be two smaller teams (one for infrastructure, one for tools)? We planned to meet with the remaining members of the team to talk through the options and get their input on what our new approach should be. 3.2 Senior Management as an agile team It was and is important for our department to be "all in" in the reorganization. For real change to take place, it can t just be direction from management to go do it. It has to be something we all believe is right. This meant that the senior management team was also part of the agile adoption process. We agreed to use Kanban with daily stand- ups, monthly retrospectives, and repurposing the monthly IT organization meeting as the team s report out. Our first board included a detailed process flow and WIP limits, very low WIP limits even, and initially we were very successful in driving down cycle times. Between the first and second report out, we d brought down the average cycle time by several days. We included the two IT team members who weren t on the cross- functional teams: the security manager and the purchasing clerk, and the three members of senior management. Our intention was to also function as an agile team and play by the same rules as the rest of the organization. We knew that reorganizations in which senior management hasn t bought in or is only playing lip service to the change won t really succeed. We knew that we wanted to communicate more and to be more transparent about our decisions with the department and to demonstrate to the teams that we were also posting our values and agreements, holding ourselves to a report- out cadence, being transparent with our results, and that working on continuous improvement through our retrospectives was critical for success. Knowing all that, there were still challenges. The first being that this wasn t a team focused on similar work. The security manager and purchasing clerk reported to one of the Directors so they were leveraging the board for management time with him. The senior managers didn t want to display or discuss work about personnel in the retrospectives with everyone present. The result was that what was on the board wasn t the most valuable work, just the work we could do together. Team members began missing stand- ups, we broke our WIP limits and didn t resolve the problem. We skipped report outs. After six months, we scrapped the approach and started again. We called our coach in to help us through the retrospective and came up with the following action items: Split the team: Security and Purchasing teams got their own boards so the senior management board was only for senior management. We agreed that everything goes on the senior management board. We broke the tickets into the specific work types that we commit to work on as a management team and we are tracking how much time spent on each. For example: We want to do a better job communicating so one of the work types is communication. We can now analyze where we are spending time based on the work types and determine if we are focused on the most valuable work. We have discussed additional experiments that aren t yet initiated: o If we divide up the key area of work for one person to focus on for a period, will we make more progress on the work identified as most valuable? Going All In: Lessons in Agile IT at Harvard Business Publishing: Page - 5

6 o How will WIP impact the work flow? Will it improve cycle time? Will it adversely impact the focus on the most valuable work? As the senior management team, we still have many questions on how to be more effective. Is it more important to focus on the most valuable work if that means delaying the work that came in earlier? How do we get more focused and still support our many teams and stakeholders effectively? 3.3 Working with Human Resources on a new way to evaluate personnel performance As you would expect, Harvard Business Publishing has a very well defined performance management system, with clear planning, competencies, and goals at the company, business unit, department, manager, and individual level. In our agile transition, we needed to align our new way of working with our existing system. We had taken managers out of the direct equation related to the management of work. Managers were responsible for the direct supervision and evaluation of the performance of individuals. How would they be able to give someone a fair evaluation when they were no longer supervising the work? We put individuals on agile teams: we wanted to reward the team as a whole so that the teams would think of themselves as teams and not focus only on their own individual successes or failures. So what should we do? Luckily, as part of our reorganization and the other teams who have adopted agile in the larger organization, Human Resources agreed to work with us on new ways of doing performance management. We undertook a series of experiments to understand what would work in our new environment and also align with the company s plans and structure Experiment one surveys If we are measuring the team s performance through their velocity or cycle time, how do we find out if everyone on the team is contributing to the output? How do the team members rate themselves and their colleagues in contributing to the team s success? Senior management introduced a monthly survey where the teams rate themselves and each other on how they feel each person is living into the values of the team (values determined by the team). This information is anonymously recorded and provided to the supervisors. We expected to see a trend over time as the team's mature that they will get higher and closer ratings. If that doesn't happen, we'll know the team needs more coaching or other action. If it happens for most of the team but not all, we can coach specific individuals. Leveraging the anonymous survey was intended to give people an outlet for help if they didn t feel they could discuss a problem in the retrospective as well as giving us data on how the individual team members felt they were performing. It wasn t exactly scientific but it also wasn t anecdotal or based only on individual conversations Experiment two team goals Each team has goals, agreed to with Senior Management, for each fiscal year. The goals may be a subset of the goals set for the unit as a whole but they may also be different, as proposed by the teams. For the first year, senior management provided an initial list for discussion and agreement. At HBP, goals are usually tied directly to the company s bonus program. For this experiment, they are not tied to the bonus program. Based on what we learn we may propose that to Human Resources in the future Experiment three 360 degree survey of senior management At the time of writing, we are in the process of adding this survey. We believe we can do a better job for the teams and team members and we want to get at how we can provide more value to them. Thinking of Senior Management as an agile team and the EIT organization as a key stakeholder, how do we learn to provide them with better service, quality, value? The survey is intended to be a regular thing so we can measure change over time. 4. WHAT I HAVE LEARNED In Managing Oneself (Drucker), Peter Drucker suggests that before making a major decision, write down your intention. Do it before the decision so you aren t able to rationalize a bad decision away later. In six months or nine months, look back on what you wrote and ask yourself if the decision had the intended results. I would suggest that for any senior management team undertaking an agile transition that they follow Drucker s advice. I would like to be able to look back on the intention for many of the decisions and communications I made during the transition and then use them as data points in later retrospective sessions. Did this decision actually meet the intent? Did this communication lead to the intended results? Did it have the intended results yet they weren t actually the right results? Did the intention and the results align? Going All In: Lessons in Agile IT at Harvard Business Publishing: Page - 6

7 We work for a mission- driven organization that is focused on improving management and yet we, as a senior management team, have still managed to be surprised by the unintended results of our decisions. Despite coaching, a thoughtful decision- making process, and great support as well as a very open and eager organization, we were able to make mistakes. Being open about them and willing to try something else or try again is something that we can all do better and it is something I am working on particularly. Looking back, some things are obvious to me now that weren t at the time. I may have a different opinion about them in another six months but these are the things I think I would do if I were giving advice to someone else about to start an agile transformation: Start with experienced scrum masters, even when it is hard to bring new people into the organization or convince management of the need for funding/headcount. If people want to opt- in, make it full- time and make sure they can overcome the cultural baggage of the organization s old way of doing things. I believe we made the right decision empowering the teams to choose the agile method that would work best for them. Either Kanban or scrum would have worked for our teams. The key wasn t about which method they choose but all of us focusing on continuous improvement after the decision is made. We should have started with 360 degree feedback to senior management from the beginning in a way that the organization would feel comfortable doing. Organizing the senior managers into an agile team was absolutely right. Even though we have been struggling with this in execution, it has made a significant difference to how each of us is able to communicate about the changes and challenges within our department and stakeholders and each other. Hire an agile coach to help. I don t know what we would have done if we had tried this without one or even if we had chosen a less- able coach. Changing our performance management approach is still a work in progress. Evaluating it, trying some experiments, and thinking through what may have to change here to reflect our new method of working is incredibly important. Going all in. Embracing agile and undertaking the transformation of the organization was the right thing to do. I have focused on the challenges of the changes in this paper and not on the feedback from EIT s customers about it. We are making great improvements in delivery and quality and process and our customers are responding to that. Is it where we want to be? Not yet. We want it to feel easy- - for our teams and for our stakeholders. After a long climb up- hill, there s that moment when you jump off the peak and soar. I hope we are approaching that moment. 5. ACKNOWLEDGEMENTS I would like to thank Harvard Business Publishing and my colleagues in Enterprise IT for this incredible experience and all of their support. I would particularly like to thank my boss, Jason McNamara, as well as Ken Griffin and Susan Webber who all read and reviewed this paper as well as working with them through the entire reorganization process. I would also like to thank our agile coach Frank Saucier, from FreeStanding Agility. Finally, I would like to thank Susan Burk from Top Five To Seven, LLC who has been my shepherd through writing this paper. I am incredibly grateful. REFERENCES Bose, Indranil, Huang, Ming-Hui, and Huang, Minyi. Jharna Software: The Move to Agile Case Study, December 2014 Buckingham, Martin. Most HR Data is Bad Data digital article. February, 2015 Drucker, Peter F. Managing Oneself Harvard Business Review, January 2005 Gothelf, Jeff. A Better Project Model than Waterfall digital article. July, 2012 Harvard Business Publishing. Corporate Brochure. Lafley, A.G. and Martin, Roger L. Playing to Win Harvard Business Review Press, 2013 Reinertsen, Donald and Thomke, Stefan. Agile Product Development: Managing Product Development Flexibility in Uncertain Environments Case Study, December, 2014 Going All In: Lessons in Agile IT at Harvard Business Publishing: Page - 7

8 Rhea, James. Just in Time Production Controlled by Kanban Case Study, January, 1984 Schrage, Michael. A Testable Idea is Better than a Good Idea Digital article, December, 2014 Spreitzerland, Gretchen and Porath, Christine. Creating Sustainable Performance Harvard Business Review, January, 2012 Takeuchi, Hirotaka and Nonaka, Ikujiro. The New New Product Development Game Harvard Business Review, January, 1986 Going All In: Lessons in Agile IT at Harvard Business Publishing: Page - 8