Image by Photo by Perry Grone on Unsplash
I was once faced with a dilemma: how to bring a critically important and existing software engineering team from waterfall development to Agile without breaking delivery. These teams were staffed by third parties including tier one outsourcing organisations from India and the USA and having worked on the customer’s account offshore from India they were now onshore in Australia in company offices and expected to use Agile development. With scant team knowledge of Agile and specifically the Scaled Agile Framework I needed to create a navigable journey.
I started by carefully listening and watching the team at work in their stand ups and interactions with each other and our many stakeholders both from the business and technology. Then I started working on the fundamentals. I printing and laminated copies of the Agile Manifesto (values) and the Agile principles and attached them to every workstation cubicle wall. I used anecdotal stories such as the infamous “squirrel burger” and focused on transforming the team from their lifelong experience with command and control management from being told exactly what to do (and sometimes exactly how to do it) to know that I valued their skill and experience. Knowing that the team is better placed to work out how to build software rather than their “boss” and making sure that they not only heard me say that but that they learned to believe it too.
Building a high performing team takes courage, team and management courage. The team needs to want to do it, the “what’s in it for me” scenario and management needs to ensure that their customers, the actual people who will use the software get what they need. Change is also threatening. A complete change to how you perform work and how that affects a large team is extremely threatening. So, what’s in it for me? We no longer have titles. You’re not a developer or a tester or a business analyst: you’re all developers. Sure, we have specific skill sets where you’ve focused your knowledge and learning and you may be a better coder than tester but you will become a full stack developer able to run the entire gamut from initial discussions with our Product Owners through to releasing into production working valuable software. This will enhance your career far more than staying in a silo.
Fully documenting how I helped the team navigate their Agile journey would take up a book alone. Here at the start I focused on “self-interest”: I needed to show that not just adopting Agile but also embracing it would be of value to the team. To this day though my previous team mates can now quote Agile principle number six that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. We still stay in contact with each other and I’ve been an employment reference for many of them.
A key tenant of success was in building trust, enabling transparency, having their back, supporting them, helping them to grow professionally and personally. Knowing that the Agile approach to software development is more successful than waterfall, but that you need to embrace it, slowly, gradually but with conviction, rigor and commitment.