Agile has increasingly become the standard way software development organizations deliver software. According to a recent TechBeachon survey, most organizations lean toward agile or purely rely on it for their software delivery. For a majority of government projects, waterfall methodologies continue to be heavily used with large amounts of process governance and controls.
While the government has begun to embrace agile in small pockets at some agencies, it has not come without its mistakes. The lack of agility can be attributed to many high-profile failures.
While agile alone would not have solved the problems that plagued those projects, it would have made the issues more transparent, detected sooner, and allow corrective actions to be taken much further in advance. If the federal government wishes to truly embrace agile, it should be weary of the pitfalls that have plagued the other projects.
-
Resistance to Change
Change is hard. Agile is a change in the way we not only do development but also business. Notionally thinking you’ll be agile overnight because an executive said so is just not realistic. My experience has taught me that resistance can manifest in many ways: passive aggressiveness, sabotage, refusal, and re-branding. While the first three are easy to identify, the latter continues to elude many federal agile sponsors.
Re-branding can manifest itself in both processes and people. Sprint and stand-ups do not an agile project make. Many teams use terms like “sprint” or “iteration” only to apply those words to their current waterfall methodology. Language such as “three requirements sprints”, “two testing sprints” or “three security hardening sprints” is usually the dead giveaway. It’s important to be cognizant of your existing roles and how the jobs of your employees are going to change. A Project Manager and a Product Owner are not the same thing. Despite training, there will always be those that refuse to change what they do, and it’s important to identify and remove those individuals from critical paths quickly. People can tell when rhetoric doesn’t match implementation.
Agile development demands that employees and managers break patterns of behavior and adopt new ones that have been proven successful for many years. People must know that the executive team has their backs, will to support them as challenges are encountered, and that support will last long after the first few months of a transformation.
Avoid falling into bad habits by using targeted support and agile coaching through all phases of the agile process.
Rely on teams with proven agile experience to help maintain and implement agile best practices.
Although agile transformation is typically driven from IT by the CIO, it’s crucial that it’s driven across the entire enterprise including areas like procurement or contracts.
-
Failure to Deliver Software Frequently
Most failing government projects often fail to deliver or fail to deliver value when they do deliver software. This problem is exacerbated when you have long durations between software delivery and release to production. How do you respond to a zero-day security vulnerability when you can only manage to deploy twice a year? Many agile transformations fail because of built up governance models, red-tape, and road blocks that under a waterfall model to help ensure everything is covered and reduce the risk of a large release’s failure.
Unfortunately, that reactionary habit is destructive to an agile transformation. Well-functioning agile teams develop small working pieces of code each story. By enabling software to be delivered to production more frequently we:
- reduce the risk of delivery,
- get more practice delivering,
- increase the efficiency of delivering (often reducing the overall maintenance window),
- encourage testing early and often, and
- allow us to respond more quickly to issues
Use infrastructure as code technologies to automate deployments from development to production.
Reduce/remove business roadblocks that prohibit fast deployments.
Deploy often and plan for successful rollbacks. Remember practice makes perfect. Start monthly, then bi-weekly, then weekly, then daily.
-
Silo-ing Work
It’s important for stakeholders to realize that agile development is most effective when flat and team-centric. Team members should be specialized generalists that own the application from requirement to implementation to production deployment. Perhaps the most prevalent pitfall is the tendency to separate and silo application development into separate teams by skills or responsibilities. In a practical sense, I often see this as a separated “Security Team”, “Testing Team”, “DevOps Team” or “Operations Team” which often leads to some responsibility not being owned by any team and few or no person with full application knowledge.
By separating these groups each team will have its own mission, its own distinct subset of application knowledge and its own delivery time table that can work against the project as a whole. It is fertile ground for disconnects in priorities, terminologies, approaches, as well as delivery slippages. This silo-ing of team skills also lends itself to an overall lack of ownership and responsibility in the project’s overall success, where the blame game is more important than fixing the problem(s).
Avoid creating specialized teams with one skill-set. Instead create robust teams of specialized generalists with varied skill sets.
Ensure the team has the responsibility and can perform all the functions it needs to design, develop test and deploy the application.
-
Lack of Product Owner Empowerment
When product owners are used to command and control management of many government agencies, it can be hard to feel empowered. As the name suggests, however, they need to own the product. If they can’t change the scope, make decisions without outside approval, or make changes to the team by adding team members, then they can’t make the decisions that need to be made.
All too often, in my experience, product owners are given defined parameters they must work in that limits not just product owners but the team’s ability to deliver results. This can slow a team’s ability to get critical decisions made to deliver on time, create requirements confusions between the business and developers, and effectively make the product owner just another hurdle to get to the real one.
Empowering a product owner requires a governance model that allows greater flexibility and a cultural change that focuses on trusting lower-level employees.
-
Putting Politics before Process
Often times, I have found typical project managers so averse to risk that they refuse to make any decision that can be traced back to them and simultaneously impart impossible standards on those they manage. Many folks just want to be told what to do, how to do it and when to do it. They don’t want to solve problems, take risks or be held accountable.
Faced with the “Blame Game” type of resistance, it is very tempting to concede. However, creating a culture where it is safe to try new things and safe to fail, you can help people find the most effective and efficient way to be successful in your organization. Don’t fall into the trap of thinking there is only one true way to do things that will make everything successful, because it just doesn’t exist. Failure is okay, as long as you learn and adjust so that you don’t make the same mistake twice.
An experienced agile coach can become very handy at identifying the root cause and recommend mitigation techniques.
Ensuring that your team consistently reflects on how to improve in retrospectives and actually takes actions to tune and adjust is key.
