Faux-agile
A few months back Martin Folwer put out a transcript of his 2018 keynote at Agile Australia. As usual, there were many snippets that jumped out at me, and many that hit close to home. Many of the "agile transformation" environments I've worked in over the past decade experienced dysfunction, stemming from a over prescription of process and lack of technical expertise.
Martin Fowler speaks to these complications, and aptly provides a nice little "Faux-Agile" label that I'll be sure to use from now on.
"Our first problem is dealing with the Agile Industrial Complex"
I've lost count of the amount of times someone would exclaim out loud, exasperated, something to the effect of "Agile just isn't for me", "Agile just won't work for our team", or "why are we adopting a new process? Can't we just get our work done?"
I'm an agile enthusiast. I advocate adopting Scrum or Kanban, specifically for new teams in the "forming" stage, or existing teams with poor execution. But I also advocate for peeling away processes if they are no longer necessary, if the team has grown beyond them.
"The Agile Industrial Complex imposing methods on people is an absolute travesty"
Engineers are smart people. Designers are smart people. Give your product teams the tools to be able to do their best work.
"A team should not only choose its process, but continue to evolve it"
If engineers aren't active in Standup, it's because they're active outside of it. They have their own channel of coordinating, and they are protecting them from outside hijacking. There is no one-best-way solution for a high-functioning team. It depends on the particular individuals and interactions.
"The second problem is the lack of recognition of the importance of technical excellence."
Vindicating to hear something so obvious: that technical excellence is a required precondition to high-execution agile teams. The belief that hiring a group of people with a variety of limited experience, placing them on a project with a scrummaster, and expecting that they will be able to estimate, execute, and reflect with any degree of precision -- even months later -- is simple naivity.
Engineering is hard and technical. Product ownership is hard and technical. UX is hard and technical. Expertise is crucial!
Yet in agile transformation projects, while there maybe be representatives of the business, who is responsible for assessing the technical expertise required for agile teams to thrive? If the head of engineering is not focused on ensuring the right people are in the right roles, who is?
"Oh, we need to create a whole new world for ourselves. The software craftsmanship movement where we can go away, get away from all of these business experts and project managers and business analysts, and just talk about our technical stuff."
Agile was created by technical people wanting to be more productive in risky situations. So why are technical people effectively pushed out from agile discussion in 2018?
Project managers and product owners who do not share the correct understanding of refactoring should have no place on an agile team. Refactoring, as a housekeeping behaviour, is crucial for high-functioning teams.
"Refactoring is lots of small changes, none of which change the observable part of the software"
But even when refactoring is well-understood, what seems to be even less understood is that refactoring is hard. Effective teams require experienced software engineers writing code, reviewing code, and caring for the code. Software development isn't just a day job -- It's a vocation!
Lastly, Fowler speaks to the imperative to organize around products, and not projects. This is perhaps quite obvious to anyone at a typical startup, but still quite a unique concept to many traditional enterprise organizations.
Hire good people. Give them clear markers and direction. Provide them with tools, books, and support. Let them figure it out.