As a coach, I frequently meet with managers of software development teams to talk about Agile. They get excited when I talk about Agile and Scrum and how they might improve their software development processes and team productivity. When I describe the rigor and discipline of Scrum teams and the mindset change required to support empowered and self-organizing teams, they tend to bristle. Letting go of control sounds too radical to them. "We want evolutionary change" they say, "not revolutionary".
During training courses, I often think it would be helpful to have all of Scrum and Agile summarized on one page. It’s actually not so easy! Even though the Agile Manifesto is just 4 values and 12 principles, and the Scrum Guide is 17 pages, it is still hard to summarize all that on one slide. We’ve tried anyway, and I am interested in your opinion on our efforts.
I meet with a lot of organizations who want to be Agile. When I ask why, most will respond with mechanical and tactical reasons:
- Improve On Time Delivery
- Align Business and Technology
- Flexibility to Respond to Change
Are these the right things to measure? If you achieve this, will you create a competitive advantage, or even parity? Do these represent business agility?
Looking for resources to help you succeed with Agile or make the transition to Scrum? You’ve come to the right place. Bookmark this guide and leverage it for all questions you have related to Agile Pilots, Training, and Transformation.
Whether you are just beginning to learn about Agile and Scrum and need guidance on best strategies for an Agile pilot, or a seasoned Agile Leader who is looking to create high-performing teams, we have tips, plans and strategies to help you avoid pitfalls and ultimately succeed with Agile and Scrum.
Earlier this month I had the opportunity to teach 3 agile training sessions in a row, 2 for clients and one at Northwestern University. In those classes, I learned a few things from the attendees. These were challenges that the participants saw to implementing Agile in their organization. They were often stated as objections or ways in which they did not think Agile would work for them.
Have you ever wondered how to undermine change and thwart progress in organizations? One of my agile coaching colleagues recently shared a link to the Simple Sabotage Field Manual, a document published during WWII by the Strategic Services, the precursor to the CIA. It makes for entertaining reading, in particular, section (11) General Interference with Organizations and Production.
I have a colleague who is an Agile Coach and he frequently helps me to see my own biases about agile. He gently points out that something I said was actually about Scrum, and not about Agile. You see my colleague comes from an XP background. When I talk about sprints or backlog refinement or other Scrum-specific concepts, he finds it jarring.
It's interesting to me that the main people who talk about using hybrid approaches to Agile are traditionally trained project managers. They believe there is a special blend of waterfall and agile techniques that will yield better results than either approach alone. They want to take the best of both worlds. I think they are misguided.
Last month I wrote about a couple of blog posts on LinkedIn about the death of Agile. Though the author admitted he was speaking tongue in cheek (and clearly hyping the topic by using an image of a nuclear explosion), he raised some good points about why some people wish Agile were dead. In this post I look at the areas where I agree with the author, as well as where I think he is wrong.