No Way! Agile in the Federal Government

download No Way! Agile in the Federal Government

of 7

  • date post

  • Category


  • view

  • download


Embed Size (px)


Agile in the Federal Government. An experience report from an Agile Coaches perspective on transforming a government group, one organization at a time. Presented at Agile 2014.

Transcript of No Way! Agile in the Federal Government

  • No Way! Agility in the Federal Government BRANDON RAINES, AGILE COACH, BLUE COLLAR OBJECTS JUDY NEHER, AGILE COACH, CELERITY TECHNICAL SERVICES There are so many challenges that organizations face. Healthy organizations continuously tool and re-tool themselves to go from good to great. This paper will describe the road taken to transform a major government organization using Agile, Lean and Scrum principles, practices and techniques. From the contracting process to initiating, executing and closing projects, to redesigning the physical workspaces, and moving from a matrix to a team centric structure, this organization completely re-tooled how it did business, for the better. 1. INTRODUCTION Let us introduce you to The Organization...which we will affectionately refer to as ORG for the remainder of this paper. ORG is a fairly autonomous organization within a federal government agency which operates like a business. What this means is that ORG only initiates projects when external federal government customers (who well call GOV) hire them to develop small to medium sized applications meeting specific requirements and financial parameters. ORG is composed of Project Managers, Developers, and a smattering of Specialists who perform requirements gathering, testing and administrative duties on a part time basis. Requests to develop a new software application can come from any part of GOV. ORG is seen as a low cost, fast way to build small to medium sized software applications without the overhead of going through a Request for Proposal (RFP) process. ORG has mixed membership comprised of both contractors and government staff. Though ORG has the ability to ramp up and down its contractor workforce when it sees fit, this is rarely done since the work flows in on a steady basis. In the past, once a request from GOV was given to ORG, an ORG Project Manager (PM) was assigned to gather requirements, scope the project with a schedule and dollar amount, staff the project with people from across ORG and then execute the project to completion. Developers were almost always assigned at least 3 to 4 projects concurrently. While this model worked to some extent, there were frustrations, failures and an increasingly bad reputation was being developed across GOV. The Program Managers and the ORG Director knew that planning for projects was too unpredictable, error prone, frustrating and confusing. Canvassing the stakeholders reveals the following concerns: Josephine, a PM in ORG, feels yet again distraught that she cannot find a developer to work on a new project that has been accepted by ORG from an anxious GOV customer. George and Jean, ORG Managers (the leaders for ORG), are in Jean's office for the third time this month trying to figure out how much time Jack, a Java developer, will be able to work on both of their projects. Jean struggles to figure out objectively what capacities Jack, as well as the other developers in her organization, have at any given time. Martin, a GOV customer, is furious that his project has to secure additional funds to finish his most important needs for the product. Martin is one of many customers who have had to make a decision late in the schedule to determine whether they should continue to fund the projects they've contracted or stop the project at once. John is a new developer in ORG and is confused and frustrated because there is no standard way of producing a software build in ORG. To make matters worse, each of the different software build incarnations are manual, labor intensive and error prone. Rob, the Chief Technology Officer (CTO), feels ignored because yet again the technology staff has not been involved in the technical scoping of another project that has been driven off the technical rails. Author's address: 11216 Waples Mill Rd. ste 102A fairfax va 22030; email: Author's address: 4353 Stevens Road Centerville, IN 47330; email: Copyright 2014 is held by the author(s).
  • No Way! Agility in the Federal Government: Page - 2 Thank goodness for Jason, an ORG Program Manager!! He heard about another software group within GOV that had transformed itself after having faced similar challenges by bringing in a team of Agile coaches. These Agile coaches were allowed to be neutral parties that helped that group define the challenges in objective terms, develop a plan to help address the challenges and coach the group through those challenges until they were no longer needed. OK, said ORG, Great idea! Lets hire some Agile Coaches!! Thats where we, Brandon and Judy come in, your friendly authors and now resident Agile Coaches for ORG. While the names have been changed to protect the guilty (except for Brandon and Judy, of course!), the above represent some of the real-life challenges the coaches faced when they arrived in ORG. By using Lean, Agile and Scrum principles and techniques, Brandon and Judy set ORG on a road to higher productivity and business-valued results for its customers. Lets go on a journey, one that would last over a year, through the story of ORGs transformation, and well show you where we hit bumps, took detours, and sometimes even took the scenic route! 2. THE TRANSFORMATION TEAM Once aboard, one of the first suggestions the Coaches made was to ask the leadership of ORG to form a Transformation Team (TT). This group would be charged with developing a transformation strategy for ORG. The TT would set the stage for everything that followed for ORG. It would serve as a visible beacon of change and send a clear message to the entire ORG that leadership was behind this change for the long haul. This approach would also provide an opportunity for those in the TT to develop some empathy for the change that would be felt by the rest of ORG. The TT consisted of the Program Managers, Chief Technology Officer (CTO), architects, and the Agile Coaches. The TT decided to use Agile concepts to organize itself and execute a Vision, Roadmap and Releases. The roles were as follows: George and Jean were Product Owners (POs) and TT Delivery Team members. Rob & his team of architects were part of the TT Delivery Team. Brandon and Judy were Scrum Masters (SMs) as well as Delivery Team members. The rest of the ORG acted as stakeholders and end users. The first order of business was to train the TT by holding a bootcamp session. During this session, Brandon and Judy gave the TT an overview of Agile, Scrum, eXtreme Programming and Lean principles as a way to level set on the basics. In addition, the bootcamp provided a way for the TT to start going through Forming, Storming, Norming and Performing1 steps. The TT solidified the membership, roles, responsibilities and structure in which it would operate. Most importantly, the TT developed a Vision for the ORG Transformation. Simply stated, the Vision was: For ORG, The Transformation Team will be working to uniformly transform ORG processes to incorporate Agile principles and practices. The Agile Team will be collecting, prioritizing and executing new techniques and removing impediments in order to realize a more Agile ORG thereby delivering software products to its customers with the right price, within the time they need those products, and with the features they need with the highest of quality. Using the Vision as a guidepost, the TT developed a series of organizational goals for the transformation. These goals effectively were fodder for the Teams Roadmap2. This Roadmap described releases3 complete with release dates and goals for each release so that the TT forced itself to work within a deadline but also understand that there were important things to accomplish as markers. Therefore, the destination was as 1 Bruce Tuckmans Model Stages of Group Development 2 The Roadmap detailed the sequence of steps, complete with dates and milestones, that the TT would take to achieve the Vision. 3 Each Release contained more detail about the organizational goal (effectively, smaller steps that needed to be completed to each the larger goal).
  • No Way! Agility in the Federal Government: Page - 3 important as the time factor. Armed with a Vision, Roadmap, a defined team and a desire to do good, the TT set off to start with its first Sprint. But as the TT got going... 3. I WANT OUT OF THE MATRIX Both Josephine (remember our PM?) and Jack (our developer) continued to express their frustrations to Brandon and Judy around project support. Things had certainly reached a boiling point...they really wanted to stop the practice of flowing people to work, instead of the reverse! Flowing resources (actual people!) to work caused angst: Complex and Expensive! Forming, storming, norming, and (never really) performing came at a large cost, both in terms of time and dollars. No measure of how much work a team can complete in a given sprint! The teams never developed a consistent velocity. Planning was difficult and inconsistent! It was clear that moving to a more team-centric organization would help relieve some of the pain. While there were those who saw that a team-based approach had its merits, a large majority of the organization was resistant to change. 4. LET THE PILOTS BEGIN Brandon and Judy were concerned about the effects of change overload as well. They had learned their lessons regarding too much change, too soon, earlier in their careers as Coaches and thus suggested that ORG run a series of pilots. The TT would set the rules and constraints for the pilot teams. Additionally, the TT would provide support for the pilot teams by removing impediments for the pilot teams along with their ScrumMasters. George and Jean picked a few projects that would serve as pilot projects for what would be called Integrated Project Teams