Agile Engineering, SAFe and DevOps: A Roadmap to Adoption at the Potomac Forum
Most Agile transformation efforts in the government begin with the Scrum process. However, many agencies feel that they have reached a plateau and are ready to move through to the next logical steps. Improving digital services delivery and getting working software into the users’ hands shouldn’t stop with just Scrum. As agencies progress in their Agile transformation, they begin to see the value of adding the Agile engineering practices, such as Test-Driven Development and Continuous Integration to improve code quality and the downstream delivery of fully functional and tested software. And what about the challenges of scaling Agile for very large projects? What might a strategic progression for Agile transformation look like? This will be the focus of our ninth Agile in Government workshop, Agile Engineering, SAFe and DevOps: A Roadmap to Adoption at the Potomac Forum, Willard InterContinental Hotel on Thursday June 14, 2018.
Full Agenda and Registration can be found here.
Notes from Agile 2015 Washington, D.C.
Having lived in Washington DC area for over 25 years, my experience caused me to presume that the majority of the audience at the Agile 2015 Washington DC would primarily consist of people working in the public sector, given our geographical proximity to a long list of federal agencies. It was not unrealistic for me to expect that the speakers at the conference might tailor their presentations and discussions to this type of audience. The audience actually turned out to be quite diverse, rendering my assumptions inaccurate. However, I could not help to feel somewhat validated after listening to the first key note speaker. Indeed, the opening presentation by Luke Hohmann entitled “Awesome Super Problems” focused on tackling “wicked problems” such as budget deficits and environmental challenges. Wicked problems, as described by Mr. Hohmann, are not technical in nature and cannot be solved by small Agile teams of 6-8 people. These problems deal more with strategic decision-making that may result in long-term consequences, intended as well as unintended. They impact millions of people and they require broad consent as well as governance. Hailing from the San Jose, California, Mr. Hohmann discussed how implementation of Agile methodologies helped the city tackle some “wicked problems” such as a budget deficit of 100 million dollars.
Planning and Executing
Solving major problems such as budget shortfalls generally require a great deal of collaboration between stakeholders with competing priorities. Mr. Hohmann stressed that the approach should focus on collaboration over competition, or in Agile terminology, “customer collaboration over contract negotiation”. Easier said than done? Maybe… To help facilitate this collaboration, Mr. Hohmann assembled a conference of public servants such as city planners, police and fire chiefs, and other community leaders. There were several discovery sessions where people could get answers to questions like how much money would be saved if the fire department removed one firefighter from their teams and what impact to safety that may entail. The group was broken down into small tables of no more than 8 people and one facilitator provided by Mr. Hohmann. The group was presented with the list of major budget items and subsequently was compelled to engage in budget games in which participants were basically bidding to get their high priority budget items included in the next budget and negotiate cuts by trading these items. Afterwards the players had a retrospective and offered feedback.
Retrospective and Outcome
Feedback provided by the participants showed that competition was replaced by collaboration. Participants tended not to get into heated arguments because the games inherently encouraged compromise. Small groups helped cut down on distractions and side conversations. The participants also reported that the game was fair since every player possessed equal bidding power. Interestingly, the final outcome resulted in surprising consensus over the budget items, as the majority of the participants actually ended up prioritizing their items very similarly after the competition aspect was removed. The “democratic” aspect of the collaborative approach helped eliminate animosity and partisanship which are not uncommon, as have been witnessed in the U.S federal budget negotiations. This experiment seemed to yield the desired outcome of tackling the imbalanced budget and was touted as a success, attracting attention of more San Jose residents.
Scaling
To tackle other public issues such as school overcrowding and water shortages, Mr. Hohmann attempted to repeat the process, but the number of participants has increased to the point where a large conference hall was needed. In order not to upset the budget by renting a giant conference hall, Mr. Hohmann and the local government set up an online forum that accepted a virtually unlimited number of participants, yet still assigning them to groups of about eight people and increasing the number of groups. The participants played other games such as Prune the Product Tree which basically involves prioritizing the list of problems the public wants to tackle. The feedback was even more positive as the majority of the participants actually preferred the online setting even more. They reported even less distractions. The data was easier to collect and aggregate, giving the participants almost an immediate view of how the game was progressing and how the priorities were moving.
Conclusion
One main takeaway I got from Mr. Hohmann’s presentation is one of encouragement to be creative. Mr. Hohmann stressed the importance of focusing on what he described as “common ground for action”. The idea is to focus on generating a list or backlog of actionable items. The process or exercise to get to the desired state can vary, and Agile methodologies can help folks get there, even when tackling wicked problems.
External Links:
http://www.innovationgames.com/budget-games-guide/
http://www.innovationgames.com/prune-the-product-tree/
Further reading:
http://conteneo.co/san-jose-residents-play-4th-annual-budget-games/
Art Chantker, President of Potomac Forum, LTD and CC Pace cordially invite you to our next exciting Agile in Government Workshop V, May 20 at the Willard Hotel in Washington DC. Workshop V will have something for everyone, from new adopters just getting started with Agile in their agencies, to seasoned Agile practitioner scouring the landscape for new horizons in Agile disciplines and trends in the Federal government that they can put to practical use now.
Art has led the Potomac Forum in training thousands of government and industry professionals throughout the country on a wide variety of information technology, acquisition, financial, and management subjects of importance to our government. Over the years, Art has invited CC Pace back again and again to present on the full spectrum of topics around Agile software development and Agile project management along with officials from the Department of Homeland Security, USDA, the VA, Department of Education, NGA, GSA and many other Federal agencies.
On May 20th we will be conducting our next Agile workshop at the Willard Hotel for the 2015 Potomac Forum series. The focus will be on Agile and Lean best practices, including Scrum, Kanban and scaling Agile for larger projects and programs. In addition to the seasoned Agile trainers from CC Pace, our confirmed government speakers include Karen Ritchey, Assistant Director Applied Research and Methods
U.S. Government Accountability Office; Bill Pratt, Office of the CIO, Policy & Planning-SELC/Agile IT, Department of Homeland Security; and our keynote speaker Greg Godbout, CTO of EPA, and co-founder and former Executive Director of 18F, the government’s new center for inter-agency Agile services.
There is a tentative agenda already posted on the Potomac Forum website, pending some agenda changes once other invited officials are confirmed. If your agency is starting down the path of agility, or you want to bring your adoption efforts up to the next level you should attend this workshop. We look forward to seeing you on the 20th.
As you many have read in my prior post about The Agile Impact regarding “Telework and Modified Schedules”, there are some variations on how moving to being Agile has impacts on the government agencies that are different than those seen in private industry. In this blog, I will highlight some of the impacts that contracts and vendors have on the Agile transition in government agencies and outline some things to watch out for.
To set the stage, I first want to point out that we are not examining the contracting styles or types, but we are looking at how having most of the team members being outside of the agency, working for a vendor which is based on a contract, changes the landscape of how Agile is seen and implemented.
Before we get too far into the impact to the agencies, let’s set the stage a bit on what an Agile team really is: dedicated! You can read more about the definition of an Agile team by reading another post: “The Reality of T.E.A.M”. In short, an Agile team is formed with the intent of being dedicated to the team and to the solution they are delivering. The team is intended to be created so that they remain a team, even after the release happens. An Agile team is not created around their specialties, but more by pulling specialties together and having them work together to accomplish a goal.
Now that I’ve set the stage on what an Agile team is, let’s dive into the impact agile has on contracts and vendors…
In many government agencies, the teams that do the work building the solution are typically not government employees, but rather they are employees or contractors of a vendor that has won the contract. These teams will sometimes be allowed to sit at the agency, but more often I’ve seen that they will be offsite, either at the vendor’s office or at their home. This style of team poses a few issues when comparing to the definition of what an Agile team is. Any ideas on what some may be?
When a contract is awarded to a vendor to build a solution, they usually go form a team to complete the contract. In most cases, the vendor will assemble a team that has the skillset they need to complete the solution. This team, which probably will not be sitting within the agency, needs to be able to communicate and collaborate with people within the agency on a daily basis. This poses a number of issues since they are not co-located and most likely not on the same network. It becomes a challenge for the team to be as effective as they can be; the team needs to work much harder to communicate and collaborate. When this happens, communication and collaboration have a tendency to fall away and take a back seat to ‘just get it done’.
Also, when a vendor has their own team, which is not affiliated with any particular agency, the team in all likelihood has their own way of doing things and their own ‘set of rules’. The team’s way of doing things may not align with the way that the agency does things, but they will need to find a way to work together. If they don’t figure out how to work together, they will never really deliver the value requested.
Another hiccup in the vendor-agency relationship when moving toward Agile is the constant need for the agency to evaluate the team according to the contract. While the vendor may understand the shift from a ‘contract-based’ relationship to one that is more ‘collaboration-based’ (see value 3 of the Agile Manifesto), they are still responsible for delivering the contract. This puts the team, based at the vendor, in a bit of an interesting position: do they collaborate and deliver based on the communication/collaboration OR do they follow the letter of the contract and deliver based on that? I’ve seen a couple instances, not many however, that manage to have both, but it really depends on how the contract is written and how the vendor’s relationship is maintained.
In most instances, the agency’s relationship with the vendor relies heavily on the contract and ensuring the things outlined in the contract are what are delivered. However, the vendor and the agency can find ways to accomplish both – an Agile transition AND delivering to the contracted agreement. The biggest thing they both need to keep in mind is that they need to communicate and collaborate in order to ensure both the value and contract are the drivers.
One of the easiest ways to ensure that both the transition and contract are met, is to have a vendor that understands and supports being Agile. When a vendor is already aligned with the Agile values, it makes things much easier to ensure the communication and collaboration are the basis for the delivery.
On January 28, CC Pace and the Potomac Forum collaborated once again to present their latest in the series, Agile Development in Government Training Workshops. In addition to CC Pace’s presentations and training sessions, speakers and panelists included officials from the Department of Homeland Security (DHS), the National Geospatial-Intelligence Agency (NGA), and the Government Accountability Office (GAO). Several other Federal agencies were represented in the audience. The workshop participants were challenged to take a fresh look at what agility, “being agile”, really means. One top Federal official posed five questions for us to consider:
- Can we have a Lean bureaucracy? If you had one more incremental dollar for your project, what would you spend it on? Right now we’re spending that dollar on oversight and documentation instead of valued results.
- Shouldn’t we be looking at best practices, cutting edge approaches instead of arguing about Waterfall vs. Agile?
- Why not benchmark to leaders in Industry like Netflix and Amazon?
- Why doesn’t top IT talent think the Federal government is the best place to work?
- Why is it acceptable to spend billions of dollars and take forever to build software?
One of the key Agile principles that was emphasized throughout the day, both by CC Pace and the government officials, was the value of empirical learning. By building software incrementally and taking advantage of short feedback loops facilitated by continuous communication with end users and other stakeholders, the developers can apply what has been observed and commented on to improve the process and more accurately inform the schedule, requirements and production as they go forward. This approach greatly reduces project risk while improving quality and usability of the finished product.
Officials from some agencies that are successfully implementing Agile practices already, cited recent initiatives like the publication of the TechFAR, and the Digital Services Playbook, as well as the establishment of GSA’s 18F (a Federal Agile services group), that are beginning to remove some of the roadblocks to agility in the Federal Government. Since there were a number of workshop participants who were new to Agile and Lean Thinking, CC Pace included an excellent session on Agile Basics, laying the foundation for our working lunch session, What challenges will your agency face when trying to implement Agile? The working groups came up with five common challenges: 1) Cultural resistance to change, 2) Regulatory issues (all the way up to Congress), 3) Old measures that may not be relevant in the new environment (EVM), 4) Need for training of executives and middle managers, and 5) Inability to attract top talent to government from the private sector.
Our panel discussion included comments on these five issues as well as on the fact that Waterfall project failures have soared into the billions of dollars over time. There has to be a better way. However a note of caution was sounded since many vendors are claiming “agile” when there is nothing agile at all about their approach. Agile is not a “silver bullet”. Agile is not going to fix a poorly managed project.
CC Pace wrapped up the day with a presentation by their Federal Practice Director on cutting edge practices in Lean and Agile in the session What’s on the Agile Horizon and Why it is Important for Government, followed by the final presentation Putting it All Together – An Agile Roadmap, by CC Pace’s Managing Director. The workshop received excellent evaluations from the participants. We hope you can join our next Agile in the Federal Government Workshop at the Potomac Forum this coming spring.
As discussed in the first post in this series Agile in the Federal Government – Going, Going, Gone Beyond Scrum, the history of Agile adoption in industry took the path of usage of Extreme Programming (XP) followed by the combination of Scrum and XP. In the government, the adoption of Scrum alone has become the de facto method of Agile adoption with the use of the term Agile and Scrum even becoming synonymous in some agencies. In our latest white paper we discuss why we believe the use of Agile Engineering Practices such as XP is crucial to the success of Scrum projects for the Federal government and that the government can again benefit by combining Scrum with XP as is already in use by industry. We believe this is because Agile Engineering Practices enhance the empirical process control (Inspection, Adaptation, and Transparency) of Scrum.
According to the latest State of Agile Survey by VersionOne, the top three XP techniques in practice are Continuous Integration, Test-First Programming, and Shared Code. What XP practices are you using at your agency? Is the use of them improving quality?
About a year ago, I co-authored with Bruce Yang a whitepaper entitled “Agile in the Federal Government – Moving Beyond Scrum.” In that whitepaper, we predicted that the government would follow the lead of the private sector to adopt Agile solutions beyond Scrum to gain broader benefits. Specifically, the private sector had learned that Scrum by itself would not effectively support scalability to replicate the success of one project across the entire organizational structure and adopted scaling frameworks such SAFe. Similarly, it realized that the Scrum methodology was not necessarily appropriate for all types of work and looked for alternatives, most notably Kanban.
I am happy to report that the federal sector has in fact followed this anticipated pattern. Some examples:
We’re trying to compile a more comprehensive list of agencies that have adopted Agile techniques beyond Scrum and how well they have been working. Would you mind sharing any non-confidential examples that you might be aware of?