Download - No Way! Agile in the Federal Government

No Way! Agility in the Federal GovernmentBRANDON 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. INTRODUCTIONLet 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 we’ll 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: [email protected]'s address: 4353 Stevens Road Centerville, IN 47330; email: [email protected] 2014 is held by the author(s).

No Way! Agility in the Federal Government: Page - 2

mailto:[email protected]

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! Let’s hire some Agile Coaches!!”

That’s 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.

Let’s go on a journey, one that would last over a year, through the story of ORG’s transformation, and we’ll show you where we hit bumps, took detours, and sometimes even took the scenic route!

2. THE TRANSFORMATION TEAMOnce 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 Team’s Roadmap2. This

1 Bruce Tuckman’s 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.


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 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 MATRIXBoth 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 BEGINBrandon 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 (IPTs). Pilot projects were chosen based on several criteria:

● Its readiness for teaming.● The team’s current work was amenable to agile practices and showed potential for

increased productivity.

The newly created IPTs were initiated via the “bootcamp” process that the TT experienced. Brandon and Judy helped each of the IPTs through their transformation by:

● Providing appropriate training as needed (e.g. estimation practices, user story, leadership practices)

● Attending Scrum Ceremonies and providing feedback to the IPT● Mentorship (especially to new Scrum Masters) and modeling of behavior● Providing feedback to the TT from the IPTs.

Each IPT was a self-organizing, cross functional team that had at its Core all the skills and resources necessary to accomplish the work it committed to for the project. With each sprint, the IPT would Plan-Do-Check-Act4 using Scrum as a foundation and bringing in XP engineering practices where necessary. In addition, new leadership models5 needed to be coached.

3 Each Release contained more detail about the organizational goal (effectively, smaller steps that needed to be completed to each the larger goal).4 The PDCA Cycle, Dr. W Edwards Deming, http://en.wikipedia.org/wiki/PDCA5 The staff were very use to command and control leadership styles. The IPTs and new Scrum Masters embraced new Servant Leadership principles as part of their transformation.


The pilot lasted for several sprints. As the IPTs inspected their work each sprint, those obstacles that the teams could not resolve were elevated to the TT for resolution. A few examples were:

● Lack of defined artifacts to produce.● Tools to help organize the work.● Fighting the legacy of years of inertia working in one particular way.


The IPT’s retrospectives highlighted improvements in their work life:● Providing a steady diet of priorities fed by a participating customer.● Frequent cycles of inspecting and adapting.● Having a dedicated team to perform the work in a consistent and measured manner.● The team was developing a velocity...they could now begin projecting how much work

they could take on in future sprints!5. A WISE CROWDRob, our CTO, stormed into George’s office yet again, furious that he had been called to task for another project that was behind schedule when neither he nor any of the architects in his group had participated in the estimating or execution of the project.

For years, typical engineering practices were not accounted for in the estimation and thus, not only did the schedule not incorporate a good majority of the engineering work required for the project, the actual overall quality of the product suffered. This manifested itself in rework, lost customers and a frustrated staff.

George, Jean and Rob, with the help of the rest of the TT and Brandon and Judy, enacted some changes:

1. Architects became part of the IPT early on to help determine some of the technical considerations while scoping the project. They accompanied the PMs to initial customer meetings and helped establish the requirements and determine scope and system level architecture.

2. The entire IPT participated in the estimation process for the project. This helped bring a 'Wise Crowd' mentality to the organization - diverse, independent perspectives aggregated together to establish a richer plan and team to develop a better product.

As a result of this experiment, the team became stronger and more confident of their estimates. The architects helped to point out practices and potential solutions that were omitted or overlooked in the past that made the project of better quality.

Since this experiment worked so well with the Pilot IPTs, it was quickly adopted for all new projects being scoped. This would prove to be an early win for the TT and a clear improvement to ORG that all agreed upon.

5. SCOPE ITMartin, our frustrated customer, is scrambling trying to secure additional funding for his project that is now way over budget. The fingers can be pointed in many directions but one thing is apparent: The features that have been developed so far are according to the original plan, but are certainly not the important features that solve the original problem Martin was hoping to solve. Jean has just returned from meeting with Martin and his boss. It was not a pleasant meeting as her ears are still ringing from the screaming that took place.

It was finally time to tackle the problem of better scoping the project from the beginning. This was another opportunity for the TT to help the IPTs develop a method to focus on an overall Vision, determine goals that achieved the Vision and defer the details until execution occurred. The TT decided that Roadmapping would solve this need.

Roadmapping allowed the IPT and its customer to embrace the concept that not all the details had to be implemented; only the most important that achieved the goals of the Vision.

The benefits were numerous:● Gave direction to the team (they could see where they were heading!)● Gave focus to the customer (they could discern the important outcomes of the

product!)● Provided constant reference to the Goals and Vision rather than just the technical

details● Allowed the customer to cut lower level details and not sacrifice the business goals.


Putting this plan into action with future projects allowed the project’s schedule to be met, the project to be delivered at budget, and most importantly allowed the critical goals to be met without all the detailed features being developed; only those most important to achieve the goals.

6. LET’S GO ALL THE WAYGeorge and Jean were starting to really appreciate the positive changes coming from the Pilot IPTs. But, before deciding definitively if and how to roll out IPTs to the rest of the organization, Brandon and Judy suggested a retrospective. This retrospective would be organization-wide to include all members of ORG. The purpose of the retrospective was to review events, generate insights and provide information such that the TT could decide when and how to roll out IPTs to the rest of ORG.

Brandon and Judy suggested that the design of the IPTs follow that typical of most Scrum Teams. Each IPT would be a cross functional team of 7+-2 people.

● A Core Team where membership remains constant for the life of the team. Roles on this team include Developer, Tester, Requirements Analyst and Project Manager (who also assumed the role of ScrumMaster).6

● An Extended Team to support each IPT with those who had skills that were only temporarily needed and thus might split their time across multiple IPTs.7

● An Operations Team which provided support in the areas of Maintenance, Systems Administration and Database Administration.

Figure 1. The Whole Team consisting of the core, extended and operations team

6 Core Teams were formed based upon implementation technology. For instance, an IPT might be focused totally on Java Enterprise Edition (JEE) or Ruby on Rails.7 Extended Team members have skills in Database development, User Experience, Graphics, etc.


Each IPT would have a portfolio of projects. The portfolio was a mixture of projects the team would work ordered within a given sprint based upon a number of criteria including mission priority, schedule, strategic alignment, and budget. The number of projects an IPT would take on at a given time would be determined by the IPT. Over time, the IPTs would establish a ‘velocity of projects’ that was derived from the traditional definition of velocity based upon a trend of story points completed over time. Which projects were in the IPT was a consultation between the managers and the IPT with the aforementioned criteria as objective input. A team would have the ability to determine if it could take on more or less work by informing George and Jean. You may be thinking, “Why not work one project at a time?” This would be a tough challenge among all the other challenges to immediately get ORG to drop its legacy of taking on multiple projects at a time. The compromise in the short term was to begin adopting Work In Progress (WIP) limits for the projects an IPT takes on at a given time.

As more and more teams came on board with the transition, the need became apparent for an environment that would scale as well as continuously reflect and improve for long term sustainability. Because of this, ORG established general frameworks, constraints, and a feedback loop so that each team could improve based upon the overall model of the organization.

The framework and constraints set in place were:● Use Scrum to organize the work● The teams worked their portfolio of projects within the sprint based upon established

criteria (mission priority, strategic alignment, budget, schedule).● Visions, Roadmaps and Release Plans would be developed at the initiation of each

project and be updated throughout the project’s life.● Each team would utilize the Core, Extended and Operations Team framework.● Use eXtreme Programming for Engineering Practices● A project review would be conducted monthly to:

o Allow the teams to share new techniques, practices and lessons learned;o Provide a point in time to draw a connection between progress on work

remaining, budget and schedule; ando Expose impediments that may exist for other teams.

7. WHAT’S LEFTPerfection is a journey, not a destination. As such, there is always work left to do. However, there are a few specific things that Brandon and Judy feel are important to work on as priorities. Here are a few:

7.1 CONTINUOUS INTEGRATIONAn automated way of integrating work on a continuous basis is still lacking. An effort has begun to provide a set of servers that the IPTs can use to integrate code on minimally a daily basis so that there is a flow of code/test throughout a sprint. In addition, defining the practices and establishing the habits that will support this way of working is under way.

7.2 NEXT GENERATION OF COACHESBrandon and Judy want to develop a group of people that can become coaches for ORG. These coaches would continue to provide a systems wide view, making sure ORG continues on its path of improving. To that end, work with the existing Scrum Masters is daily and continuous.

It took over a year for all the IPTs to form, adopt the frameworks and continue executing projects. Most believe the organization is in a far better place than when the transformation first began. It has certainly not been without the normal growing pains that a transformation usually brings. There has been chaos at times, resistance and the eventual bright spots of happy customers and successful deployments. The work continues and always will as long as the organization commits to “uncovering better ways of building software…”
