I spend most of my time these days helping teams get started with Agile. It usually begins with a straightforward request: ?We are interested in Agile, and we want to get some training so we can get started?.?
These types of messages are most welcome. My role at CA Technologies is to help teams get started on their way to reaping the wonderful benefits of Agile. After an initial discussion with the requester, usually we agree to establish a baseline of knowledge about agile and then pick a good time to start. And so it goes.
Too often I see teams, at least those who have a choice in the matter, give up on Agile before or shortly after they get started. For me, it?s a point of reflection on how I can do a better job of helping managers establish the conditions for success with Agile. Nonetheless, I want to share a list of the common reasons I see for teams giving up, with a thought or two that may help these teams get back on track.
Why We Are Giving Up #1:
?There are too many rules, too much process, too much change in the role definitions, and other stuff. It?s all just TOO MUCH!?
Why you shouldn?t give up: Yes, it?s overwhelming! That?s why I recommend that people start with a simple concept ? how can your team improve how they work? Starting with the biggest problem or challenge facing your team, how can everyone mobilize around solving that biggest problem? And after you?ve started, when will you regroup to monitor progress? That?s about as simple as it gets, and it?s agile.
Why We Are Giving Up #2:
?We?ve made an earnest effort to start practicing Scrum over the past few months, and yet, we haven?t seen things get better. If anything, our team performance has declined.?
Why you shouldn?t give up: Yes, your team performance likely will decline at first. It?s because you are, if you?re doing it right, fundamentally changing the way your team approaches work.
Why We Are Giving Up #3:
?The Scrum events like daily stand-ups and retrospectives take up so much time. Like, we were all already overwhelmed before we started with this Agile stuff, and now the addition of these different required activities is just piling on more work for all of us.?
Why you shouldn?t give up: If you go by the book, the Scrum events should take up about 10% of everyone?s time. Subtract from that the other meetings that those events displace, such as debriefing after something goes wrong or periodic planning, the total meeting time may not increase at all. The reality is that the Scrum events each have a specific purpose. The spirit of Agile allows that the team could decide to NOT do some of the events. Our team, for example, decided that it?s ok to have only three stand-ups per week instead of every day (and we haven?t been struck by lightning yet). But, as you scale back these team activities, what are you giving up? If you scrap the Sprint review, are you saying that you don?t want to get feedback from your customers on your finished work? If you don?t do a retrospective, are you saying that your team is not committed to reflecting on how to get better? If you don?t do Sprint Planning, are you abandoning the idea that everyone needs transparency into what is important to work on and how each person will contribute?
Why We Are Giving Up #4:
?Agile doesn?t work for how we work. We?ve always worked in a swim lane model, where everyone has their own assigned area of responsibility. We just don?t see why we need to communicate so much when most of what?s said is not relevant to most of us.?
Why you shouldn?t give up: This problem raises questions about the assumptions that go into a swim lane model. One assumption is that steady ?coverage? ensures better service to the beneficiaries of each swim lane. Well, that seems to say that all areas of responsibility are of constant importance. To that, I say: Ridiculous! People need to learn to work across swim lanes in response to what?s important at the time. During some periods, any given swim lane will demand urgency and a lot of capacity. At other times, it will be quiet. By being more flexible, you can move people to swarm around what?s most important. Over time, the team will develop improved adaptability as everyone learns about everyone else?s work.
Why We Are Giving Up #5:
?We started with the 2-week iterations, and the people around us don?t work that way. We can?t respond to urgent requests by telling them to wait until the next Sprint. They don?t understand why we want to deliver small bits of work bi-weekly when they would rather wait 6 months and see all of the work done.?
Why you shouldn?t give up: I get it. If everyone was working in 2-week cycles, things would be simpler. The fact of the matter is, the commitment you made to work in short iterations was made for good reasons. Now, you are in a position where you need to advise your customers why you do so, and how they too will benefit. Over time it can work, but it quickly shifts you from being in a position of adhering to rules of the method and being an evangelist for them.
Why We Are Giving Up #6:
?The more I read up on Agile and study the ruminations of the ?experts,? the more I think these Agile people are living in La-La Land. Collaboration and teamwork are cool, but business is not a place for rainbows and unicorns.?
Why you shouldn?t give up: This reaction taps into one of the key reasons that people give up. Sure, many of the top Agile ?experts? spend a lot of time talking about the fluffy stuff, and some of them even sound like hippies. However, it?s a reminder of where Agile came from. The principles and values of the Agile Manifesto mostly talk about how people work together. People are very proficient at the technical skills of their job. After all, someone hired them on that basis. But teams and projects fail because of human factors and systemic issues in the environment. Agile asks you to examine those conditions and work together to fix the things that are holding the team back. Sure, that might involve talk of rainbows and unicorns, but you?ll see with experience that trust, collaboration, and humanity are the keys to the kingdom.
Most of these dilemmas point to a very simple idea. Is your team willing to truly commit to getting better? If so, expect some bumpy roads, some exposure of feelings, and some upended assumptions. Nobody said it would be easy.
The idea that a thought or two from me could get teams back on track is interesting. I can?t give a thought or two if I?m not there. That?s why, as part of getting started, I recommend that teams establish and tap into a structured support system as they ramp up their Agile practice. It could be a regular diet of discussion with an Agile consultant, a close relationship with an Agile Coach who is helping to monitor progress or even a mentor who has walked the path on which you now embark.
Are you struggling to maintain your momentum? Consider the ideas I?ve presented here, and let me know how you?ve overcome these challenges.
