An Update on Agile

This is the seventh article in a series about Lessons Learned.

In a prior LinkedIn post I commented about not missing many of the rituals associated with Agile Software Development, such as planning and daily standup. While I believe these efforts have some value, my recent thoughts are that adherence to the orthodoxy has supplanted the purpose of Agile, which is to empower the people closest to the work to make the best decisions and hold each other accountable to their commitments.

I will often comment, when asked about Agile, that I believe it is a “religion”, not a science. By that I mean that there are many different ways of practicing it, and while every adherent believes their way is the right way, there is no scientific evidence demonstrating that one way is materially better than any other, otherwise all companies would run their process in that most efficient pattern. Instead, companies and organizations tend to run agile in whatever manner a few senior people on a team have run it in the past, just as children adopt the religion of their parents and culture, not through rigid examination of what might be best, but because that is the norm of their social unit.

It is, I believe unapologetically, bullshit to be in a mode of always shipping features, and scheduling out as much time as possible to only work on “back of box” functionality while ignoring all the other critical work that needs to happen to make products successful, performant, and usable. When we miss out on time to experiment, explore, and prototype, we lose out on valuable information that leads to a more holistic understanding of the problems we’re trying to solve, which causes our work estimates to be highly inaccurate. Research is not a thing that can be forced; the research is done when it’s done, and we may have to explore many paths before we find workable solutions, if they even exist at all. We also need time to document our findings (including the paths explored but not pursued, so that engineers new to the space do not waste time retreading fruitless paths), peer review our results, and disseminate our plans to external teams who may be involved in the overall solution.

Too often, and usually with Project and Product Manager who are new to the workforce, I have seen strong-headed individuals simply try to force work upon engineers and drive features to completion simply by force of will. Pushing back with clear data (“it’s just not possible to complete this in two weeks!”) was met with stubborn resistance (“You don’t have a choice, you have to get this done.”) from the authoritarian PM. This leads to animosity among the team, and turns engineering into an IT team; they merely exist to do the heavy lifting, the “product people” are the real thought leaders. I reject disempowering engineers, and have frequently encouraged my engineers to have a broader definition of “done” that includes a wide range of tests, functionality that is fully realized and not just workable in the best-case scenario, as well as code that is well documented, maintainable, and performant. Features that “simply work” just so that a naive PM can move a box over to a new column in Jira is not a recipe for success on a team, nor a successful product.

(I should call out that this is not a blanket condemnation of PMs, as I have worked well with excellent people who do think holistically.)

As I think about product planning, tracking, and execution, I have found myself leaning more towards a Kanban approach, with a less rigidly applied timeline for how work is segmented and advanced, a free backlog that can be completely examined and pulled from flexibly, and more ad-hoc check-ins on progress, planning, and adjustments to the schedule. I also encourage more pipelining from teams who feed design work or other deliverables that unblock further work, enabling people at all levels across teams to communicate more directly about what they need. As leaders, we shouldn’t be bottlenecks in communication, nor gatekeepers of the process or methodology. Instead, while we remain responsible for the ultimate quality and timeliness of deliverables, we should be enabling our teams to do their best work, to explore all the possible paths, and collaborate effectively in ways that maximizes their time in a state of flow, instead of prioritizing adherence to the Agile Rituals over doing great work.

Next up, an article about properly level setting your knowledge base.

Lessons Learned:

• Adjust your process to what works best for your team.
• Flow, psychological safety, and communication are more important than orthodoxy and ritual.
• Ensure your team has time to explore, prototype, plan, and validate their approaches
• Expand your meaning of done to include a wide range of test cases, broad usability, maintainability, and performance tuning.
• If your task tracker indicates that the project is on track, but you’re not actually using your product to validate that it’s functional, bias towards the state of the product, not the tool that lets you move boxes around.