I have been thinking about this topic for some time. A tweet from @MooneyDev asking for my thoughts on an article written by @jbandi prompted me to write this article.
Mr. Bandi’s article, Why I Don't Believe In Scaling Agile to the Enterprise, makes some very valid points.
I spent the first twenty years of my career as a developer and architect. In the past eight years, I became a delivery manager and project manager. I embraced the points in the Agile Manifesto. I also found the tenets of Extreme Programming, Scrum and Kanban compelling because of their simplicity and came to understand how they can be used to deliver software solutions.
Recently, a popular topic is “how to scale agile”. A number of solutions have been offered, SAFe being one of the more popular solutions. This solution and others have generated some criticism in the development community.
A point often made is that solutions like SAFe are “cashing in” on agile. I agree with this point to some degree. However, this is not new. The IT world is littered with good ideas that have been packaged and sold as solutions.
Another point often mentioned is that agile is mostly common sense and any group of very smart and highly motivated people will succeed using agile. There is no doubt that this is true as well.
We are asking the wrong question
When considering large teams we are facing the bell curve. We need to figure out how to deliver software solutions when hundreds of people are involved. Smart and motivated people would probably be successful with any process. We need to be successful with average folks.
The Waterfall Accident where he points out that Winston W. Royce, the father of the waterfall approach, never intended for it to be a once-and-done, single pass approach.
So, in order to scale people to successfully deliver software, we need to observe the available options around us and carefully select solutions knowing that there is no silver bullet.
SAFe has some attractive options as do other frameworks and approaches. Every firm and situation is different. How do we select the right option?
Open Agile AdoptionI have found the Open Agile Adoption approach offered by Dan Mezick attractive. This approach book-ends a set of iterations with open space meetings. In these meetings, any member of the team is free to post suggested break-out-sessions they feel are important. Attendees are free to attend any meeting they choose. If something is important, folks will attend.
Every member of the team is invited to attend including executives. This open and free communication enables the team to figure out what is best for them. Typically some flavor of an agile practice is used but the team sorts this out.
These meetings are facilitated by true Servant Leaders who help the team see the path.
I head Dan speak at a user group meeting and I am eager to try his approach on a future engagement. I believe the team knows best the
approach. Leadership is required to help them find the way.
In conclusionThere are firms who have large staffs who need to successfully deliver software. We need to figure out ways for these large firms to be successful. Many approaches have been tried over the decades and we are improving.
The internet has exploded over the years and, clearly, this demonstrates we are learning from our mistakes. I believe that the textbook waterfall methodology is no longer a consideration. Some flavor of agile is. We just need to figure out the details which has always been a challenge.