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.
Two conversations in two days have concerned me in my role of agile coach. In the first, I had a product owner and his assistant expressing frustration at the current pace of development for 3 scrum teams. In the second conversation, an person assisting another product owner, similarly concerned, asked the scrum master for the team to begin to track who on the team was working. In both cases, the product owners for the teams lacked trust and wanted to push or motivate the team in some way.
I recently compiled a list of all the teams I had trained and coached since I began coaching in 2012. Turns out that I have helped over 90 teams from 19 companies so far. Wow! Even I had not realized the number was so high.
The teams I trained or coached vary in many ways - technology, industry, company size, and product just to name a few. The culture and diversity of the teams is also all over the board. Some teams were just OK, and some were truly high performing teams. And the team sizes vary quite a bit, from teams as small as four to teams as large as 13.
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.
Key Planning Considerations:
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.
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 recently had a participant tell me that my Agile and Scrum for Teams class was 1,000% better than he expected. Which I took as a great compliment, even though I noted the hyperbole. When pressed to explain why, he said that his previous Agile training had been horrible. Which got me wondering if I was that much better, or if the expectations were simply low.
As an Agile Trainer and Coach, I find an interesting paradox. Most people will state that they already know all about Agile. And if asked, most organizations will say that they are already using Agile, even if it is A.I.N.O. (Agile in Name Only). Or they will describe what they are doing as "agilish". I am pretty sure that "agilish" in this context means that they aren't following Agile Values and Principles.