- We can’t do that because it’s not Agile
- Our Agile maturity is way behind
- This is just waterfall development with stand ups
I hear these types of things frequently from former and current colleagues and linkedin posts. Upon investigating I typically find the person making these kinds of statements is limiting their perspective; they are only thinking about themselves or maybe about their team over a short frame of time.
Sometimes it seems like any constraint is evidence of a lack of Agile-ness. Unless 100% of your backlog is organically created by the PO based on user feedback then you’re not Agile. If we are working towards a date we are not Agile. Having to create architecture docs is not Agile.
Successful agility (and life, for that matter) balances trade offs to navigate constraints according to a set of principles and values that change over time. Leadership is often about recognizing and articulating those principles and values. Creativity and psychological safety is needed to construe options for how to move forward. Diversity on a team is needed to sluice out how those paths affect the trade offs. The presence of constraints is not evidence of a lack of agile maturity, but your inability to make peace with them may point to a lack of some of these attributes.
Zoom out and make sure you understand how your team’s work is contributing to the bigger strategy. Often times this can give you insight into what is driving those principles and values, and the constraints you’re facing. That date you hate managing to might be because of necessary coordination with marketing in order to beat a competitor to the punch. Your company’s ability to do things like that is giving it agility in the market and therefore a potential survival advantage.
I’ve watched our amazing teams build the most in-depth integration on the market with a new (to us) wealth planning tool. In 11 months they went from the first line of code to production users. That’s incredible. It required massive coordination, dealing with late discoveries in legacy systems, new training programs, coordinating travel for hundreds of our users…
At the same time our teams also built a Salesforce based replacement for our 25 year old home grown CRM system. That system ran on mainframe, weblogic, springboot, DB2, and Mongo. Dozens of tightly integrated components, hundreds of cobol programs constantly updating data based on rules written ten or more years ago. In order to get some value to our users without having to replace the entire thing at once we had to create a bi-directional realtime sync system that keeps hundreds of critical bits of data matching between DB2 and Salesforce. This allows us to test and learn with real users years faster than we would have otherwise. Whatever level of complexity you are imagining for all that, 4x it. But in 18 months we went from first line of code to first production user.
Folks, if that ain’t agile then I honestly don’t know what is. And those aren’t even the only two things our firm is accomplishing right now. It’s a thing of beauty to watch our teams manage through the tangled web of constraints and find paths that take us forward. And that’s enabling our firm to achieve a level of agility in the market that is helping us serve our clients better and compete effectively.
For an individual PO or developer on one of those teams it probably doesn’t look like the kind of “Agile” they read about online. Most of the work they are doing is related to enterprise epics. That’s a trade off our firm is making in order to move these massive initiatives forward so quickly. At some point we will shift our values again to create more team autonomy. They will build their backlogs based mostly on user feedback and evolve their parts of these systems to be more joyful to the users. I’ll be trusting the leaders on these teams to make sure that’s shift is well understood, and I’m highly confident our diverse teams will be light on their feet to accept that shift and take advantage of it with creative ideas around how to deliver the best value they can.
In other words, we’ll keep being agile.