Has the agile industrial complex done so much damage that nearly every opportunity involves working within a set rigid framework unable to move beyond the dysfunction that comes with such an existence?
Scrum != agile, SAFe != agile, Autoscrum != agile, using a Kanban Board != agile. If your goal is to be good or even great at implementing a framework that is in someway related to agile, go for it. But please stop fooling yourself into thinking that this will solve all of your problems or help you better serve your customers. What implementing one of these canned frameworks will do, is make the people working within said framework immeasurably unhappy.
The copy/paste framework installment way of working into organizations is wrought with actively destructive practices.
- Estimation “best practices” such as story points or cosmic function points.
- Splitting “stories” into individual tasks/sub-tasks.
- Loading Sprints based on gamed velocity numbers acquired from story pointing.
- Assigning tasks/sub-tasks to specific individual job roles in our tracking systems.
- Retreating to our corners to work on our pieces & parts.
- Holding Daily Scrums/Standups (Status Reporting) meetings to hold one another “accountable” to completing our assigned tasks/sub-tasks.
- Backlog Refinement meetings to discuss what we are going to build next while not knowing if what we are currently building is going to work to solve the problem since we aren’t including our customers or users.
- Attempting to reassemble everything on the last day of the sprint so we don’t miss our release train and Sprint Review Demo where we show our “stakeholders”, still no sign of that customer or user, what we built.
- Submitting our release to the CAB (Change Approval Board) to get permission for the deployment team to deliver this feature none of our customers/users want or will use since we didn’t involve the customer/user at all in the creation of said feature.
- Attending a Sprint Retrospective where nobody has the time or energy to focus on the problems we are experiencing with our process, mostly due to the fact we are still getting the deployment packages ready for the deployment team, and way of working. Let alone having the capacity to think about what is good and how we can turn that up.
And these things listed above are assuming the org has at least decided to do most of the work within a single Sprint/Iteration. With the exception of the release process. Remember, there are places out there doing:
- Design Sprints
- Development Sprints
- QA Testing Sprints
- User Acceptance Testing Sprints
- Hardening Sprints
- Deployment Sprints
So far working in this agile world, in & out of these “agile frameworks” & then being a part of some teams and orgs that really do grasp the concept of agility. I feel confident in saying you do not need any framework or tracking tool to work with agility. You do not need to implement a specific process or set of tools. You certainly do not need to mandate meetings or enforce “best practices” across people, teams, divisions or organizations. A team is more than capable of figuring out what tools they need, defining the process to follow, determining how they work together, & including their customers/users. The only thing management needs to do is provide the flexibility for teams to experiment and learn.
I once watched Dave Thomas give a talk on agile and agility. Here is an excerpt from that talk.
“Agility – What to Do
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
- Repeat
Agility – How to Do It
- When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.”
For anyone reading this that is looking for that “one right way” of working with agility, it’s not coming. It doesn’t exist. No framework, process, policy, design approach, etc.., is “the way”.
If you want to do the things I have listed above that time and again prove to not work for those trying to work in an agile way, then by all means go for it. If that works for you, have at it.
But be warned. Other organizations, and yes even those in your domain, are investing in finding better ways of working for real. They are not just going through the motions of installing a canned copy/paste “Agile Framework”. What happens when they learn those better ways. To include their customers and users. To solve problems with better quality. To provide a better experience for the same customers in your domain. Can you afford to not be taking that same approach?
Big thank you to Kevin Meadows for laying out this scenario in our conversations.
Of course there are things we have found to be helpful that have become somewhat common that agile teams do and could be considered a shared practice, process or tool. But nothing stops truly agile teams from challenging a practice, process or tool. These “Agile Frameworks” simply do not allow those challenges. These “Agile Best Practices” that accompany these “Agile Frameworks” are beyond reproach.
Any mention of an experiment into no longer estimating by changing the way you work as to no longer need estimates is met with hostility and in a number of cases have cost people their jobs.
Any mention of an experiment to move away from the scatter-gather work style is blocked by “utilization/capacity planning” and “resource allocation” command and control style management.
The next logical step in this post might be to discuss the certification companies promoting these frameworks. I think we can sum that whole conversation up with one quote.
“Certified doesn’t mean qualified.” – A lot of people
Chris Pipito 