Most organizations today have tried Agile approaches and the majority are finding them helpful. There are a significant number of people for whom Agile has not been helpful or it hasn’t worked. Or, they tried it but they did not get the benefits that they had hoped they would get. When I peel back the onion, I hear some of the same reasons for Agile not working.
As we work with clients who are exploring how to get started with Agile and Scrum, we find ourselves asking many of the same questions. The questions help us to create a plan for success with Agile and avoid some of the problems that teams encounter when trying to adopt something new.
To address this need and help clients think broadly about the change, we developed a checklist of things to consider. The planning checklist is not intended to be comprehensive, but we believe that it includes the most common things to be considered when planning for Scrum Teams.
One of the most common conversations I’ve had with clients over the last few years is how to move from a traditional or waterfall style of development to using Agile and Scrum. Based on those discussions and years of experience leading and supporting these transformations for my clients, I’ve compiled this short guide on planning and executing an agile pilot or an agile transformation in your organization.
A common question I get during my Agile training courses is what is the difference between Agile Adoption and Agile Transformation. It's a great question. I see five key differences worth talking about.
But first let's agree on our terminology. These are my working definitions for these two terms though I realize that people don't use these two terms consistently.
Last year I wrote “Project Managers Don’t Get Agile” for the ProjectManagement.com website. As I continue to think about it, I see that part of the challenge comes from the mindset change that is required to understand agile. If you are a great project manager, chances are that your mental models limit your ability to understand and implement Agile.
One question that I get frequently from leaders during Agile training is about how to make sure everyone is busy. How do we make sure that we are getting the most out of every person? They have a seemingly perverse focus on individual efficiency rather than on team effectiveness and throughput. Rather than focusing on creating an environment for high performing teams, they try to make sure that everyone is busy all the time. This is another form of local optimization.
I have a client that has been using Agile and Scrum for the last 3 years. Let me restate that, this client has been using A.I.N.O. for the last 3 years. I am working with him to implement Scrum and eventually embrace a full Agile Transformation. With him and his team I have to refer to this as implementing a "more disciplined Scrum" because unfortunately, everyone believes they were already doing Scrum.
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?
Imagine that you have a favorite restaurant and that you go there all the time. The restaurant's specialty is the veal chop. You love the restaurant and the veal and you recommend it to everyone. You have a good friend who visits your restaurant based on your recommendation. But rather than getting the veal, she orders the spaghetti and meatballs. Her husband orders the vegan burger, which BTW is terrible. They wind up very dissatisfied with the restaurant.