With the Govis Agile forum today in Wellington NZ, I found this post on TwinTechs to be an interesting yet disturbing read. The suggestion:
Most Agile developers or PMs present the methodology using accepted terms, all of which are unfamiliar to Stakeholders unless they have worked previously on Agile projects. What it really comes down to though, is that an Agile methodology aligns with Government projects quite nicely, and many of the principles are already applied at Agencies, just under different nomenclature.
via Does an Agile Methodology work in a Government Environment? | TwinTechs.
So Agile would work well in Government if practitioners didn’t come across as such freaky post-hippies? Maybe. There’s a nice little translation table included which seems serious until you hit:
Product Backlog, Release Backlog: Phase 2
Yes, I kind of get why you’d say that – but Phase 2? This is one of the reasons why an adapted waterfall vocab disturbs me. One of the bigger battles with Agile is getting the customer to understand and take advantage of the “variable scope, fixed time and cost” opportunity that Agile methods present. To me, “Phase 2″ in place of a backlog is definitely on a non-Agile planet – it implies that any “Phase 2″ features are definitely out of the current phase, and definitely in the next phase. The product backlog is an important concept and reflects the product owner’s prioritised features/stories that haven’t been committed to in the current sprint.
What may be more worrying here is the implication that a shift to Agile in government (in this case Federal govt in the US) may not be achievable. Some smoke and mirrors and the comfort of waterfall terminology may just allow you to deliver using Agile methods, as long as no one looks too closely. I don’t accept that this is the case everywhere and people I’ve worked with in the state sector in New Zealand have shown more adaptability than this.
Overall I wonder whether the approach would of hiding Agile under waterfall just get you into trouble later on (“I asked for gold taps…”). Bringing people along for the journey, even if one at a time, and shifting mindsets is a better path to travel in my view.
Glad you got to read my post! This post comes from experience of a painful situation I’ve encountered a few times. I’ve been shut down at the door of some Agencies when selling an agile approach. Remember that this is when speaking to the original audience, not the boots on the ground managers and developers. That being said, there are also some US agencies that welcome an Agile approach readily.
The fact of the matter is that every organization can benefit from Agile. Government, at least in the US, is a slow moving machine. Some employees do not readily welcome change for a multitude of reasons. Even employees who want to adapt to Agile and can see the benefits know that it is difficult to enact change from within at any great speed. Hitting key selling points of Agile while introducing or bidding a project such as:
1. Exposing Team Velocity and Strengths/Weaknesses
2. Allowing Constant Reprioritization and Goals
3. Frontloading Most Important Features
4. Constant and Improved Communication
5. Frequent Stakeholder Review
6. Rapid Delivery
without getting hung up on terminology is key. Sell the solution and even the actual process during the initial phases. Don’t confuse decision makers with unfamiliar terminologies though, they need to hear about the process in clear and succinct terms. Semantics is a fun and important part of the process but so is having the opportunity to enact a force multiplier. When you are on the team level and are past the bidding process, you can call the decision maker a Chicken all you want
In my experience, government agencies tend to insist on a classical, non-agile approaches on the macro, but give teams free hand to handle the week-to-week in an agile manner.
We had more success in first using such a hybrid approach, and when we gained credibility, ask for more agile contractual approach for the following engagements, or for maintenance work.
Apart from that, I agree with the comments of original article.
Thanks for your responses. Nic, I love your six key selling points for Agile and appreciate the idea behind not getting caught up on the language (I know I felt pretty put out the first time I was told that as a Chicken I had to zip it!).
For me the opportunity is to get decision makers to see Agile methods as a way to get more value and more delivery out of their projects, rather than as something software people do behind the scenes. Points 2-5 in Nic’s comment above are great ones to focus on for this.
Jake,
We see, in certain parts of the US Govt, a real willingness to embrace Agile. Even more so that commercial but in the big public focused agencies they are much more like you describe. On the Macro they want waterfall but on the Micro they are more flexible until you build trust.