This past Sunday saw the kickoff of the Scrum Bangalore User Group in Bangalore, India (more on that later). At the meeting, Scrum expert Pete Deemer gave us these 19 nuggets of wisdom from his many years as an Agile coach for organizations across the world.
- Do it for the right reasons: Like Harry Potter, when evil wizards use good magic for evil purposes, they get destroyed.
- Start with teams that want to try it: It’s counter-intiutive, but don’t force a pilot effort onto resistors. Have the teams pick themselves. Then, set their expectations: “Are you sure you want to try it? It’s really dangerous. You can try it, but only for 1 sprint”.
- Set realistic expectations for Scrum: Don’t go in saying, ”Scrum will save our disaster project”. Force a project restart & give the team 3-5 sprints of breathing room. That’s how long it takes to get to all cylinders/cruise control.
- Call it a pilot program for as long as possible: People assume a pilot is messy, and nor will a pilot threaten their long term career.
- Change is scary to many people: Humans aspire, in an unfriendly world, to protect ourselves with some stability and predictability. Introduce your changes gently: “Scrum may not be right for us, but we won’t know until we’v tried it. So let’s do it all-in, correctly, for 1 sprint. Did we see any benefit? If so, let’s do it one more sprint. It’s one way of working. It’s not the final way of working, but it might help us get a little bit better”
- Patience is a virtue: -Â Start with 1 team and grow gradually from there. You don’t want 20 teams all struggling with the same issue we’ve yet to figure out. Â Instead, it’s better to have one trailblazer fix that issue so others don’t have to.
- Find the Scrum middle path: In some ways, my job is a purist advocating the dramatic change, speaking hard truth, but then encouraging teams to tailor the practices to their situation. Be careful though; many organizations respond to the pain of change by diluting the change.
- Scrum is hard: it surfaces your nasty, accumulated junk. If you’re not prepared to deal with the issues that Scrum reveals, then it will be very hard to continue.
- Get experienced help: Consultants are not afraid of getting sacked, nor do they have a departmental agenda.
- Get high quality training: Often, adoption failures are associated with the initial training provided by someone who was told to read a book over the weekend. Better to send 1 person to really good training, than to send 20 people to bad training.
- Your enemy is your friend: Spend the most time with the people that like Scrum the least. Put your chief resistors on the Scrum steering committee. If they’re not engaged, they’ll miss how it works, and feel marginalized. Â Also, those resistors will help you understand the key roadblocks to successful adoption.
- Be prepared to use Guerilla tactics: Namely, if management won’t solve your problems, sometimes you solve them yourself. One example: get your own screwdriver and change the cubicles over the weekend.
- Find your guardian angels: You need senior managers who “get it”. When you need to bend a corporate rule or special budget funding, your guardian angel. Indeed, many executives are eager to try an Agile approach, because they’ve worked on so many project train wrecks over the years.
- Make good information more accessible than bad information: There is a ton of bad information on the internet about what an Agile approach is or isn’t. Establish a steady flow of good information with email updates, brown-gab lunches, staff meeting talks.
- Measure the results early and often: Publicize the good and the bad results. Have both business and technical metrics. Use surveys to measure both the customer’s satisfaction and the team’s satisfaction.
- The urge to tinker is great: To illustrate the difference between tailoring and compromise, Pete described a game of “CricketBut”. We play Cricket, but instead of a pitch, we’ll use my living room. Instead of a wicket, we’ll use my dog. Instead of a ball, we’ll use a brick. Instead of a bat, we’ll use my head. After a few overs, you will have bloodshed, just like at the office.
- Choose your tools carefully: Don’t ask “which tool should we use”, but ask “What problem are we trying to solve that makes us think we need some software tool?”
- Don’t stop with just the members of the Scrum team: Scrum is an organization framework. Often a team can be successful on a localized level, but the organization is stuck in bad habits and the success is not fully realized. You as a team might be able to deliver results, but if it doesn’t get out to the end customer, who cares?
- Scrum will always be messy: The Agile movement is fundamentally about people and what they do. If people aren’t perfect, then our projects will never be perfect either. You will always have conflict, mistakes, and challenges. Simply ask yourself, “is it better than it was last month”.
It was a lively talk, that yielded some good points. Pete has a witty energy about him that made the talk even more enjoyable.
QUESTION: what have you seen to be the keys to successful Agile projects?
Nice list. Though one of the things that is often missed out is the motivation for doing agile.
In the US, the motivation is generally internal. A company wants to do agile for better time to market, or better visibility or better RoI or whatever it is. So they plan for a long term transition, with pilots and gradual scaling.
In India, its generally because the customer asks for it. So the team goes and learns scrum and executes the project. Next customer wants waterfall? Fine, we do waterfall for that customer.
So there is no choice in which team does agile. There is no question of doing a pilot, then scaling it across the org. There is no question of learning on this project and applying it on the next.
Its customer driven, and agile starts when the project starts, and ends when the project ends. The sole role is to make that one single project work so you get repeat business from the customer. The folks doing agile in this project may well be back to waterfall in the next one.
Because of this different context, the way agile transitions have to be approached is very different from what you would do in the US.
Siddhi, you offer a very interesting point. If Agile techniques have delivered results for you in the past, then why would you go back to waterfall, even if the client asks? If a client asks for a requirements document and UML design, then certainly you can give that to them. But wouldn’t you want to do so, in conjunction with delivering working software early and often?
Thanks for your comment; it’s very insightful.
Very good list.
Actually I’m contracted to a organisation which does have organisational problems (eventhough you would not think that they have, if you would know the organisation). The good thing is, that they know that they have problems. The bad thing is, that they (or at least some parts of the organisation) think, just with using SCRUM in their projects, everything will get better. So, already reflacting the first point of the list would lead them to other steps first before choosing another project-management-framework than the acutal working one.
Furthermore, because of the lightweight framework, at least points 8,9 and 10 are not covered at all. There are people in the organisation who think that they know how to use the framework just because they read some (in fact: one) books about it; these people act like the so called evangelists. But they can’t do everything like in theory, because the organisation is not adopted to the framework at all.
I don’t know, if this is really true. But if only 30 % of the SCRUM-managed projects are really agile, it’s most likely because the responsible people didn’t walk through such a list BEFORE they decided to do SCRUM.
Dieter, great story. Yes, the key cause of failed Agile projects is doing it for the wrong reasons. However, that does not mean you are doomed. It is important to remember that all change is bumpy and imperfect. It is certainly not ideal for Agile enthusiasts to talk about their new process as a sliver bullet. But, it is at least a start. If you are there to help coach people to address the real problems, then success is still possible.
Unless the Agile adoption starts from the top Management, it will be very hard to achieve good results. Tope Management should understand the concept well.
When a team who practise Scrum says something through their experience, management should try to understand that rather than saying “its’ against our policies”. May be some needs additional funds to cater the requirements, but if the team has good enough reasons, Management should try to cater for them.
I totally agree, Prasantha. Any change need both bottom-up AND top-down support to be successful