What to do first?

I just got an email from someone who recently went to one of our Scrum courses. (Note: This is a long but, I think, interesting post. Bear with it if you can.)

QUESTION:

Hi,
Let’s say one is going to work as a team lead for a software project in an organization that currently does not use Scrum and that may or may not in the future. Let’s assume that the org currently uses a matrix structure where developers are shared between projects and their time is allocated via some sort of resource manager to individual projects.

Let’s also assume that you, as the new team lead, can’t just unilaterally say that you are going to manage the project using Scrum but have to peacefully coexist in this matrix environment. Let’s also say as the team lead you wanted to introduce Scrum but realize that trying to initially go 100% Scrum wouldn’t be organizationally possible.

Finally, the question …
As a team lead in such an environment, which Scrum/XP practices would you try to introduce first, in which order and why?

Thanks,
Robert

This is what I wrote him quickly, slightly edited. (Sorry, can’t promise such a long reply to every question. And, as a wit said, “Sorry for the long email, I didn’t have time to write a short one.”)

ANSWER:

Hi Robert,

The situation you describe is classic. Of course with a million minor variations.

So, let me start with the story of an American couple who flew to Dublin in early December. They rent a car and travel around the countryside. At 4 p.m. that day they are in a small village, lost, and need to get back to Dublin before dark. They go up to a little old man and ask, “How do we get back to Dublin?” He says: “If I were you, I wouldn’t start from here.”

We all say this, almost every day; it is useful to chuckle at ourselves when we do, but my advice is not: “If I were you, I wouldn’t start from here.”

Now, I do not mean to minimize the difficulties you mention — they are hard. Life itself is sometimes hard, but that’s why we do this interesting work.

My brother has also reminded me that there are two times not to give advice. When someone asks for it, and when they don’t. Nonetheless, I will give this advice.

1. Start from where you are.
2. Believe in your own power to influence the situation, in large part by recruiting others (up, down and sideways). As you know, to get another person to do what you want, you must help them see with their own eyes why they want to do it (usually positive reasons are best). You win by showing them the truth (perhaps slowly). You can never win (in the long term) with power, so do not pine for your own lack of so-called power. Your power is in being truthful and being right. Be happy that people will all the more readily tell you what they really think.
3. Find an important project and a good team including a good PO. (Assuming you will be the SM.)
4. Start working on a round of influence to a core team of stakeholders, to this effect: Getting them to support you on the project, make it a success, by using Scrum and by removing impediments.
5. Get a minimal level of buy-in from this stakeholder team. Perhaps just enough to start the effort with Scrum for a couple of months. Get them to buy-in on principle that the new team needs to NOT do things the old way.
   • For example, I would hope, given your own great personal powers of persuasion, that you could convince them for this one team, the “pigs” will be allocated at least 80%. Partly because this is such an important project (ah! that’s why you wanted an important project). The other 20% is doing old stuff or helping out other projects.
6. Create a Product Backlog with Business Value points and story points, etc.
7. Get a team room and collocate (as much as possible). It is so much easier for them to learn Agile that way. Maybe this is Step 12.
8. Pick a Sprint length (I like two weeks almost always — more feedback, faster).
9. Focus on all the core Scrum things: the three roles, the Daily Scrum, the Sprint Planning Meeting, the daily work, the Sprint Review, the Retrospective. Also the Scrum artifacts: Prod Backlgo, Sprint Backlog, Scrum Board, Burndowns (or Release Burnup), the “potentially shippable product increment,” the Impediments List. Fix the top impediment (over and over again) with the values and principles behind them.
   • Note: There will never come a day when they (and there are many people in “they”) totally understand Scrum. They will forget. You will always be explaining Scrum, and why each piece is useful.
   • Ex: George may understand the Daily Scrum for awhile, and then he will forget, or stop doing it as well. The SM must explain it to him again.
10. Deliver something meaningful, at a reasonable date. Let’s say in two months (four Sprints). Release 1.0. (Note: This period can vary a bit, but remember the business side is your friend (or will be soon) — they want stuff now!)
11. Once you start to make the business side happy, work with your PO (a business guy, right?) to gather their buy-in to helping you fix impediments. Now you have some real power behind the changes you want to make. Explicitly or implicitly, the senior business guy is saying, “We have business goals to accomplish, and all that IT political BS is not helping. Get the heck out of the way of my effort.”

Notice a few things:

1. I kept all of bare simple Scrum in the initial “big change.”
2. I did not suggest big changes to engineering practices first. Planning Poker, yes. User stories, yes, probably. Anything else from XP that I can get “for free,” but my political capital is not put there first.
3. I bent them, but did not break them.
4. I did not even talk about how you convince the team itself.   Sometimes that is an issue.
5. Lots of things might be issues, but you won’t get all issues thrown at you in a specific situation. Only fight the most important issue you really have today.
6. If you have to compromise on Scrum (team allocation, interruptions, etc.), make it clear/visible (in a nice way) and keep asking, “Is this the best way we can do things?” With matrix, I am betting the slide about doing three projects at once should be compelling. Discuss that. Use that slide often.

So, you co-exist with the matrix, but because you have an important project, they let you get a high allocation of the people in your team.  And you keep on asking for a higher allocation.  You tell them you need that to deliver more quickly.  And you show them the advantages of focus (or relatively more focus).  I am hoping 80-20 at first. It might be worse at first, but keep making clear the advantages of higher focus and the problems with lower focus (allocation).

Here is another mantra for you to some managers:

“Let me do what I want with this team for awhile — just think of it as magic. Hold me accountable for getting more results, and don’t ask how I do it, and why I do it this way. Just help me do it.” A colleague tells the story about getting espresso makers.

“Just think of it as magic. I pour espresso into the room and magically every two weeks out pops working software.” (Your team may not care about espresso, but you get the idea.)

The Agile community has not scientifically proved that Scrum is the minimum needed to be successful.  But it is emerging that Scrum is probably the bare minimum you need to start. That’s my answer to “why.” There is no better Agile answer to the bare minimum that has much support. Like all the good Scrum people whom I know, eventually you want all (or almost all) the XP stuff and all the Lean Software Development stuff — just not on Day One.

Does this help?
Did you have an “oh, shucks!” moment? Yes, it ain’t easy and you have some hard work to do. Go get that Dale Carnegie book (How to win friends and influence people), or something similar (Fearless Change).

Best regards, Joe

Depending on your situation, one of the following might also be helpful:

1. “When you come to a fork in the road, take it.” — Yogi Berra (A little humor always helps.)
2. See “The Road Not Taken.”
3. Keep cranking the sausage maker. You learn and you help them learn the most by seeing what comes out. (Scrum helps instantiate the sausage maker.)
4. In most situations, make a decision. There are few things worse than no decision. However bad the decision, you can inspect, adapt and make an improved decision with more information. (This is almost a quote from Ken Schwaber.)
5. If you wait for perfection, you might wait too long. (I guess this is my quote. Said with a smile, since I find that nothing is perfect, and, as Yogi Berra so rightly says, if the world were perfect, it wouldn’t be.)