Agile 2015: Key Takeaways

Last week, we attended Agile 2015, an annual conference organized by the Agile Alliance “dedicated to furthering Agile principles and providing a venue for people and ideas to flourish.” In 2013 and 2014, we had the pleasure of speaking at the annual conference and sharing our ideas about Agile in the Federal IT space. This year, we were fortunate to attend the conference for a third time and participate in the conference’s first ever track aimed specifically at promoting ideas and sharing experiences related to Agile in the government. Building on our excitement from last week, we wanted to share some of our main takeaways from the conference regarding Agile in the government.

Takeaway #1: The Digital Services Playbook and TechFAR have changed the conversation on Agile’s viability in the Federal IT space.

We’ve been excitedly championing the adoption of Agile in the Federal space, and the White House’s publication of these documents proves that Agile methodologies are finally gaining traction within the highest ranks of the Federal government. The 13 plays of the Digital Services Playbook clearly point to Agile as the government’s vision for the future of Federal IT and the TechFAR provides technologists in the Federal space with guidance for implementing agile principles while adhering to current rules and regulations. Together, these documents provide a Federally-approved framework for implementing Agile methodologies and remove some of the ambiguity around what you can and cannot do when implementing Agile in the Federal space. If you haven’t checked them out, make sure to do so now!

Takeaway #2: The government’s current Waterfall-based approach to IT procurement/contracts must undergo some significant changes for Agile to succeed in the Federal space.

While the Digital Services Playbook and TechFAR are a step in the right direction, they alone are not enough to eliminate the deeply entrenched Waterfall thinking that currently hinders Agile’s success in parts of the Federal IT space. Currently, contracts for Agile projects tend to be Fixed Price, which means that they guarantee a set amount of money based on a set amount of work that is to be completed in a set amount of time. Additionally, these contracts typically establish fixed requirements up front, which then become locked in for the life of the contract. While this type of contract may make sense for Waterfall projects, it undermines the very foundation of Agile principles by removing the flexibility that Agile teams need to respond to changing customer requirements and stifles innovation and creativity.

But there is good news! The TechFAR does provide some recommendations for overcoming these challenges. Specifically, it provides guidance to Contract Officers (COs) to consider all contract types when drafting contracts for Agile projects, and it encourages COs to challenge the notion that Fixed Price contracts always provide the government with the least amount of risk exposure. In fact, the TechFAR explicitly states that COs should “select the pricing structure that will result in reasonable contractor risk and provide the contractor with the greatest incentive for efficient and economical performance.” Additionally, the TechFAR suggests that Agile teams should work with their COs to write contracts that communicate a Product Vision and process for achieving that vision, rather than delineating specific requirements. This approach allows Agile teams the flexibility to build software that actually meets their clients’ needs while also setting some boundaries around the scope of the work that is to be completed.

Takeaway #3: The education and empowerment of Product Owners is a critical next step for Agile’s growth in the Federal IT space.

Multiple sessions at Agile 2015 were focused on the concept of a Government Product Owner (PO). Again and again, attendees discussed the issues they face when trying to find a resource who can effectively serve as the PO. In Scrum, one of the most popular forms of Agile, the PO is considered one of three essential roles that are required for the methodology to succeed. However, the role of PO does not easily translate into one of the traditional roles associated with Waterfall. Oftentimes, the Contracting Officer’s Representative (COR) or a Government Program Manager is assigned the responsibilities of the Product Owner; however, there are many challenges to this approach. In fact, multiple 90 minute sessions at the conference were focused specifically on this issue. But in the interest of time, I will risk oversimplifying the challenges and summarize the overall issue, which is that it is very difficult to find a Government team member with the availability, authority, knowledge, and interest to excel in the PO role within the current government structure.

However, without a strong Government PO, it will be very difficult, if not impossible, for Agile teams in the Federal space to succeed. The PO is charge of guiding the vision of the project, making critical decisions, attending agile ceremonies, and providing answers to questions. So you may be asking, with all of these challenges, how can Agile teams possibly establish a strong Government PO on their teams? For many Agile teams, they will need an Agile Champion on the government side to support and empower the PO as they guide the vision of the overall project and perform their other critical duties. With the help of an Agile Champion, Agile teams can make it a top priority to educate and provide comfort to government clients on the role of the PO and the differences between the responsibilities associated with this role and traditional Waterfall roles, such as the COR and Program Manager. Once this common understanding is established, Agile teams can work together with their client to identify good candidates for the Government PO role and train the selected PO on Agile concepts and principles.

Although individual agencies (and even within offices inside an agency) are at very different stages of Agile adoption, it is an exciting time for those of us interested in the overall growth of Agile methodologies in the Federal space. The publication of the Digital Services Playbook and TechFAR signals a new era of Agile in the government. Despite the challenges that continue to exist, Agile teams have never been more primed to expand Agile’s influence in the government. Here at Dovel, we look forward to continuing to play our part in Agile’s advancement in the Federal space, looking for new opportunities to bring Federal IT to the next level of technological efficiency.