I am a believer in the original declaration of the agile manifesto. Go re-read it; I’ll wait.
I am an extreme skeptic when it comes to most people and companies who say they are Agile. In particular, I am skeptical of any system for doing agile software development that comes with rules and best practices.
I’ll call out by name DSDM because I coached at a company that had tried to adopt DSDM Atern. By the time I got there, senior management was desperate for help, but insisted that I not call what I was doing ‘agile’ and not use typical agile terminology. Faced with recalcitrant teams, difficulties in offshoring development and wanting to attract talented engineers, they had tried to impose an Agile Process and they were overwhelmed by rules and buzzwords and Processes. I’m willing to bet that SAFe is the same. These ‘systems’ are full of rules and procedures and terminology, and management assume that by following all of them, teams will magically write better software.
Note in that regard that the first declaration of the manifesto for agile software development is “We have come to value Individuals and interactions over processes and tools.” Every team is composed of individuals different from every other team of individuals. And that idea, of valuing individuals so highly is what resonates with me most strongly about a good agile process. Every team is unique, every sprint is a new opportunity for learning, and every interaction is a chance to build trust and relationships. Companies who put their trust in people are more rewarding than those who rely on process alone.
Most people I’ve talked with who consider themselves agile follow some flavor of scrum. And they happily talk about the ceremonies they use: the standup, the planning, the retrospective. But when I ask my favorite question “what did you learn at your last retrospective?” you would be amazed how many times those people say “we don’t really do retrospectives” or “I’m too busy to attend the retro.” FAIL.
In my opinion you are not agile if you are not regularly inspecting the process you use and adapting it to your own lived experience (see the last agile principle). Which brings up the other failure of retrospectives: teams who “look back” on their sprint and congratulate themselves for finishing their work—without examining HOW they got the work done. “We finished the code with only one defect” is not a proper answer to “What went well during the sprint.”
Mike Cohn says “best practices can be dangerous” and I wholeheartedly agree.
During the latter part of my tenure at Cars.com, I was part of the internal team which helped to implement agile practices. It was some of the most exciting work I did. I learned a great deal, and by the time we were done with our multi-month transition, we had a number of teams working well. Sadly, when many of us who led the transition left to do more agile coaching elsewhere, the transformation at Cars.com did not stick, I am told. Like a garden, a good development process needs dedicated tending lest the plants grow out of control.
So if you’re doing agile (have you noticed that I am selective about capitalizing the “a” in “agile?”), be prepared to tell me what you learned at your last retro. Tell me how your flavor of agile works for you and how you came to it.
Because I love the concept, the principle of agile for software development. I love working in an environment where we can all see progress in a short time, where we can examine that progress and keep it on track. And I love inspecting our way of working and the relationships we have as people and improving them. It takes a lot of risk to build the trust that is necessary, but it is worth it.