Full issue by AEi International

March - April May2013 - June 2013

Government Agility

How to Reduce IT Cost Using Agile Managing Federal Projects in Agile

Top 5

Agile Transformation Strategies

Agile

The Catalyst for Innovation

Scrum

The Framework for Change

Does Agile Scale? 路 Using Agile to Inspire Loyalty 路 Flipping the Iron Triangle

All Agile, All In

he word ‘agility’ has not often been associated with government agencies in years past. The common perception of government as large and ponderous does not mesh with the traditional definition of agility. And government agencies are not often thought of as being lean, nimble, and quick to adapt to evolving technologies.

achieving a department’s goals. In recent years a new paradigm of software development methodology has taken the I.T. world by storm. It’s called Agile software development, and as its name implies, it’s a methodology that utilizes quickness, flexibility and responsiveness in developing quality software with great efficiency.

Certainly there is some truth to these stereotypical views of government. But if we expand our view a bit and search for large and ponderous departments within the realm of private industry, we’ll find them. It’s a false perception that government agencies have grown large, inflexible and inefficient simply because they’ve been funded with free flowing tax dollars. (And these days, of course, the tax dollars aren’t flowing quite so freely as they may have in years past!)

Rather than a traditional linear, end-toend approach to software development, Agile is more of an adaptive, reactive approach. The result for both government and private operations can be software development projects more on-target with end-user requirements.

Many factors influence the efficiency and flexibility with which a department functions, whether governmental or private. Focusing particularly upon I.T. departments charged with software development, efficiency of operation has much to do with the philosophical methodology employed in

We expect that those of you already utilizing Agile development practices will be nodding your heads in knowing agreement as you read through this “All Agile, All In” issue of Modern Government. And we hope that those who have not yet availed themselves of the benefits of Agile will be motivated to explore the potential benefits in deeper detail.

Jenna Bratten President and CEO, AEi International Publisher, Modern Government

Features

Content 7

Flipping the Iron Triangle

By Jennifer Bleen Cardinal Solutions

Does Agile Scale?

By Larry Putnam, Jr. Quantitative Software Management

Using Agile to Inspire Loyalty

By Michael Swansegar Swansegar Consulting

20 TOP 5 Agile Transformation Strategies By Sally Elatta Agile Transformation, Inc.

Agile The Catalyst for Innovation. Scrum The Framework for Change. By Lizzy Morris Bearded Eagle

On the cover All Agile, All In! Agile takes over!

Federal Government 27 Managing 30 Projects in Agile: Agility: How to Moving Away from the Waterfall

reduce IT cost using Agile

By Christine Bottagaro & Ronica Roth, Rally Software

By Devon Morris Bearded Eagle

Modern Government May - June 2013 Published by AEi International

Modern Government is a bi-monthly online publication that goes beyond the traditional business divide to bring leading organizations together to share thought leadership and practical insights for government.

MODERN GOVERNMENT 路 May - June 2013

Contributors

Jennifer Bleen

Christine Bottagaro

Sally Elatta

Jennifer Bleen PMP, ACP, PSM is an experienced agile coach, change agent, program manager, business analyst, trainer, and industry consultant. Using her breadth of industry experience, she creates strategic solutions to develop high performing organizations. She enjoys coaching and mentoring teams and individuals to help them reach their full potential. She actively serves the central Ohio agile community as co-Founder and President of Central Ohio Agile Association, PMICOC Director of agile training and PMI Agile CoP Chapter Engagement Representative.

Christine runs integrated marketing campaigns for Rally Software, focusing on how Agile practitioners learn, what they need to know, and how to apply these learnings to their organizations. Christine has a background in product management, customer advocacy programs and strategic marketing development - as well as a passion for good reading material.

Sally is the President of Agile Transformation Inc. (8a Certification in progress)

Contact Jennifer: Jennifer.L.Bleen@huntington.com www.huntington.com

Contact Christine: cbottagaro@rallydev.com www.rallydev.com

She is an Enterprise Agile Transformation Coach who comes from a strong technical background as a software developer and architect for several years. Sally fell in love with Agile methods almost a decade ago because ‘They just brought back common sense approaches to getting work done and re-emphasized the need for Servant Leadership’. Her organization is made up of a talented team of highly qualified Agile trainers and coaches who are passionate about helping organizations succeed with their Agile Transformation. Their clients range from large fortune 50, 500 to medium size businesses and government agencies/ contractors such as HHS, DHS, DOD, Nebraska Dept of Roads, US Navy, USDA, US Army, US Air force, Raytheon, Northrop Grumman, Cayman Island Gov. Sally is the Agile Expert for PMI’s Learning and Education CoP, a frequent public speaker at national conferences and has published several popular videos on AgileVideos. com. She is also a co-author of the ICAgile Leadership certification track. She is also the founder of www.AgileforGovernment. com which is a site that will be dedicated to helping government agencies learn and apply Agile methods. She is a proud mother of 3 young children and enjoys traveling and exploring the world with them! Contact Sally: Sally@AgileTraining.com www.AgileforGovernment.com

May - June 2013 · MODERN GOVERNMENT

scrum and raising scrum master and future coaches. Lizzy believes she is blessed to go to work everyday able to pursue her passions.

Elizabeth Morris ”Lizzy” Lizzy as she likes to be called, is a British native who relocated to the USA in 2005. She is a seasoned organizational change agile executive management consultant that focuses on driving measurable results for her clients, processes, employees and financials. Lizzy has over 19 years in-depth experience in delivering software development, project management and strategic consulting. This has given her a unique ability to provide clients with the right tools and techniques tailored to the needs of their organization. Lizzy career has taken from the UK across Europe, North America, Asia, and Africa. Lizzy and her husband own a company called BeardedEagle, they offer services that are geared towards executives, private individuals, teams, managers, large and midsize organizations that are ready to embark on their Agile journey. Lizzy passion is Scrum and considers herself blessed to be able work everyday pursuing one of her passions. A mother of 6, 4 boys and 2 girls Lizzy understand the benefits of Scrum in action.

Lizzy considers her sweet spot to be Agile Organizational Trans-formation, the reason she is loves it so much is in her own words “there is nothing greater than starting to see all the “arhah” mo-ments happening with teams, executives and middle management. It tends to be like a domino effect that had once seemed impossi-ble. When every training class and Agile presentation and side conversation you have had comes to life and makes sense to cus-tomer. Nothing like it ..it beats ice-cream!” Lizzy considers herself a lifetime student at ecosystem of learning and development. Lizzy is always pursuing new techniques and methods to help teams evolve. Her training always have her students wanting more. Her belief is that students should leave her training with a tactile knowledge of scrum that they can immedi-ately put to use. Lizzy has her students engrossed in games, simulations and group facilitation exercises to provide an immersion experience into the philosophy and culture of agile. By no means your ordinary agile change agent . Lizzy is currently writing her first book which she hopes to be available for purchase by the end of the year. It is called Agile Transformation from Agile Heels. We will look forward to it release Contact Lizzy: team@beardedeagle.com www.beardedeagle.com

Larry Putnam, Jr. Larry has 21 years of experience using the Putnam-SLIM Methodology. He has participated in more than 80 estimation and oversight service engagements, and is responsible for product management of the SLIM-Suite of measurement tools and customer care programs. Since becoming the Managing Partner of Products and Customer Care, Larry has developed a new customer care program that has increased customer satisfaction levels by 50 percent and increased client license renewals by 46 percent. Larry is a member of and active participant in numerous organizations, including the Quality Assurance Institute, Software Program Managers Network, International Function Point Users Group, and International Society of Parametric Analysts. Larry has delivered more than 27 speeches at conferences on software estimation and measurement, and has trained – over a five-year period – more than 1,000 software professionals in the use of the SLIM-Suite. Contact Larry: info@qsm.com www.qsm.com

Lizzy has three passions training scrum, coaching executive leaders through agile adoption with

MODERN GOVERNMENT · May - June 2013

Devon Morris

Michael Swansegar

Ronica Roth

Devon Morris is a Certified Scrum Trainer and EagleEye at BeardedEagle. He was introduced to Scrum in 2000, where he played several roles ranging from software developer to project manager. In 2005, Devon started consulting to influence the cultures and work environments of his clients. He has helped with the adoption of Scrum and Agile at numerous companies, including Allstate, Awana Clubs, Capital One, Experian, Johnson & Johnson, Pearson, Rackspace, Sears, State Farm, TransCanada and USAA.

Michael is an active Agile Trainer and Product Manager. Michael has spent over 12 years in infrastructure support and has now paved a way through Quality Assurance and Product Management. Michael has been on a quest to find “who is in charge” when it comes to defining the right product. As many Product Managers realize, the customer on the call with support is exactly the one we need to inspire. Michael believes that agile is designed to inspire loyalty with internal and external customers. Michael loves to teach and uses radical methods such as movies clips, games and stage props to memory retention by associating our normal life to the content being taught. Michael is married, has two dogs and lives in Colorado.

Ronica brings incomparable energy and passion to promoting Agile principles and practices. Her mission is to build learning organizations that honor the individual, give everyone the chance to do what they do best, and harness the power of team to amplify great work and produce great software.

Devon’s brings his broad range of experience to every training event and coaching session, so that you boost your performance when applying techniques. Devon believes in values espoused by the Agile Manifesto and applies in to his everyday life. He holds the follow certifications - Project Management Professional, Agile Certified Practitioner, Certified Six Sigma Black Belt, Lean Six Sigma Black Belt, Myers-Briggs Type Indicator Professional and California Psychological Inventory 260 Professional. Contact Devon: team@beardedeagle.com www.beardedeagle.com

May - June 2013 · MODERN GOVERNMENT

Contact Michael: michael@swansegar.com www.swansegarconsulting.com

As Rally’s Solutions Evangelist, Ronica works with stakeholders to set strategy for evolving Services solutions that support our customers’ needs for Agile coaching, consulting, and training. She uses her Agile Coach and Consultant experience to evangelize how Agile + Rally = company greatness. Contact Ronica: rroth@rallydev.com www.rallydev.com

Flipping the Iron Triangle BY Jennifer Bleen

Practices such as limiting the amount of work being performed in order to get more work done may seem counter intuitive.

Triple Constant

eginning an agile adoption is a disruptive change that impacts not only the processes used by team members performing work, but the organization’s culture and your role as a leader. Agile is a set of values and principles shared by application development and product lifecycle methods and frameworks. Practices such as limiting the amount of work being performed in order to get more work done may seem counter intuitive. In my opinion, the paradigm shifts required are the toughest for leaders. Not because they are difficult, but simply because they are unfamiliar territory. More often than not, no one explained in practical terms what the paradigm shifts really mean for everyday business as usual. In this article we will explore some aspects of one such paradigm shift, the triple constraint or iron triangle flip. For those of you unfamiliar with the triple constraint concept, an organization

managing projects in a traditional manner will generate a list of requirements up front. This defines the scope of the project and drives the project’s planning efforts. Estimates and schedules are built based on the scope. The triple constraint is named based on the idea that the three factors of scope, cost and time are all related. Decisions and changes to one, impacts the other two. At any point in time you can only constrain two items. For example, I can define scope and let that drive my schedule and cost. If I want to reduce the amount of time it will take to deliver the scope, my cost will change. If I change my cost and schedule, my scope will change. Other models expand the triple constraint to include architecture, risk, quality and/or customer satisfaction as these are also affected by changes in scope cost and time. For our discussion, we will keep it simple and focus on the iron triangle: cost , schedule and scope.

MODERN GOVERNMENT · May - June 2013

Before I dive into the paradigm shift, let’s explore the goal of introducing agile. Fundamentally, the goal is to drive toward predictability, flexibility and quality of our product and service delivery. We need a way to respond to the ever faster changes in our market place. In addition to fickle consumers and general market place changes, government organizations may experience change with each election. For some organizations the election changes may happen more frequently than their current project lifecycle. A new law maker governs within the fixed time box of the seat held. Driven to make a noticeable change before the next election, your organization is provided an arbitrary deadline by a law maker to change a manner in which you operate. Many times this is in the opposite direction of the predecessors orders. Introducing agile into your organization is not as simple as mandating all new projects start following agile practices and processes. Remember, agile is a set of values and principles supported by practices. Now let us return to the triple constraint flip. Most organizations practicing agile use fixed time boxes known as sprints or iterations to create a potentially shippable product. The work is ideally performed by a dedicated and consistent team. Given my team is fixed, I have a fixed cost or run rate for that team. My time is constrained by

May - June 2013 · MODERN GOVERNMENT

the time box. If my time and cost are fixed variables, they will drive the amount of work that can be delivered. The scope that can be delivered is the value being created for the organization. Sounds simple, right? What does this really mean to your organization? Let’s look a couple of the factors. First let’s explore time. What does it mean to have a time box. Similar to the law maker in office, your team has a fixed start and end date to deliver work. Let’s understand the assumptions around time. In order to deliver a potentially shippable product in a time box, we must have the right people on the team, they are self-organizing and have the resources available to perform the work needed. In order to be successful, a team must be accountable and have ownership. Ownership in the deliverable and ownership of the method in which to create the deliverable. Most day to day decision making needs to be within the team. If the team is required to ask permission and gain approvals on all decisions their ability to meet commitments within a time box are hindered. In my experience, I have found government agencies have a strong military influence. By nature the military has a dominate command and control culture. Rightfully so, lives are at stake when out in the battle field. Knowledge workers on the other hand have different needs. Too

Introducing agile into your organization is not as simple as mandating all new projects start following agile practices and processes.

If the team is required to ask permission and gain approvals on all decisions their ability to meet commitments within a time box are hindered.

much command and control can stifle creativity, lower moral and hinder productivity. The trick is to find the right balance between the organization’s strategic goals, the organization’s culture and your leadership style. Leaders who learn their managing techniques within the military often find it uncomfortable to let go and let their subordinates make the decisions. Many times identity and ego are tied to position and authority. Giving up decision making authority may feel like a loss of power. It also requires trust. Trust in the process and trust in the team. In order to be successful as an agile organization, you will need to allow your teams to make day to day decisions. To help you over this hurdle, I suggest, you define clear boundaries for decision making. Set allowable change tolerance thresholds. This is especially useful in union environments. Clearly defining the boundaries of each role’s authority for decision making around changes and day to day decisions will help set expectations and help keep peace with union requirements. I used this technique with a government, union managed client where agile practices were introduced. The thresholds defined allowed the product owner to make the priority decisions on work to be completed by the team, this included the robustness of the features to be delivered within the release. However,

One example is to complete unit testing of new features and deploy to a shared system testing environment where dedicated testers are available to finish testing. Then create a technology roadmap to improve your environments to evolve into an agile organization over time.

Another barrier to time is not having the supporting technology to complete work within the time box.

if a feature was to be moved to another release or omitted all together it took a superiors sign-off. For the organization, two sprints would be packaged into one production release. We had created a product roadmap and aligned features to release dates. By making this distinction, the development team was able to explore with the product owner the best way to meet the needs of the organization and deliver on time without having administrative overhead of capturing approvals for each low level requirement. Because we had contracts in place with vendors, thresholds went on to define when procurement was to be involved. More on that later. Another barrier to time is not having the supporting technology to complete work within the time box. Definition of done is extremely important. For work to be considered done, a set of requirements must be met. Usually this means the requirements have been fully integrated, tested and are ready

to be delivered to production. Coupling agile engineering practices such as acceptance test driven development and automated continuous integration with a framework such as scrum will allow an organization most flexibility. Note, the automation is key. Without automation, the team will slowly lose their ability to deliver within the time box. For example, a team is building a new application. In the first sprint they build and test the features. In the second sprint they build features set two and regression test feature set one. In sprint three, they build a new feature set and regression test one and two. If the regression testing is manually completed, the team will get to a point where no new work may be introduced in the sprint as the team regression tests all the prior sprint’s new work. If your organization is in a situation where you do not have the technology to support agile fully, you may need to look at a hybrid model in the short term.

Now let’s look at scope. As we discussed above, if time and costs are fixed then scope varies. Many government agencies work with vendors based on contracts with defined scope. If scope is variable, how can we measure a vendor’s services for contract payments? First, let’s remember one of our goals is flexibility to the changing needs of the organization. In order to be flexible, we have to accommodate the changes of the organization needs. We want to be able to do this without introducing unnecessary administrative overhead. An example of how this was handled at a government agency I coached, was to clearly define the time boxes and roles in the vendor contract. General scope items were identified but not committed. The roles were clearly defined for both the vendor’s roles and the roles to be filled by dedicated full time employees of the organization. This is a partnership and both parties must be at the table. The product owner role was defined as the accountable role for directing what was built and the priority. This role was

MODERN GOVERNMENT · May - June 2013

If scope is variable, how can we measure a vendor’s services for contract payments?

filled by the organization. The organization had clearly defined authority and accountability. This accountability on the organization is the shift in the paradigm. The organization had a stake in the game and could no longer blame a vendor if something was not delivered since the organization was defining what was to be worked on every step of the way. This also minimized the need for a lot of administrative change control overhead. Remember the change tolerance thresholds we discussed earlier, they also applied for contract changes. If the product owner wanted to add scope that would extend the contracted number of sprints, a contract change would need and require appropriate superior approvals. As for vendor deliverables, in order to receive payment, the vendor provided sprint reports describing what features were planned and what features were delivered along with end customer reactions to the sprint show and tells. Metrics on the number of points or any other velocity metric were not included. Points are a relative

May - June 2013 · MODERN GOVERNMENT

unit of measure to define the effort and complexity of a piece of work. Velocity is the sum of all work pieces completed during a time box. The team’s track velocity internally to gain insight into predicting the amount of work they are capable of completing in a time box. Points are not transferable to another team. Beyond a team’s use, the values can be misconstrued. For example, if one team reports a 20 point velocity and another reports a 30 point velocity, does it mean the one who completed 30 points did more work? No. If a leader attempts to use this as a means of comparison, the behavior it will drive is inflated point estimates not increased output. Increased out point requires continuous improvement and removing obstacles standing in the team’s way, including unnecessary process. We have only touched on a few ways one paradigm shift from an agile adoption is a disruptive change. Through knowledge of these changes you will be one step closer to fully attaining the benefits of predictability, flexibility

This accountability on the organization is the shift in the paradigm. and higher quality products and services that agile is capable of delivering. By truly understanding the nature of the disruptions you will understand and respond appropriately to the needs of your team. My parting suggestions for leaders new to agile are have an expert conduct an agile readiness assessment to help you understand where your process and technology constraints exist. Then hire an enterprise agile coach to develop a roadmap for the agile adoption and help you navigate the cultural and leadership style changes required on your journey to becoming an agile organization capable of quickly responding to change no matter which way the political winds may blow. [MG]

Does Agile Scale? BY Larry Putnam, Jr.

ike Romeo and Juliet, government’s flirtations with Agile software development practices have been the talk of the town. But there’s one aspect of the story we tend to forget: government is big—really big. So what happens to Agile projects when they’re forced to scale to the size of major government enterprise initiatives? We could speculate, of course. But instead, let’s take a look at the data. For this exercise, we analyzed 93 Agile projects, occurring between 2002 and 2012, mainly in the Government, Financial, and Health sectors. We divided the data into two datasets called Early Adopters (2002-2008) and Later Adopters (2009 – 2012), which gave us similar sample sizes in both groups. At the same time, we examined a sample of 93 non-Agile projects with the same sample demographics. Then, we charted how the projects fared as their sizes (measured in lines of source code) increased.

Here’s what we found:

Early Adopters vs. Later Adopters ❚❚ Early adopters had a significant proportion of smaller boutique software firms ❚❚ Later adopters were mostly large enterprises, with many from the financial services and banking sectors ❚❚ Early adopters exhibited shorter project durations (faster to market) than later adopters ❚❚ Later adopters tended to use more staff than early adopters and tended to look more like the non-agile group

Agile vs. Non-Agile ❚❚ Duration of Agile projects was mostly lower on projects larger than 14,000 lines of code ❚❚ Number of defects created were lower on Agile projects than non-Agile projects

“Large staff” projects cost significantly more, achieved negligible time savings, and produced many more defects than “small staff” projects.

MODERN GOVERNMENT · May - June 2013

MB Average Staff VS Effective SLOC Figure 1: Plotting the number of lines of source code (SLOC) against the average staff sizes of “small staff” and “large staff” Agile projects.

LARGE TEAMS

1,000

1o0

mb average staff PEOPLE

SMALL TEAMS

1 0.1

100

1,000

10,000

EFFECTIVE SLOC thousands

So, if our question is whether Agile projects can scale, the answer would seem to be yes. As the projects we analyzed grew in size, Agile methods produced: shorter project durations, fewer errors, and higher productivity. However, we also learned that as Agile projects grow, they tend to expend more effort and use more staff. And that’s a problem, because we know from separate analyses (e.g., the QSM Almanac study in 2005) that high staffing

May - June 2013 · MODERN GOVERNMENT

“Large staff” projects keep adding more people as they add functionality, but the “small staff” projects do not.

levels correlate strongly with waste, regardless of development methodology. We also know that government IT departments aren’t exactly flush with cash these days, and that hiring an army of Agile developers is probably not in the budget. So just for fun (yes, this is what we do for fun), we decided to take a closer look at Agile projects in relation to staff size. Projects with 7 or fewer

staff members we classified as “small staff,” and projects with more than 9 staff members we classified as “large staff.” When we compared the two groups, here’s what we found: “Large staff” projects cost significantly more, achieved negligible time savings, and produced many more defects than “small staff” projects. That’s fairly definitive. But does it hold true even at maximum scale? 80,000 lines of

code? 200,000? 5 million? The answer seems to be yes. And here’s why: As Figure 1 shows, the “large staff” projects keep adding more people as they add functionality, but the “small staff” projects do not. (As functionality increases, “small staff” projects add fewer than one full-time employee, whereas “large staff” projects grow fifty times in staff size.) What this suggests is that large-scale Agile projects may not require big staffs after all. (Staffing up is just how most IT managers reflexively respond.) If, instead, we kept our Agile staff small, the data indicates we could complete large-scale enterprise initiatives much more efficiently, in nearly the same time frame. This is phenomenal news for government, particularly during the dog days of sequestration— when keeping IT teams small and lean is worth its weight in U.S. bonds. Using this method, government organizations can keep costs down by influencing

the way their contractors staff development projects, while at the same time producing more reliable products. We must be careful, however, not to view Agile as government’s panacea. If our data shows anything, it’s that Agile projects are highly variable. We’ve seen how adopting Agile methods can potentially lead to modest schedule compression and fewer errors, but also a tendency toward bigger staff size and higher costs at scale. So the question becomes: With all of these variables in play, how will government IT managers know when it’s the right time—or the wrong time—to implement Agile methodologies? The answer, we believe, is to do exactly what we’ve just done—run the numbers. Agile practitioners might try to minimize upfront planning, but in large-scale government initiatives, there will always be a need for some semblance of pre-project assessment (even

if it’s done in an iterative, agile fashion). In fact, one reason government IT managers have been reluctant to adopt Agile methods is for fear of losing that planning and predictability. However, this is where software estimation and forecasting tools can bridge the gap. In a recent Harvard Business Review article (“Why Your IT Project May Be Riskier Than You Think”), Bent Flyvbjerg and Alexander Budzier write: “[Smart managers] break big projects down into ones of limited size, complexity, and duration; recognize and make contingency plans to deal with unavoidable risks; and avail themselves of the best possible forecasting techniques...” But to forecast effectively, you need data—and lots of it—on past and present Agile development projects. Because the truth is, Agile development in government is here for the long haul. [MG]

We must be careful, however, not to view Agile as government’s panacea. If our data shows anything, it’s that Agile projects are highly variable.

MODERN GOVERNMENT · May - June 2013

BY Elizabeth Morris “Lizzy”

Agile

The Catalyst for Innovation

Scrum

The Framework for Change 14

May - June 2013 · MODERN GOVERNMENT

oday we are blessed to live in a nation whose roots were planted by a people that had the courage and aptitude for change. This great quote “We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness” This quote sets the bar rather high and is the catalyst of what is known as the ‘American Dream.’ Today, many Americans would say that they do not live this happiness, some would say it is because they do not feel free. Liberty is not something that is evident within their environment. Here lays the question how can agile principles and values drive innovation that can empower every Americans’ pursuit of happiness.

How can agile principles and values drive innovation that can empower every Americans’ pursuit of happiness.

The Agile Principles Let’s look at the twelve agile principles

Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software. (services, representation)

Build projects (communities, job programs), around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Continuous attention to technical (details) excellence and good design enhances agility.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The most efficient and effective method of conveying information to and within a development team is face-toface conversation.

Simplicity-the art of maximizing the amount of work not done--is essential.

Deliver working software (services and government) frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Working software is the primary measure of progress.

The best architectures, requirements, and designs emerge from self-organizing teams. (Communities, citizens, townships)

Business people (citizens and residents) and developers (senators, mayor, must work together daily throughout the project.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

At regular intervals, the team (local town hall, government elected officials) reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

You will note that I have underlined certain words within certain principles. The words within the brackets after the underline are suggestions for the replacement. We are uncovering better ways of developing software by doing it and helping others do it? Through this work we have come to value: ❚❚ Individuals and interactions over processes and tools ❚❚ Working software over comprehensive documentation ❚❚ Customer collaboration over contract negotiation ❚❚ Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more . Bold words wouldn’t you agree? Let’s look at what we will call agile principle number 6. Well if The most efficient and effective methods of conveying information to and within a team is face to face conversation. When the last time face to face interaction was was part of your company culture? When we have the option to send an email or walk around the corner and see the person, what do we tend to do? Send an email. Technology advances seems to have killed the art and need for in person

MODERN GOVERNMENT · May - June 2013

relational interactions. Now we don’t even pick the phone up to make a call, we simply shoot a text. Be careful not to misplace the message. The 1st agile values states it best, Individuals and interactions over processes and tools. It is important to note that the people we call the founding fathers of the agile manifesto were a cross section of brilliant technologist and business thought leaders from multidisciplines. However, they realized from year of running projects and being part of projects within corporate and governmental organizations that if we lost site of the people, the customer, the user, and the citizen; we will have missed the ‘plot’ Technology tooling, and processes should be there to empower the individual’s interaction.

Why Are Individuals Interactions Important? At the very core we are simply human beings as a result we all have basic needs and desires. One of those core needs is interaction with other individuals. The need to feel connected, the need to belong, the need for recognition and acceptance. Each of these needs drive human behavior. The pursuit of happiness requires these needs be met. Maslow’s hierarchy of needs shows the levels at which we need the interactions with another individuals 1st Physiological Needs (air, food, water, shelter, clothing, sleep)

May - June 2013 · MODERN GOVERNMENT

2nd Tier - Safety & Security Needs (Health, employment, property, family, stability) 3rd Tier -Love & Belongingness Needs (friendship, family, intimacy, connections) 4th Tier- Self- Esteem Need (Confidence, achievements, respect of others, connections, need for individuality) 5th Tier - Self Actualization (Morality, creativity, spontaneity, acceptance. Experience purpose, meaning and inner potential)

What Environment Framework Fosters Individual Interactions The Scrum framework and scrum values provide actualization to tier 3, 4, and 5. Let’s talk scrum. Scrum is simple framework that facilities complex problems, projects, processes being built out and delivered. It came about through Jeff Sutherland and Ken Schwaber released a framework called, “Scrum.” This framework is known as an empirical process. In short, this framework allowed you to take large complex unknowns, break them down into simple statements clarified by success criteria known as the acceptance criteria. And these simplified statements, known as user stories would be placed into a time boxed environment in which a cross-functional team of individuals would collaborate their skills in order to make each simple statement a viable, usable

Scrum is simple framework that facilities complex problems, projects, processes being built out and delivered.

product that delivers value to its customer. A key principle would take place through a mechanism known as a retrospective. The team would introspect along the five core scrum values: ❚❚ Commitment ❚❚ Focus ❚❚ Openness ❚❚ Respect ❚❚ Courage All held on three Scrum Pillars: ❚❚ Transparency ❚❚ Inspection ❚❚ Adaptation.

Agile Siblings that look like Twins

The very domestic threat that lays within our borders, it is our fear to step out and innovate, our fear to adapt.

Agile and Scrum although two individual separate entities, Agile speaking to a philosophy and belief system of working. Scrum speaking to process that fulfills that philosophy while delivering product or service increments. Interact in such a collaborative fashion in perfect support of each other, the industry at large tends to declare as agile scrum or scrum agile. Thus suggesting by implication that to be agile you need to scrum. That is an interesting debate to be had at another time. ❚❚ Commitment speaks to Tier 2 stability ❚❚ Respect speaks to Tier 4 Respect of Others ❚❚ Courage speaks to Tier 4 Confidence- Self Esteem ❚❚ Focus speaks to Tier 5 Purpose - Self Actualization

❚❚ Openness speaks to Tier 3 - connections ❚❚ Customer Collaboration Speaks to Tier 3 Friendship Tier 5 Creativity -Self Actualization ❚❚ Responding to change speaks to Tier 5 Spontaneity, ❚❚ Working software speaks to Tier 5 Experience purpose ❚❚ Build projects (communities, job programs), around motivated individuals. ❚❚ Give them the environment and support they need, and trust them to get the job done- Speaks to Tier 3

How Can This Knowledge Empower life liberty & pursuit of happiness Taking what is known as the very simple framework of Scrum, it is possible to facilitate consistent value in small increments of change. Changing the way inner city children are educated, changing the way inner city schools are funded. Allowing large organizations tax breaks for financing inner city school and equipping them to learn today what they will need tomorrow. Corporate workers time volunteered to teach courses in these schools that don’t attract the best teachers. Why not begin an open space backlog for improving inner city schools. If cities were allowed to be self-organizing and make alliances with businesses to increase their budgets. Today, as Americans, we are faced with many complex unknowns. We

need to be courageous enough to admit we do not know what we do not know and implement an iterative approach to break down complex issues utilizing the methods the scum framework prescribes. Our department of Defense mandated a new acquisition process for information technology systems, leading to Agile becoming law. The very domestic threat that lays within our borders, it is our fear to step out and innovate, our fear to adapt. Our failure in retrospect to adapt and roadmap our technology future and education path has Japan, China, Sweden, as epic centers of technology innovation. In times past these countries and others like them, were seen as nothing more, but third world types. Today they have become leaders due to their willingness to embrace innovation, the courage to be able to step out and get it wrong. XP (Extreme Programming) prescribes to fail early, fail fast, fail often, and fail better. Why is it so important to be willing to fail? Thomas Edison said, “I have not failed. I just found 10,000 ways that won’t work.” James Anthony Froude says it best, “Mistakes themselves are the best teachers of all,” because as Aristotle said, “He who has overcome his fears will truly be free.” This is our root impediment fear. Our American forefathers were not fearful they fought to maintain their freedom from the Great Britain. It is time to fight with knowledge, and inspire innovation!

MODERN GOVERNMENT · May - June 2013

Where Do We Begin Most people spend According to US dept. of Labor people in the US spend at least 1896 hours per year at work on average. If were to take a closure look at corporate America we could probably double that number. That would raise the issue that people need to be happy at work.

Let’s talk Work What can be done in your environment to make things better for your teams? Do you care to improve their environment? Is the traditional model of management fostering innovation in your employees? Is is easy to think that innovation only belongs in technology, but if you encourage innovation in accounting in your hotels it means you give your teams the space to self-organize create better ways of doing what they do on an everyday basis. Scrum prescribes inspection of what we do so that we can adapt it and continually improve. If we are not encouraging improvement and growth then we are by default encouraging stagnancy. Managers should be coaching mentoring servant leaders thinking about how they can build team and inspire growth. The leaders of the millennium, led by inspiration and example, not by tasking and micromanagement. Gardner report has said waterfall is dead it is the day of agility why? Because it creates an environment and ethos of empowerment trust and freedom to be creative which births solutions to complex problem. John Fisher’s transition curve states that we all go through a transition of happiness. The

May - June 2013 · MODERN GOVERNMENT

impact of the awareness that one’s viewpoint is acknowledged and shared by others provides a feeling of relief. A feeling that something is going to change and not continue as before. A feeling of anticipation and potentially excitement about the possibility of improvement. Regardless of the familiarity of the old system, there also lies truths that no matter how well we like and are comfortable with the status quo, there is something unsatisfactory about it. The anticipation makes the happiness phase one of the more interesting because we transition through the phases without knowing. The feeling of knowing we have an impact to take control of our destiny helps move through the process. Hence the drive of an individual to pursue higher education solely from the extra income an education brings to satisfy a lifestyle of freedom. Under the belief that freedom buys happiness because freedom in decision making means living a happier lifestyle.

Dare to Innovate You be the change agent Agile principle #4 talks to business people and developers must work together daily throughout a project because it incites innovative concepts from the power of collaboration. Don’t underestimate the power of synergy that comes from collaborative efforts. Bringing these techniques to our local government to empower government from the people by the people can be more than historical statement from an epic speech. It can be a reality! Communities

Is is easy to think that innovation only belongs in technology, but if you encourage innovation in accounting in your hotels it means you give your teams the space to self-organize create better ways of doing what they do on an everyday basis.

must demand governmental support to build projects around the people within communities the real people, to develop an environment conducive for enriching and cultivating innovation. Methods of innovation could be the introduction of serious games to produce serious results. The founder of innovation games Luke Hohmann spent the last ten years aiming to shift the mindset of traditional thinking and techniques around data harvesting or people’s opinions, desires, and priorities. When these methods were first introduced, it went against the graining of traditional customer market research techniques. Rather than interpret and assume the end customer’s desire, Luke had the concept of why not just ask the customers in a collaborative face to face fashion. This led to innovation gains like creating the product box, buying a feature. Today, the San Jose local government utilize buy-afeature gain model to engage their constituents in matter of government budgeting and priorities. A great mind that is well respected today once said, “The secret of change is to focus all of your energy, not on fighting

the old, but on building the new.” (Socrates) They have the courage to formally engage the people to become a part of their own governance model; a wonderful innovative prototype that sets the dial on a government, “For the people, by the people.” (Lincoln) Bringing in two hundred citizens from varying demographics in San Jose’s Town hall, and giving them copies of the budget and a limited amount of money to spend and furthermore, dividing that amongst the table of fellow citizens needing to come to consensus about serious issues that would affect their city for

the next fiscal year. An example of these issues: increasing the police force, closing public libraries, repaving roads, opening vs. closing – closing vs. opening afterschool clubs. These are just an example of some of the serious issues this innovative technique was able to facilitate, the process of decision making and prioritizing. Corporate organizations like SAP, FIAT, CISCO, ADOBE, and EMERSON are few organization who use these serious games to drive productivity and customer collaboration. American Government customers are the American

It is time to take Agile and Scrum beyond software into the communities, take it to the people.

people. It is time to actively listen and deliver continuous improvement.

Let’s Summarize It is time to take Agile and Scrum beyond software into the communities, take it to the people. The spirit of the constitution offered justice, equality and the hope that the pursuit of happiness was viable for everyone. The Principles and values of agile coupled with the scrum framework provides the guidance and agility momentum to take citizens from theory to execution. [MG]

MODERN GOVERNMENT · May - June 2013

TOP 5

Agile Transformation Strategies

A practical guide for government leaders who want to make a difference! BY Sally Elatta

overnment IT isn’t much different than the private sector in some ways, there are simply too many simultaneous projects started, very few are ever “done” and the handoffs between various functional silos are killing productivity. One major difference however, is that often government planning, contracting and auditing methods are stuck with antiquated, cumbersome and wasteful procedures. These

May - June 2013 · MODERN GOVERNMENT

waterfall multi-year-you-won’tsee-anything-until-the-end methods have repeatedly proven that they lead to failure, BIG failures on both IT and non-IT projects. Unlike the private sector, government departments undergo frequent budgetary crises and mandated policy changes. Often government projects are under much more scrutiny because these BIG projects are paid for by taxpayers! For example, the US Department of Defense canceled a Human

Resources project after 12 years of wasted effort and 1 billion dollars was written off costing every US taxpayer $100. (Thank you Vivak Kundra for doing so!) So has Agile actually succeeded for large government projects? You bet! Agile saved the FBI’s Sentinel project at the cost of $99 million after 10 years of failure and 2 aborted Waterfall projects that cost $597 million! The US Army Software Radio was also a large multibillion dollar Waterfall project saved by Agile methods in the

Agile methods are now being used to complete the avionics software systems for both the F35 and F22.

GOVERNMENT LEADERS Top 10 Strategies for Leading an Agile Transformation This paper will focus on the first 5 which are fundamental to kicking off a successful transformation. The next 5 focused on Scaling the Transformation will be covered in a future paper.

1 2 3

Invest in Your Own Agile Learning

Design a Transformation Roadmap Take on the Spiral of Death – Gov. Planning, Contracting and Auditing Processes

11th hour. A small Agile team finished all the hardware and software at a fraction of the total budget delivering a complex system on time. Agile methods are now being used to complete the avionics software systems for both the F35 and F22. The Ministry of Defense, US Veteran Affairs, the UK Government Digital Service, in India, Australia and New Zealand have all demonstrated that Agile can work for Governments. It’s Time for Serious Change! But an Agile Transformation for

the Government will require strong hands on leadership to drive its success. For this reason, we will focus on the key strategies that Government executives and leaders can take to lead a successful Agile Transformation within their agencies. You see, we can debate fiscal responsibility all day in Washington, OR we can roll up our sleeves as leaders and do the hard work of making it a reality. If you succeed, the taxpayers and citizens of this great nation will love you!

4 5 6 7 8

Pilot Agile Successfully Invest in Agile Training and Coaching

Invest in a Strong Technical Foundation

9 10

Scale Agile to Programs and Larger Initiatives Transform the Culture to Servant Leadership and Cross-Functional Collaboration Apply Agile and Lean Portfolio Management

Transform to Enterprise Stable Agile Teams

MODERN GOVERNMENT · May - June 2013

Invest in Your Own Agile Learning.

Take time out to learn the difference between Agile and Waterfall, why Agile works and read about real case studies for Agile in the government. This training Executive/Leadership level training should help you learn: ❚❚ How an Agile Transformation will help you make better buying decisions and improve quality and time to market. Be able to answer the Why Agile question with real statistics and case studies.

Agile to Scaling Agile to the Enterprise Transformation stages successfully.

❚❚ Understand that this is an organizational transformation that requires a change management plan as part of ❚❚ HOW do you actually transform the roadmap. your teams to Agile? What ❚❚ Learn and speak to the is the strategic roadmap and differences between Waterfall practical implementation steps and Agile development. See necessary for this to work? below for some key points on How to move from Piloting this:

Waterfall Development

REQUIREMENTS ANALYSIS-DESIGN 1 DEVELOPMENT 1 2 DEPLOYMENT 2 3 1 TESTING 1 3 4 2 5 6 7 8 9 10

3 4 5 6 7 8 9 10

2 3 4 5 6 7 8 9 10 2-3 months

3-4 months

2-3 months

3-4 months

4 5 6 7 8 9 10

1 2 3 4 5 6 7 8 9 10 DONE! 1 month

May - June 2013 · MODERN GOVERNMENT

The chart shows the typical cycles of the Waterfall process. If you are trying to build a new software product using Waterfall you could spend 5 – 8 months just in upfront planning activities ‘Requirements gathering and Analysis/Design’. This is called BDUF (Big Design Up Front) and it’s one the key killers of projects, especially large ones! Next time someone tries to convince you to spend 6 months+ getting ‘All the Requirements’ and design documented in detail and ‘signed off’ you should RUN! This could be biggest risk factor to your project because: 1. You will never ever get ‘All’ the requirements and by the time you think you did they will all change. 2. You have just spent a third or more of your budget on ‘documentation’ and have nothing to show for it. If this project gets canceled then you have wasted 100% of your investment and cost. 3. You have many features (10 here) all in progress but none are ‘Done’. Sounds familiar?

Work in progress 10 features Planned completion time: 11-15 months

4. You’ve lost time and the opportunity for early feedback. Instead of working on delivering working products in small chucks so your target customer can start testing and giving you feedback (think Lean Startup), you’ve wasted valuable time and left all the testing for the end. Consider if you walked through a new home you’ve built for the first time right before moving in… how many ‘defects’ would you find? Don’t take our word wfor it, here is what the Dr. Winston Royce, author of the Waterfall Model says in the paper he published that gave birth to Waterfall in 1970: “I believe in this concept but the implementation above

Story Points Delivered

Cost (USD)

Current project done 83%

Current Project Burn 74%

TARGET ACTUAL TOTAL

TARGET ACTUAL TOTAL 63

20 0

ITERATION 0

33 20

500,000 400,000 300,000 200,000 100,000 0

ITERATION 1

ITERATION 2

is risky and invites failure. The problem is illustrated in Figure 4” (http://bit.ly/waterfallpaper) Contrast the waterfall approach with the above chart that shows the same project with 10 deliverables going through an Agile approach. ❚❚ Release Planning: This is where the Agile team performs ‘Just Enough’ planning for the project so that we have a clear ranked Backlog of requirements (called stories in Agile) and a ‘initial’ plan of iterations needed to accomplish our goal. This is the first estimate provided by the team for potential duration of the effort using their ‘estimated velocity’. This approach to planning is the REAL value Agile provides; the structure and discipline of traditional methods with the flexibility to adapt to changing mission/ vision needs!

While the Waterfall team is spending months in ‘Requirements and Design’, an Agile team would have already delivered a few high priority/ valuable items with a few iterations executed under their belt. Why does this matter? Because VELOCITY MATTERS! That is the only real number you can count on for estimating future performance and delivery. VALUE DELIVERY matters because if the Agile project got ‘cut’, you will have something to show for it.

450,000

450,000 288,000

550,000 540,000

450,000

360,000

270,000

170,000 85,000

408,000

550,000

180,000

90,000

ITERATION 0

ITERATION 1

ITERATION 2

that is customer tested and accepted as DONE. In many cases for larger projects it takes several iterations to get enough features that produce a ‘minimal viable product’ MVP. These stories can be software, hardware, business operations or any type of valuable deliverable. Once the team executes a handful of iterations you will start to get ‘real velocity’ data. Velocity is represented by how many points the team got DONE within an iteration. See the sample burn up chart below answering “What is Done? How much is it costing me?”

ITERATION 3

ITERATION 4

PRE-RELEASE

Download a sample Agile Lifecycle Diagram from here: http://bit.ly/ agilelifecyclediagram

Watch these videos The Business ROI of Agile Methods http://bit.ly/UaK0aB Agile Estimating and Planning htt://bit.ly/11c69Gx

Agile Development

RELEASE PLANNING ITERATION 0 1 2 DESIGN ITERATION 1 ITERATION 2 3 SPIKES 1 ITERATION 3 4 ARCH 2 4 ITERATION 4 5 SETUP 3 7 5 DEPLOYMENT 6 8 DONE! 6 10 DONE!

2-4 weeks

9 DONE! DONE! DONE! 2-4 weeks

2-4 weeks

7 8 9 10

2-4 weeks

❚❚ Execution (Iteration 1+): Deliver small chunks of value

ITERATION 4

Consider this:

2-4 weeks

❚❚ Iteration 0: Build the foundation with ‘Just Enough’ setup work needed to make Iteration 1 Demo/ Review successful. Typical deliverables maybe High level architecture diagrams, setup software/hardware needed, high level look and feel designs, team environment setup, risk mitigation spikes and so on.

ITERATION 3

550,000 450,000

2-4 weeks MODERN GOVERNMENT · May - June 2013

Design a Transformation Roadmap

We’ve seen too many Agile adoptions fail because the organizations and teams got stuck after they finished Piloting Agile. Somehow they feel that the logical next step is to stand back and wait for Agile to grow organically to other teams. All the while, leaders once excited and supporting Agile are now attracted to shiny new objects to put their weight behind. This short term attention span can be devastating to successful organization transformation! An Agile Transformation doesn’t just happen organically; it needs a plan and a roadmap for success. There are 3 stages of maturity when transforming to Agile:

Plot Agile

Plot Agile methods on a few projects to prove value, gain buy-in and identify and address obstacles.

Scale Agile

Scale to multiple teams, larger programs and distributed teams to gain wider adoption and confidence in scaling.

Enterprise Adoption

Transform the organization to stable teams and communities of practice. Adopt Agile/Lean Portfolio Management.

May - June 2013 · MODERN GOVERNMENT

So, as a leader of this kind of change you will need to collaborate on designing a transformation strategy/plan that includes: ❚❚ Transformation Vision, Drivers for Change, Objectives, Measures for Success (Why change and how do we measure success?) ❚❚ Define transformation stakeholders (who do we need buy-in from for this to succeed? How will we keep them involved?) ❚❚ Define transformation barriers and mitigation plan (how can this fail and what is our mitigation plan?) ❚❚ Define the Transformation Team (who will lead this on the ground? Run this as an Agile project itself) ❚❚ Roadmap for upcoming quarters (what do we need to get done in the upcoming quarters to meet our goals?) Your roadmap may have high level goals such as which teams to standup and when. The Agile champion’s team might break these high level EPICs (large deliverables) down into smaller chunks to be completed in short iterations (basic Agile) such as: Training for the Blue team, standup ScrumMaster CoP team, address Agile concerns from compliance team, provide coaching for the Yellow team, etc.

Watch these videos Thinking of Agile Adoption? Start Here http://bit.ly/11y7KGB Success Factors When Transforming to Agile http://bit.ly/Ok6bJg Scaling Agile to Multiple Teams http://bit.ly/10KtJ1C

Take on the Spiral of Death! Gov. Planning, Contracting and Auditing Processes

If you’re convinced at all that using traditional to plan for large project invites large risk and waste then consider this: ❚❚ Traditional planning inspired by the Waterfall stages advocates spending significant time and money on heavy upfront planning/ design followed by a signoff to seal the requirements. Development and testing time is usually crunched because the initial ‘planning’ phase usually goes longer than expected (requirements keep evolving and don’t stay fixed like they should!) ❚❚ Traditional contracting advocates that the processes outlined above are signed and sealed in all major legal documents with contracting vendors and suppliers. This means even if you get a contracting partner who wants to deliver sooner and apply some level of agility, they really can’t because the big waterfall deliverables and heaps of documentation are due (shooting ourselves in the foot perhaps?). ❚❚ The auditing and compliance processes now follow. These individuals could care less about the difference in Agile/ Waterfall. Their job is to make sure everyone is sticking to the contract terms and all the deliverables as outlined are being delivered. They assume

that the contract is there to ‘protect the government’, therefore they will apply strict review and compliance procedures to make sure all the rules are followed. So poor John who just got his manager convinced to try Agile on the current government project is about to get a reality check when he realizes the contract doesn’t have what he needs for success and actually mandates many heavy processes that will get in the way of value delivery. Agile contracts should outline the iterative delivery of value and not attempt to fix requirements in detail upfront. You can still have fixed bid contracts with Agile but you should understand that you are buying a fixed number of team iterations ‘Purchasing Capacity and Points’ instead of ‘Purchasing Specific Features’. Agile contracts should also outline the expected gov./contractor collaboration, visibility and Agile practices to be employed and define with clarity the role of the product owner. What can YOU do as a leader to address these issues? ❚❚ Bring the leaders/decision makers from planning, contracting and auditing to have an open conversation about this. Educate them on why you are moving to Agile

and collaborate with them to design ‘lean’ processes that support Agile. Form a strong alliance team that is focused on value delivery, waste reduction and better buying power for the government. ❚❚ In June 2012 OMB released contracting guidance to support Modular Development (Agile and Iterative delivery) that includes sample SOW and pricing arrangements. Begin to write your contracts this way. (http://1.usa.gov/ Qh7g5M).

Further reading: Better Buying Power in the Agile World http://1.usa. gov/15u8C3o Agile Contracting Manifesto http://bit.ly/ZnfwXr Agile Contracts Primer http://www. agilecontracts.org/

❚❚ Take a look at the GAO’s ‘Effective Practices and Federal Challenges in Applying Agile’ (http://1. usa.gov/MPHkM5) and incorporate the best practices in your contracts and start planning ahead for the top 14 challenges they identified. This report isn’t a comprehensive guide but a good place to start. ❚❚ Design incentives that reward for value delivery (story points that are Done). Foster a culture of transparency, measurement, iterative delivery and high collaboration between your government agency and your contractors and suppliers. Do not accept high risk waterfall processes where full testing and delivery are scheduled at the end.

MODERN GOVERNMENT · May - June 2013

Try Agile Successfully (Pilot)

Piloting Agile means choosing a few teams to ‘try it out’ and prove success. We can’t emphasize enough the importance of setting up these pilot teams for success and giving them the autonomy they need to deliver value. Here are some key tips: ❚❚ Choose the right team with the right technical/soft skills and positive attitude towards change. ❚❚ Choose the right product owner who can commit a significant amount of time to the team. They will need to effectively manage customer and stakeholder expectations while providing clarity and focus for the team. ❚❚ Choose the right project. Not too large, not too small, one that has good visibility from leadership. ❚❚ Provide initial training and coaching for the Agile team and also for their management/leadership team. ❚❚ Plan ahead and address organizational impediments (like the spiral of death, command and control functional managers, technical environment or skills gaps, etc.).

May - June 2013 · MODERN GOVERNMENT

Invest in Agile Training and Coaching

The statistics of Agile adoption success and failure as reported by the VersionOne State of Agile Development Survey 2012 (http://bit.ly/18IbPyn) has consistently pointed to the importance of Agile training, education and coaching. Having internal support groups and common tools were also cited as lessons learned. If you’re getting started with Agile, here is what we would recommend: ❚❚ Agile Team Training – 3 days minimum focusing on walking through the entire Agile lifecycle with the team and clarifying roles, expectations, planning and execution processes. The goal should not just be training but also to gain buy-in and generate excitement for the change ahead. If done correctly, this could be a great jump start for the team in the right direction. ❚❚ Agile Team Coaching – Some teams have done well with only training but the risk of failure and reverting back is much higher. You should consider having an experienced internal or external coach supporting the team for the first few months. One Agile coach can coach several teams at the same

time if they are experienced. ❚❚ Leadership/Management Training: This is a big lesson learned for us. We’ve found that teams have struggled when their own management and leaders haven’t really invested any time in learning Agile and how they can support the teams. This should cover challenges such as resource shifting, balancing support vs. project work, the new role of a manager, etc. ❚❚ Product Owner Training: We usually recommend that the product owner attend the team training with everyone else. If you have a team of future product owners and want the existing product owners to go deeper into their role then setting up this workshop would be valuable. ❚❚ Once the team has some experience with Agile then you can go deeper into soft skills like Servant Leadership, Agile Meeting Facilitation, Team collaboration skills in addition to technical Agile skills such as Agile Requirements, Agile Engineering and Agile Testing practices. [MG]

Managing Federal Projects in Agile: Moving Away from the Waterfall

n July of last year, the GAO issued a report chronicling the advantages and the challenges of applying Agile in government. Simply put: Ongoing scrutiny of long-running and expensive IT projects propelled a move to change. And now, with the current sequestration, federal budgets are squeezed further and projects are more at risk. The GAO report includes direct instruction to avoid cost overruns and schedule delays: “To reduce the risk of such problems, the Office of Management and Budget (OMB) recommends modular software

delivery consistent with an approach known as Agile, which calls for producing software in small, short increments. Recently, several agencies have applied Agile practices to their software projects.” So the question is not, “Why Agile?” It’s “How Agile?” How do government agencies adopt a new way to develop and manage programs and move away from tradition-bound practices? And how do Agile practices work in the reality of government organizations? This article provides practical guidance on applying Agile in government, addressing the sheer size, scale

BY Christine Bottagaro & Roncia Roth

and scope of projects in the federal sector.

Walk Away from the Waterfall and into Agile Waterfall has traditionally involved big upfront planning that hinges on an exacting requirements discipline to deliver, well, exacting plans. In contrast, with Agile, you move away from an up-front, formal requirements-gathering phase, as this slows the process of getting to that short increment of minimal viable features. In fact, Agile requirements development and approvals are themselves delivered

So the question is not, “Why Agile?” It’s “How Agile?” How do government agencies adopt a new way to develop and manage programs and move away from traditionbound practices?

MODERN GOVERNMENT · May - June 2013

iteratively and incrementally. This evolutionary approach allows teams to gather stakeholder feedback sooner – and thus deliver faster. The requirements and story elicitation process is embedded in the Agile process itself. In Agile, most requirements are captured in what are called user stories. While that distinction might be seen as merely tactical, the move to user stories is actually a pivotal point in transitioning to Agile from a waterfall-based environment. Deceivingly simple, user stories encourage Agile teams to behave differently. Wellcrafted user stories present the context that leads to better design, more valuable features, and faster results; they are key to team delivery, velocity and estimation. These stories are then delivered in short – typically two-week –timeframes called iterations, or sprints. Written from the perspective of the end user or customer, user stories are managed in the product to-do list, or backlog. This backlog is stack-ranked by what can provide the highest value soonest, and this backlog is worked in order. Details are fleshed out just-in-time, with an emphasis on the user stories slated for the next iteration. Stories further down the list can remain vague until they bubble to the top. By waiting to refine them, teams wait until they have more information. As much of Agile practice

is driven by collaboration among team members and across teams, conversation drives user story definition and acceptance criteria. With these largely informal communications, providing documentation and traceability is another matter. Larger organizations, or those with multiple, distributed teams, find using a centralized Agile lifecycle management tool essential for tracking and historical capture.

Piloting Agile – Where Do We Start? New teams, or teams working with customers who are new to Agile, might want to start their Agile journey or their project with an “Iteration Zero.” They use a short timebox to set the stage for success, understanding project vision, reviewing requirements with stakeholders, and identifying a roadmap of the most valuable features. They use Iteration Zero to set up their environment and ideally deliver at least a “hello world” feature. Most Agile teams will simply dive into delivery at this point. However, an interim step in the journey from plan-driven to valuedriven is to conduct an upfront high-level analysis of the full project, as well as a more in-depth analysis of an initial release or milestone objective. This analysis can provide good context, although it might ultimately prove wasteful when the

team adjusts the long-term plan in favor of new learnings. As the team begins delivering, and the customer begins to trust the team, the weight of these upfront analysis and planning activities are gradually reduced. Cadence is established, focus is clear, and customers see output earlier, allowing for inspection and adaptation to the final release. Planning activities settle into a cadence of midrange Agile Release Planning, wherein teams predict which stories will be delivered in which iterations, looking 3 - 6 iterations out. These plans are refined via more-detailed iteration planning, at the beginning of each 2-week timebox.

Meeting Federal Documentation and Reporting Requirements with Agile So how does this apply to government projects and programs? Explicit documentation demands and regulations are brought into user stories through the acceptance criteria for those stories. When implementing a user story, the team completes tasks that include reporting requirements of any kind, including those specified in Exhibit 300. As the team works on the story, the specific acceptance criteria dictate whether the story is complete or not. The “definition of done” for that story has all reporting and documentation requirements.

Fixed timeline reporting deadlines are built into the corresponding iteration, including any specifics. If the report due date falls outside of an iteration, results from the latest iteration can be shared, or align the iterations with the reporting cycles. Alternatively, engaging the customer throughout the process, sharing achievements and progress, will gradually reduce the volume and frequency of the requested reports.

Agile and Government Contracting: Productive Co-existence Agile delivery methods don’t actually change the fundamental nature of contracting. The basic firm fixed price (FFP) and time and materials (T&M) structures, as well as the many hybrid permutations in between, still exist. Just as when using traditional delivery methods, with a FFP contract a certain amount of up-front analysis and design can reduce risk. Regardless of your delivery method or contracting structure, real success is about building a trusting cooperative relationship with the customer. Applying Agile helps this process. Valuing customer collaboration over contract negotiation, Agile methods engage customers earlier in the process, removing uncertainty over priorities, trade-off decisions, and how success is defined. The visibility and value-based, data-driven progress checkpoints of an

With Agile, you move away from an upfront, formal requirementsgathering phase, as this slows the process of getting to that short increment of minimal viable features.

Done well, Agile allows teams to deliver more program value with less time and effort.

Agile approach make contract management and change control natural and cooperative. To be clear, Agile does not remove contractual compliance. Contracts that explicitly require detailed up-front analysis and documentation must be honored. However, there is often more flexibility in the form and level of detail in these documents. An Agile team serves its customer by satisfying these requirements in a lightweight, high-value manner, with an emphasis on getting past the documents and moving the program into development as quickly as possible. This is because an Agile team understands that the best analysis and the most thorough risk mitigation comes from testing, validating and iterating on a real product.

Going Agile in Government – Pushing the Rock Up the Hill Moving to Agile in government can be hard, seeming akin to Sisyphus-like punishment. Simple in concept, it is decidedly difficult in application. Perhaps unsurprisingly, the biggest challenge is altering mindsets and changing the underlying organizational culture. Agile can be seen as disruptive or anarchic, when in reality it produces a more consistent delivery discipline and encourages true engagement and thoughtful behaviors. Some groups try to ease the shift by adopting Agile in phases. However, this approach introduces significant risk in the resulting hybrid, or mixed, methodology. Hybrid methods reduce the value of both

waterfall and Agile practices, adding risk to the delivery and overall programs. Typical government projects have uncertainty, complexity and unknowable requirements. Clearly an incremental approach with frequent feedback is necessary to define, adjust and apply learnings throughout the project. A more reasoned approach is to adopt Agile wholly, but in a small group. Start with a pilot project and commit to Agile for all team members and stakeholders. Coaching, resources and a purpose-built Agile lifecycle management tool are key success factors. Choosing a good pilot project requires paying attention to two aspects: Is the work a good candidate for Agile, and, can you set up the environment for success? For the first, choose a project that is especially likely to benefit from Agile: One where there is uncertainty around either the requirements or the solution, but also where there is relatively low complexity -- either technical or human complexity. In terms of environment, choose a project in which you can ensure the following: ❚❚ A small, cross-functional team that is dedicated to the work of the project ❚❚ A person who can fill the role of Product Owner by being embedded with and dedicated to the team and by gaining consensus from stakeholders on goals and features ❚❚ Co-location can reduce risk; a distributed team must have good communication tools

and strong facilitation skills among team leads Finally, you can pilot Agile without the express support of the customer, but you will achieve far greater results if customer supports the approach. Often that first demo of working software and that first opportunity to provide feedback wins the customer over. Seek to sell the benefits of an iterative, learning-based approach. Agile is a tremendously effective process methodology for many different environments, allowing for change and continuous input throughout the program or project. Done well, Agile allows teams to deliver more program value with less time and effort. Success requires re-education, training and a dedication to the practice, resulting in on-time, on-budget projects with less risk and higher acceptance. In today’s environment of budget challenges, effective Agile projects can make all the difference. From last year’s A Common Approach to Federal Enterprise Architecture, “Success in accomplishing an Agency’s mission and optimizing resources requires a coherent and consistent understanding of program and service performance, and agile planning and development processes. This coherent view and agility becomes more important in resource-constrained operating environments.” Or, as management consultant W. Edwards Deming wrote, “It is not necessary to change. Survival is not mandatory.” [MG]

MODERN GOVERNMENT · May - June 2013

Government Agility: How to reduce IT cost using Agile

BY Devon Morris

ou have heard the buzz words - Scrum, continuous integration and test driven development. You have also heard the myths: Agile does not work for the Government; Don’t use agile on large projects; Agile teams don’t plan. We could spend time debunking these myths, however, it would not add any value to this article. With a little research, you can find the truth. Take a journey with me to discover ways that Agile can help the government with Information Technology (IT). According to the Office of Management and Budget, federal IT spending is estimated to be $74 billion this year, which does not include the local government, legislative or judicial branches. Roughly one third (or $25 billion) is mismanaged, including cost overruns and duplications. By any standard, these numbers are staggering. What can the government do to be more efficient with the dollars that are entrusted to it? How can they reduce the cost of IT or at least better manage the $25 billion? Simple - GET AGILE.

May - June 2013 · MODERN GOVERNMENT

What is Agile anyway? Agile is a different way of doing software development. The term “Agile” is derived from the Manifesto of Agile Software Development, known to most as the “Agile Manifesto,” which was created in 2001 by a small group of people that were using lightweight frameworks for software development. The Agile Manifesto consists of 4 values that we have come to live by: ❚❚ Individuals and iteration over processes and tools ❚❚ Working software over comprehensive documentation ❚❚ Customer collaboration over contract negotiation ❚❚ Responding to change over following a plan Although there is value on the right, we value the things on the left more. All Agile frameworks and methods align with these values.

There are 12 principles that support the Agile Manifesto: 1. Customer satisfaction Delivering valuable software 2. Welcome changing requirements, even late in development 3. Frequent delivery of working software 4. Working software - The principal measure of progress 5. Sustainable development and pace 6. Close, daily cooperation between business people and developers

7. Face-to-face conversation - The best form of communication (co-location) 8. Build projects around motivated people 9. Continuous attention to technical excellence and good design 10. Simplicity—the art of maximizing the amount of work not done 11. Self-organizing teams 12. Regular adaptation to changing circumstances

Think practices not frameworks Maybe you have used Scrum or XP. Maybe you heard of Feature Driven Development or the Crystal Orange. Each agile framework is a collection of practices that have been proven to work well together and drive better results. These agile practices empower teams with tools that can exponentially increase productivity. These same practices are building the blocks for demonstrating value each Sprint, while gaining trust with customers, stakeholders, teammates and most of all, oneself. Although we talk about frameworks, it is the common agile practices that help us continually improve, so let’s talk about the common practices that can help

Quicker Time to Market Agile encourages early and continuous delivery of software to satisfy the customer. It offers a set of tools that foster improved productivity, shorten the feedback loop and deliver

based on value. Functionality is released incrementally and accelerates return of value from the government and citizens. Here are some of the practices that help improve time to market: RELEASE OFTEN – Release Often is the practice of getting the software out to the end customer as often as possible without inconveniencing them. This will test your deployment process and help streamline it, which removes waste and clearly creates more value for the customer. CROSS-FUNCTIONAL TEAM – Cross Functional Team, as a practice, is very important. It refers to having the necessary expertise on the team to take a requirement from concept to deployed for the user or customer. This allows the teams to eliminate waste and bottlenecks. It enables team to be iterative and incremental, which support the team ability to release early and often. ONE DECISION MAKER - One Decision Maker represents the users of the system and has knowledge about the business domain. This person owns the backlog, writes and clarifies requirements, and accepts or rejects the results. This provides the team with a go to person for feedback, confirmation of requirements, and demonstration of results. This person prioritizes the backlog to get the highest value targets done first. All these things help to improve time to market.

Fewer Bugs Most software development environments are breeding grounds for a few “friendly” guests. These guests arrive for a variety of reasons including human error, communication failure, poor design logic and unrealistic timeframes. When a time crunch hits, the first thing to go is testing of every kind and people begin cutting corners instead of re-evaluating the committed. Here are a few practices that help foster fewer bugs being created:

Although we talk about frameworks, it is the common agile practices that help us continually improve, so let’s talk about the common practices that can help

ACCEPTANCE TEST DRIVEN DEVELOPMENT (ATDD) – Acceptance Test Driven Development allows us to build projects that deliver what the customer wants by using acceptance testing to validate requirements. This creates a trustworthy safety net because, as you incrementally meet the needs of the customer, errors are caught early, mis-communication is discovered sooner and ambiguities are cleared up faster. This results in a code base that is continually tested and reduces re-work, which leads to fewer bugs. PAIR PROGRAMMING – Pair Programming is the practice of two developers working together on the same computer to build functionality. One developer works on building the code with hands on the keyboard, while the other developer is looking forward at the design and reviewing the code that has been completed. Two people working on the same problem improves

MODERN GOVERNMENT · May - June 2013

the design and reduces defects, while building in a continuous code review process and collective code accountability. TEST DRIVEN DEVELOPMENT – Test Driven Development is the practice of writing clean code by writing tests prior to writing to just enough code to pass the tests and refactoring. At the core, this practice is ensuring the software’s technical quality with tests that are written and maintained by developers to enable change of design and reduction of the cost of finding and fixing bugs. This practice takes time and requires discipline otherwise the tests become stale.

Stop Building Everything Many government projects seem to be infused with a culture of waterfall norms and behaviors that support people building everything perfectly. Imagine a world that was imperfect and projects are only given 20% of the budget and are held accountable for the results in order to get more money. You’ve heard of the Pareto principle (aka the 80/20 rule), which is the law of distribution and states that 80 % of your results come from 20% of your efforts. If 20% of our efforts delivers 80% of the value, common sense would suggest that we build our most valuable and most used features first. The research from the Standish Group supports that 20% of requested features are

Functionality Usage 7%

45%

13%

16%

19%

always or most often used (See Figure 1). Think about the software that you use. Now ask yourself what percentage of the feature do you use most of the time... Pause... Good reason for us to stop building everything. Here are a few practices that can help you get on the right path of not doing everything: PRIORITIZATION SCHEMES help people prioritize work. The most common scheme is simple prioritization. Simple Prioritization is a relative prioritization scheme from 1-n where no two items can hold the same prioritization slot. Another scheme is MoSCoW, which is divided into 4 categories - Must Have (mandatory), Should Have (desirable), Could Have (nice to have) and Would Have, But Can Wait. There are many prioritization schemes that are being used by teams.

PARTICIPATORY DECISION MODELS are when a team needs to make a decision. One example is “A Fist of Five”, where each team member raises one hand to vote with their five fingers. When the hand is raised, each person must pick one of the six votes - a closed fist suggests strong disagreement, 1 finger suggests slight disagreement, 2 fingers suggests slight warm disagreement, 3 fingers suggests Luke warm agreement, 4 fingers suggests agreement and 5 fingers suggests strong agreement. OPEN SPACE TECHNOLOGY is a simple way to run productive meetings for five to 2000+ people and a powerful way to lead any kind of organization, in everyday practice and extraordinary change. It is known for beginning without a formal agenda and harnessing the power of self-organization. This is simply one you have to see for yourself.

If 20% of our efforts delivers 80% of the value, common sense would suggest that we build our most valuable and most used features first.

Conclusion If you are already using an Agile Framework, consider using some of these additional practices. Maybe you are doing waterfall. If so, just start with one agile practice to experiment with how it works. Gather the results to find areas of improve and implement the improvement. When you get comfortable, try another practice. Keep growing with practices and soon enough you will get to the point where you are ready to pilot an Agile Framework to implement this new found knowledge. These are very simple practices that can help the government reduce cost in IT. [MG]

Using Agile to Inspire Loyalty BY Michael Swansegar

gile transformation is often confused with implementing a tool or a process change. Those are symptoms, not the end result. The end result is inspiring partner loyalty. There is a stark difference between a loyal partner and a paying customer, just as there is between a paid employee and one that is loyal. These simple use cases can be termed internal and external customers. Customers are part of a market, whether it is your commercial market or internal company market (the employee pool). Nowhere else can this be evident than in our modern government. The American democracy is a government by the people and for the people. We have a civilian population and then we have a loyal civilian population. This is not to say we have anarchists and then we have sheep. Rather we have those who are loyal to our

cause, to our varying beliefs and needs. We have those that pay taxes and obey the law, and we have those that inspire the law and add the word modern to government. The loyal civilians are normally between 15-18% of the market. Marketing 101 calls this Maloney’s Rule. Sometimes they are called agile, innovators, creators and visionaries. Many people in the government do not think we need an agile culture. Why is this? When I was teaching at a Federal office in Washington DC

There is a stark difference between a loyal partner and a paying customer, just as there is between a paid employee and one that is loyal.

on agile culture, I was told, “We don’t need to concern ourselves with loyalty, we make laws here.” This was disheartening, to hear. However, just like in a commercial company, we have paid employees and we have loyal employees. This Federal office is designing the software exchanges for the Affordable Care Act (termed ObamaCare). We can say that everyone must pay for the end game product and build the product to meet the law. Individuals would not be wrong with that mindset, as it is reality. Nevertheless, we can be agile and still want to inspire loyalty and term it differently. We can build the product to the law and call it done. Or We can build a product to the law and take into consideration that 50% of Americans do not agree with buying or potentially using it.

MODERN GOVERNMENT · May - June 2013

The majority of that 50% tend to fall into the Republican party. The goal is to not only get the Republican to buy the product but to see value in the product and the idea behind it. For example, if their child is sick, they now have health care whereas before they may not due to preexisting conditions. Agile isn’t about the process change or the purchase of a product, it is about inspiring loyalty and identifying value as the end game result. How does agile accomplish this? Let us look at the Scrum process to see how psychologically we are inclined to become loyal to a product or idea. Pre-planning meetings are designed to force the Product Owner (the voice of the customers) to convey the vision to the delivery team. The vision is in the form of user stories, small slices of value. The delivery team, also known as “development”, reviews them and voices concerns about the individual stories being too small or too large. If the story is too small, they are indicating that the Product Owner is telling them how to do their jobs. This is not the place for the business minded Product Owner. If the story is too large, the Product Owner is still in the clouds, being the visionary. The Product Owner needs to come down to a lower altitude and provide a tactical pathway for the teams to build and believe in. This also forces the Product Owner to go back to the customer base to get more information and engage their thinking. Inspiring a customer to participate, give input and more importantly identify their needs will bring about the “right

May - June 2013 · MODERN GOVERNMENT

Agile isn’t about the process change or the purchase of a product, it is about inspiring loyalty and identifying value as the end game result.

product” faster. Planning meetings stimulate the delivery team to commit to the forecast of deliverables. This encourages your internal customer to believe in the product and method of delivery. Do you think only left wing Democrats are building the software exchanges? Absolutely not, the delivery team is made up of people from all political spectrums. If the delivery team is committed, they will want to build the right quality thing and an inspiring belief to go with the tangible good. The daily stand-up meeting brings visibility to the company, and to the Project and Product Manager roles. These individuals (titled Scrum Master and Product Owner) go back to the business with visibility of the current pulse of the product and belief. They remove impediments whether it be security, a distant

customer, an over-commanding manager or any thing or belief that stands in the way of producing value. The daily standup also changes the employees to become loyal employees. They are loyal team members to each other, constantly challenging each other to commit and adjust the workload. The demo meeting inspires both the internal and external customers. The delivery team does a show-and-tell. The customers provide feedback. Why? The customers are there, in tune, putting their blood, sweat and time into this product and belief. They may be of the 50%, but slowly come to believe that if this must be in place, it should be of the highest value, lean, and lowering cost to our health care system. In the commercial world, the customers “are your employees without being paid, because they constantly review

Agile is about people, people, people. Many think it is a tool or a process change. Instead, as you have just read, everything is about the interactions and the morphing aspect of belief systems.

your product and give you the data you need to build the right product faster.” The retrospective meeting motivates change, adaptability and most importantly, loyalty. The delivery team is honest, open, and direct about what went wrong and what succeeded. Like a healthy family, they “mine the conflict” (5 Dysfunctions of a Team – The Table Group) and get in arguments. This helps because they can commit to being a team, a family, because all options are on the table. Offensive sometimes yes, but never is an idea about improvement hidden. The retrospective meetings have an action plan. This output encourages the customers to become partners because they see a team is maturing in how they work together. Everyone is engaged, even if indirectly, to make things better. Agile is about people, people,

people. Many think it is a tool or a process change. Instead, as you have just read, everything is about the interactions and the morphing aspect of belief systems. A tool may encourage natural human behaviors to occur or stifle them. A process change might make things easier or harder, but nothing is stronger than a culture shift, which occurs in people. The culture shift is far reaching to your internal customers and external customers. Tools are tangible but devoid of human loyalty. Processes are not tangible; they are a framework of the mind and can’t inspire loyalty without human commitment. Regardless of the product or idea, you need 15-18% of the market to believe in it. This is why those odd rubber shoes (Crocs) dominated the market for a while. 15-18% of the shoe market they were trying to reach

thought they were the right shoe. That all changed when kids started getting them stuck in escalators. There is a reason why individuals stood in line for 5 hours to get the first iPhone, but now the majority read their contracts to see if they want to break them before upgrading. As markets change and buying conditions adapt, we constantly have to evolve to target the 1518%. This is the strength of the agile culture. As more people believe, you have to fight to keep it going. Products and ideas change over time to be right. If you don’t change, they will become wrong. The government needs more loyalty, more compromise and more beliefs. America was founded by 15-18% of a civilian market. Our founders were agile. They believed we needed to change to become a government of the people by the people and for the people. [MG]

MODERN GOVERNMENT · May - June 2013

now Donâ&#x20AC;&#x2122;t miss the next issue of MODERNGOVERNMENT Visit www.moderngovt.com to subscribe or read the issues you missed!