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.
In Daniel H. Pink’s book, Drive: The Surprising Truth About What Motivates Us, he discusses the motivations of knowledge workers. He makes the case that knowledge workers are driven by intrinsic factors and not the extrinsic factors of punishment and money. As he states, “Carrots & Sticks are so last Century. Drive says for 21st century work, we need to upgrade to autonomy, mastery, and purpose.” A great video covering his work is viewable at https://youtu.be/u6XAPnuFjJc. For most research on extrinsic and intrinsic motivation start with the work of Edward Deci from the 1970s.
Here is an explanation of the three types of motivation:
Autonomy
This is the granting of control over their own work to those doing the work. Guidance is fine, but too much and it becomes the micro-management which can be detrimental to motivation. Valuable feedback, performance metrics, and boundaries can be all that is needed.
Mastery
This is an innate desire to get better at doing some task. If it is too easy, workers may get bored. If it is too hard and little progress is made, workers often get frustrated and give up. So tasks must be challenging, yet doable. And fostering an environment of continuous learning will add to motivation.
Purpose
This is tying the work to a cause larger than themselves. Workers, who believe in that cause, feel that there is importance to the outcome of the work beyond just their own accomplishment.
DevOps?
According to Wikipedia:
DevOps is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.
That certainly sounds like knowledge work to me. But are the three motivations the same for software developers and operations staff? And what might they be in a DevOps team. Let’s take a look in the chart below:
The management challenge then is to create a supportive culture where DevOps can flourish and the knowledge workers will be highly motivated by having aligned motivations of Autonomy, Mastery, and Purpose.
Although our headline says Workshop VI, this is actually our seventh engagement with Art Chantker’s Potomac Forum on Agile in Government. I love being part of these workshops on so many levels. The historical Willard is so elegant and Art is a gracious host. But the real value of the Potomac Forum Agile workshops is the in-depth expert knowledge provided by the trainers, guest speakers, panelist and interactive audiences in attendance. For this latest workshop our instructors were David Patton, Government Practice Director, and Ashok Komaragiri, Senior Technical Consultant, both from CC Pace. Our keynote speaker and panelists included senior officials from the Department of Homeland Security and the United States Patent and Trademark Office. A very diverse audience included some people from industry and government representatives from NIH, National Science Foundation, Department of Agriculture, Library of Congress, Social Security Administration, FDIC, and other Federal agencies.
We kicked off our 2016 series with the topic DevOps – Taking Agility in Government to the Next Level. Now that more and more agencies are starting to employ some Agile principles and seeing good results, the concept of better integrating the development teams with the operations teams is starting to garner more interest. David Patton took us through the basic precepts of DevOps, and painted a clear value proposition for considering this approach. He helped the attendees to understand that both DevOps and Continuous Delivery are part of Lean Thinking, which has its roots in the manufacturing industry, and which has long been recognized as essential for process efficiency improvements.
Our keynote speaker posed the question that our government attendees were anxious to hear the answer to – Can DevOps Work Here? His agency is proving that it can, with a combination of specific Lean-Agile practices combined with innovative procurement methods for facilitating the acquisition of the necessary resources to make it work “here” – in government.
An intriguing all-graphics presentation was the delivery approach of one of our other senior government officials. In speaking about Lean-Agile architecture she highlighted the importance of keeping it simple, emergent, modular and loosely coupled. This approach builds the framework for changes that we know will come. She also emphasized the importance of using seasoned coaches for knowledge transfer as a key part of the successful implementation of these concepts.
After our working lunch David Patton facilitated our government panel of experts on how they are making DevOps work in their respective agencies. He then continued with a presentation on the Lean concept for managing the flow of work and identifying bottlenecks and constraints in processes known as Kanban. Finally, Ashok Komaragiri, Senior Technical Consultant for CC Pace, took us through a DevOps roadmap in his presentation A Guide to Your DevOps Journey. He encouraged the attendees who want to begin adopting DevOps practices to break knowledge silos, integrate code continuously, and automate deployments as much as possible.
Reviews of the workshop coming in from government attendees have been outstanding. One government official said that it was “One of the most informative training workshops I have attended”. If you haven’t attended on of these Agile in Government workshops, you should.
On November 5, 2015, Phil Fewell, Managing Director at CC Pace, and I attended ACT-IAC’s Emerging Technologies Community of Interest sponsored workshop held at GSA Headquarters on the topic, Overcoming the Challenges of Acquiring Agile Digital Services in Government. I moderated the panel of experts on the subject which included Traci Walker from US Digital Service, one of the original architects of the TechFAR and the Digital Services Playbook; Eric Cho from DHS’ Procurement Innovation Lab; Navin Vembar, the IT Director for the Integrated Award Environment (IAE) who we work with at GSA; and Dave Zvenyach with 18F, a GSA entity that provides digital services, including some Agile development to other Federal agencies.
The discussion centered on how the acquisition process and the contractual language of the Request for Proposal (RFP) can be structured in order to better facilitate acquiring Agile digital services, while still adhering to the Federal Acquisition Regulation known as the FAR. Attendees heard what others are doing in the government to support their agency’s adoption of Agile methodologies and frameworks.
Traci Walker, who has 15 years of experience as a Federal Contract Officer, emphasized that the TechFAR document, of which she was a key contributing author, should make it clear to all agencies that the FAR in no way prohibits the adoption of Agile development practices in government. In fact it encourages such innovation. Eric Cho outlined some of the experimental approaches that the Department of Homeland Security (DHS) has been implementing to acquire Agile services in their component agencies. David Zvenyach from 18F shared some of their recent awards to industry and how 18F interfaces with government agencies interested in their services. Navin Vembar discussed the advancements at GSA in using Agile development on their large IAE program.
The response to this topic was so strong that we had to turn some people away. So ACT-IAC will be doing two more of these sessions, one on December 10th and another on January 21st. We are suggesting that the December and January sessions both limit industry attendance to no more than 50% of the total in order to allow for more government participation. I expect to moderate the January panel and hope to see you there.
As most of you who operate in the Federal space are probably aware at this point, many Federal agencies are now utilizing Agile methods such as Scrum to manage their software development efforts. The goal for most of them is to reduce risk and accelerate system delivery to their end users. By using Scrum with the development team they have achieved part of their goal. But major risks and speedbumps still exist after the software is developed. These are encountered during deployment by the operations groups and are normally outside the purview of the development team.
The de facto approach to this issue in the private sector is Continuous Delivery and DevOps. That same approach is now being successfully applied to the public sector. Just how well is the government doing in its attempts to adopt this private sector best practice? On November 18th Dr. David Patton, Federal Practice Director, and Ashok Komaragiri, Senior Technical Consultant, both with CC Pace, will be joined by Joshua Seckel and Jaya Kathuria from the Department of Homeland Security, Tina M. Donbeck from the U.S. Patent & Trademark Office and John D. Murphy, with the National Geospatial-Intelligence Agency, to take an in-depth look at the state of DevOps in the Federal government.
For additional information visit: http://www.potomacforum.org/content/agile-development-government-training-workshop-vi-devops-%E2%80%93-taking-agility-government-new
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.
On February 25th and 26th, I had the pleasure of attending the “Agile in Government” conference put together by AFEI (The Association For Enterprise Information). The theme of this year’s conference was Mutual Adaption – Adapting Agile to acquisition and acquisition to Agile.
While attending the conference, I had the privilege of listening to some great speakers on various topics, including contracting Agile in the government, DevOps use in the government, how cloud computing is the next ‘big’ thing for government agencies, and how EVM plays a role in government projects.
Roger Baker kicked off the event with the keynote talk on day 1 discussing how to ensure the success of Agile projects. He had 2 very powerful points: base the solution on solving the mission and not the technology and what he called ‘Success Makers’ for Agile projects. Mr. Baker pointed out that he is very adamant about keeping program lengths 6 months or less to root the program in deadlines, which helps to keep things moving. He also discussed that the acceptable rate of success should be more like 80%, instead of the current 16%. Mr. Baker’s success factors are to ensure prioritization, impose deadlines, force decision making, and involving users in everything; it “takes a village to move things forward” he notes. My favorite quotable sentence from Mr. Baker was “Agile is not the answer to everything, but waterfall is the answer to nothing.”
There were a number of speakers that touched on how to use contracts in the government for acquisitions; after all, that was the theme of this year’s conference. Each of the speakers discussed how there are numerous types of contracts that lend themselves to Agile very well. One that is becoming more and more popular is that of indefinite delivery, indefinite quantity (IDIQ) which allows for changes through task orders. These speakers concentrated heavily on the FAR[1] which has been shown support Agile acquisitions.
Another topic that was a headliner was that of EVMS, or earned value management system. EVM is a management tool and not something that is a day-to-day monitoring tool. EVM helps to track time and budget at a program level. The one thing that makes the EVM stand out is that it is really about value; as a couple speakers pointed out, you really have as much time as you need but it is about the amount of value that you need to deliver in a set timeframe. The easiest way to ensure that the value is kept in check, relevant to the time and budget, is to prioritize. Prioritization is a point that was continually hammered by each speaker, including those that spoke of EVM.
David Linthicum, keynote speaker on day 2, spoke about how cloud computing is the future for the government. He pointed out how it not only helps to speed things up but also how it is something that really cannot be ignored if government agencies wish to have systems to be more reliable and scalable. As with a number of other speakers, Mr. Linthicum pointed out that just switching architecture is not the answer to becoming faster, more reliable, and more scalable; there also need to be things such as continuous integration, automated testing, and the ability to spin up environments at the drop of a hat. All of these concepts lend themselves to points made that it is paramount to adhering to developing on cadence, releasing on demand. Mr. Linthicum laid out a number of variables that need to be accounted for when moving to cloud computing and noted numerous times that a change of that magnitude takes time. He hypothesized that if government agencies began planning to move to cloud computing now, and moved forward, they would be there by 2019-2020. Another point that Mr. Linthicum drove home is that, contrary to what some think, it is not possible to ‘balance out’ the cost with the savings; there will be a cost to moving, but then savings in things like operations and reliability will be seen long term—not immediately.
Another speaker that was of interest was Mr. Victor Page. He was from the DSDM Consortium and spoke about how DSDM is an Agile method that is becoming more widely used than it has in the past. Mr. Page talked about how many believe that, by its name Dynamic Systems Development Method, that it is a method that tells you what to do and how to do it; however, he followed this statement by saying that it is more a framework than a method. DSDM, as a framework, is more about showing what to do but leaving leeway in how to implement the framework. Many, according to Mr. Page, are starting to ‘rename’ DSDM to “Driving Strategy; Delivering More”.
I was honored to speak to the group on day 1 about how teams are more than resources and they should be treated as such in a talk titled “Teams Are People Too”. In the 30-minute slot, I outlined how most teams are treated in traditional projects and how that treatment should be shifted when looking at teams in Agile. I tried to point out how teams should be treated inside an agency, as a vendor-based team, and as a team that is split between an agency and a vendor.
In probably the most enjoyable session of the conference, I had an opportunity to participate in playing a round of the Agile Contracting Strategy Board Game developed by FWD Think. This game is laid out similar to a cross between Monopoly, Trivial Pursuit, and Trouble. Each of 4 teams, of 3 people each, roll a monster set of dice and move their ‘car’ around the board. With each square the ‘car’ lands on, there are questions or challenges that the team must complete. When a right answer is given or a challenge is completed, the team is awarded money. Whichever team has the most money at the end of the game (in our case, the timeframe allowed to play), wins. I found this game to be very helpful in understanding some of the nuances of Agile and acquisitions. As an aside, my team of 3 won at our table!
As you can see from this short synopsis, there was a lot to take in and a lot to be learned in 2 days. In all, there were approximately 120 people in attendance. All-in-all, it was a very full 2 days!
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.