Framework Fundamentals
Study the fundamentals; forget the fundamentalism
You’re forming a new engineering or development team. Which Agile framework will you use? Scrum? Kanban? Scrumban? Safe? SAD? Krum?
Does it matter?
Listening to The Mob Mentality Podcast recently, engineer Bryan Finster declared, “No frameworks. Get rid of frameworks. Just do the fundamentals.” (Not a direct quote; just what I heard.)
I don’t disagree with Bryan. I am no Scrum/Kanban/Framework fundamentalist. I’m an agile (little ‘a’) fundamentalist. I believe in the values and the principles of Agile, not the implementation details.
I do find, however, that frameworks have value. Teams have to start from where they are. The frameworks are like the ‘plans’ I wrote about earlier. They are useless, in an of themselves, but they give us a place from which to start learning, experimenting, and adapting.
I have been part of so many development teams and we had delivered, but it wasn’t without difficulty and pain. We worked in a very waterfall-like manner. Requirements and project plans were drawn up in Q4, handed-off to development in Q1. “Final” features added by Q3. Testing and review by customers, panic, rush jobs, long hours, de-motivation, burnout, people quitting in Q4. Patching and overlap in Q1… Rinse & repeat.
In my first real leadership role, I had no idea how to effectively organize a team of 7 developers. The team had a reputation of not getting things done. I wanted to lead better. I started reading about Agile and Scrum. As I did, I found what seemed to be a lot of solutions to the pain points we had been experienced in “the old way.” Quick feedback loops with customers. Delivering…something/anything…every two weeks. Sustainable pace. Etc.
Like any new-to-Scrum-scrum-master, I followed the Scrum guide thinking, naively, “This has all the answers and will solve all our problems.” Daily stand-ups. Sprint Planning. Story Pointing. Retrospective. Rinse & repeat.
Surprise. It did not have all the answers. It did not solve all our problems. It did, however, give a starting point. Sprint Planning did help us to break down work to fit into the Sprint, and helped the whole team understand the challenges and proposed solutions. Sprint demos did help us to deliver…something…on a reasonable cadence. Stand-ups did help us to collaborate and communicate blockers earlier and more frequently. Retrospectives did help us to review the way we worked together. Story Pointing did help us to communicate differences or misunderstandings in estimating or forecasting.
Yet, still there were issues. Story pointing wasn’t really good at estimating, but it started the conversations, so we kept it. Management still continued to change priorities - even though the Sprint was “set.” Etc., Etc. Etc.
As we worked together, however, we actually learned to be “agile” (little ‘a’) by adapting the Scrum Guide and our processes to try and fit the current challenges. It gave us a “plan” to inspect and adapt as we worked to find creative solutions to challenges.
Would Kanban have worked for us? Probably. Scrumban? Likely. As long as we built that “agile” (little ‘a’) muscle. As long as we held to the values and principles over the framework.
If you and your team are working in an effective way without a framework, keep at it. If you and your team are not being as effective as you believe you can be, and you are not using a framework to help guide you - pick one to get you started.