Learning to Dance the Agile

We are currently working with a variety of large organizations who are all keen to “go Agile”. Most have a sense of humour about the parallels of implementing Agile to teaching an elephant to dance, but not everyone fully appreciates that, particularly for elephants, dancing involves learning new steps you’ve never attempted before.

The best way to learn how to dance is to, well, dance. There are many challenges to embrace and overcome on the road to becoming an Agile organization but the best advice I can offer is to actually do it. Many organizations get lost in the Agile academics and forget that actually delivering is the foundation upon which you can support your organizational Agile adoption.

For the purposes of this article, I will assume you have embraced a model of full-time empowered product ownership that works hand-in-hand with technology. Below I will present a common obstacle and two pitfalls – each of which can be addressed by engaging an Agile partner in the right way.

Funding – Product vs. Project

The shift towards building everything as a product is well underway on the business strategy, marketing, and even technology delivery fronts but one lingering impediment is securing financing for a product build vs. traditional project funding. This is followed quickly by the challenge of keeping the funding going. It is quite the paradox that the most conservative financial services companies find more comfort in funding a $50MM multi-year project, based solely on a thousand-page Business Requirements Document (the dreaded “BRD”), than they do in funding a product delivery team for a $250K monthly burn. And this is especially so with all of the evidence pointing to the fact that the $50MM project will likely not be able to deliver on the BRD (which is usually incomplete or incorrect in the first place).

To succeed in winning over the finance folks, you need to have an Agile partner that can demonstrate real value early on for the business. You must also be willing to sign shorter-term, flexible contracts based on time and materials alone, especially as trust is gained and a track record established.

Examples of flexibility include shortened termination notices, knowledge transfer co-teaming and ramp-down plans, location flexibility, and the ability to burst capacity as required. You also need to empower your partner with delivery ownership, allowing them to be effective in their help. Much like Agile itself, you need to take a leap of faith and prove that it works. Once your finance department experiences some wins, they will be more inclined to adopt a product team funding model vs. a project budget model.

Co-teaming vs. traditional coaching

A common pitfall we see is clients getting caught up in learning/training/adoption/transformation activities while losing site of delivery. Many financial services companies are embracing the Scrum Master and Agile Coach approach but, while it can be successful, I have seen this fail more often than not, fueling the anti-Agile fires and ultimately setting the Agile journey back.

You need to both deliver AND train up your own people, and to accomplish this, you’ll need help from firms that can execute equally on both. Look for a delivery partner with a track record of (a) delivery (of course), and (b) insisting that your people become active and dedicated members of the team (the co-team model). We’ve found that hands-on participation has a much more positive impact than a traditional role-based ‘coach’.

All the roles in a team should include a coaching component. Tech leads and developers coach while doing delivery tasks such as estimating, TDD, refactoring, pairing as appropriate, and automation. Business analysts provide hands-on training to product owners, BSAs, and BAs on things such as story writing, effective sprint planning, and backlog management. QA Engineers provide coaching with automation, contextual testing, and helping to create testable Stories. Delivery Managers provide in‑depth training for activities such as Scrum, staffing, planning, reporting, product management, and effectively interfacing with the organization. A partner that has a history and a mindset of coaching while delivering is your best bet to achieve viable and sustainable knowledge transfer to your people.

Scrum vs. Delivery

Don’t panic! I’m not going to put the Scrum Master role on a spit and cook it J. It is, however, a very important topic. One issue we have seen time and time again with our clients is the belief that having a Scrum master is the ‘key’ to adopting Agile. However, although Scrum masters are important and can be part of your Agile future, you must understand their intended role and the gaps that need to be filled in order to deliver successfully.

Approaching an engagement from a delivery ownership perspective can dramatically improve your chances for success. If your partner insists on providing experienced Agile leadership as part of their engagement with you, consider this a good sign. The last thing you want is inexperienced leadership tasked with both Delivery and training others on how to become Agile. You need your Agile delivery projects to work the first time. You should use a partner that wants to work with you on Delivery ownership and insists on critical mass, not one that simply wants to provide warm bodies. Scrum can be and is a part of it but, by definition, it does not encompass or support all elements of Delivery.

Delivering using Agile is arguably different every step of the way. Architecture needs to be designed in an evolutionary way. Development needs to commit to automation for testing and build/deploy. Requirements need to be written and fed to the team to support continuous delivery. Quality assurance must be closer to product ownership than ‘click and look’ testing. Team leads must interface with product owners, advising developers, reviewing code, and spiking new patterns. Project management will have more frequent deadlines/milestones and needs to focus on delivery and delivery impediments vs. staffing and reporting on percentage complete. You are building something real, for somebody real, in real time.

Conclusion

If you are evaluating an Agile software delivery partner and they have no track record of successful delivery using Agile, run away. If your potential Agile partner is happy if you provide a Scrum Master and they provide only a few supporting, often non-technical, roles, run away. If they are not bringing people to the table who understand hands-on mentoring and coaching while delivering is a key part of their jobs, again, run away.

Learning to dance requires a skilled partner. Choose carefully, as a bad partner can lead to a bruised toe!