A Tale of Two Agiles

In 2019, I was working with 2 clients at the same time, both claiming to be Agile. Needless to say, it was a challenging, full-time year, but also one of surprises. Let's begin by comparing these two clients and their goals and approach.

My Client A is a small consulting business with 2 key clients originally looking for custom software integral to their front end business process. The owner of Client A identified a broader opportunity to build a product for the 2 key clients, intending to sell it to other clients also.

- my role was product manager

- the team consisted of 4 developers, a data architect, and a part time business analyst

- we initially started with a heated debate over what technology to use, ultimately leading to one of the senior developers departing

- collectively, we had a pretty good handle on what the client was trying to achieve business-wise, given some of the team have built very similar system.

Client B is a large government agency working with an international consulting firm. It has a CIO, an established IT department, a full portfolio of aging applications and a decent web presence used by thousands of members. Client B wants to re-develop its internally facing applications onto a more modern, flexible platform.

- my role initially was project director

- there were 3 teams, each with a product owner, tech lead, scrum master and PM, totalling over 60 staff

- an established third party business modelling tool from a large software vendor was selected as the core technology about 2 years previously

- individuals tend to have a good handle on their specific work, but the bigger picture is poorly defined and scope changes and creep are evident in 2 of the 3 teams.

For certain, both of these projects have red flags poking up. But in this article, I'll discuss the key reasons that made one of these projects into a star, and led to the other one being cancelled.

Number 1 was clarity. This doesn't necessarily meant we knew exactly what and how to build the solution. But we knew, with some level of precision, what the outcome should look like. One project had this, at least in my head, while the other suffered through failed prototypes that took a surprisingly long time to complete. On one project, most of the team members had not actually ever seen the current system in use.

Number 2, empowerment. In one project, if a decision needed to be made, 95% of the time, I could make it immediately and inform the stakeholders later. I likewise empowered my team to make those decisions also (and while on vacation in Italy for a couple of weeks, they took the application security design in a whole different direction, but they knew that was the right thing to do so they did it - and I said thank you when I got back). In the other project, almost all decisions needed approval before we could act on them, often by committee. And more importantly, team members were cautious to act, slowing progress to a crawl.

Number 3, technical leadership. Now, to be fair, both projects had skilled, smart people. Neither project team had all the answers at their fingertips. The larger project had a combined hundreds and probably thousands of years of experience. The smaller one was two grey hairs (including me) and the rest millennials. But on one project, the team would pull together to find the answer, and our technical leader (who is 25 years old) was passionate about development. The other project relied heavily on a software vendor resource to solve the hard problems, who was literally overwhelmed and distracted from the bigger picture.

By now, you are probably guessing that the small, nimble Client A was a success while the much larger, more equipped Client B shut it down - and you are correct. When I walked in the door, I saw the signs immediately, but I thought I could improve the track record of the past 2 years at Client B. And when it was clear that I couldn't, I quickly became the advocate for ending it. I was fortunate in having strong consulting colleagues that agreed and led the executive discussion. It took a lot of courage for Client B's executive to make "the decision". While culture and structure shoulder much of the load, the software vendor managed to escape this saga, perhaps without a reference, but fully paid. But that will remain the topic of a future post on building accountability and ownership in relationships with software vendors.

The other project? Well, it continues to shine, and it remains a very exciting part of my work life as we have now implemented our first modules and start design and build of new ones. You can find the fruits of our labour at www.pictus.ca.