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.]

QUOTE
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 matrixed 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
UNQUOTE

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.")

QUOTE
Hi,

The situation you describe is classic. (With of course a million minor variations.)

So, let me start with the story of the American couple who flew to Dublin in early Dec. They rent a car and travel around the countryside. At 4pm 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 of course say this. Almost every day. And it is useful to chuckle at ourselves when we do.

Now, I do not mean to minimize the difficulties you rehearse. They are hard. And 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 the help of 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 influencing to a core team of stakeholders, to this effect: Getting them to support you on the project, to 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 Scum for a couple of months. Get them to buy-in on principle that the new team needs to NOT do things the old way.
5a. For example, I would hope, given your own great personal powers of persuasion, that you could convince them for this one team, that 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). 20% allocation to doing old stuff or helping out other (new) projects.
6. Do a product backlog with business value 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 2 weeks almost always...more feedback, faster).
9. Focus on all the core Scrum things: the 3 roles, the Daily Scrum, the Sprint Planning Mtg, the daily work, the Sprint Review, the Retro. And the Scrum artifacts: Pro Bklg, Sprint Bklog, Scrum Board, Burndowns (or Release Burnup), the "potentially shippable product increment". The Impediments List. Fix the top impediment (over and over again). And 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 (or even you do). 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 stopping doing it as well. The SM must explain it to him again.
10. Deliver something meaningful, at a reasonable date. Let's say in 2 months (4 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? well, typically)...to gather their buy-in to helping you push down impediments. Now you start to have some real power behind the changes you want to make. IT managers can drive you nuts, but magically they often shut up when the right business guy is in the room. Funny how that happens. 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 throw at you in a specific situation. Only fight the issues 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 3 projects at once should be compelling. Discuss that.

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 out, 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 expresso makers. "Just think of it as magic. I pour expresso into the room and out magically every 2 weeks pops working software." (Your team may not care about expresso, but you get the idea.)

The Agile community has not scientifically proved this (that Scrum is the minimum), but it is emerging that Scrum is probably the bare minimum that 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 I know, eventually you want all (or almost all) the XP stuff and all the Lean SW Dev stuff also. Just not on Day 1.

Does this help?
Did you have an "oh, $#!&" 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
UNQUOTE


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 (and they) learn most by seeing what comes out. (Scrum helps instantiate the sausage maker.)

4. In most situations, take a decision. There are few things worse than no decision. However bad the decision was, you can inspect and adapt shortly, 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.)

How do I start an Agile project?

I have been teaching Agile courses for a while now.

One of the persistent questions is: "Enjoyed the course, but I want more help on actually doing an Agile (Scrum) project?"

In part this question arises from a wish to have a "cookbook". This cookbook notion is something most of the smart people (at least people I think are smart) want to avoid. Agile is there to make everyone think together; it is not there to stop you thinking and let you just follow the checklist in the cookbook.

In part this question arises from a wish to understand everything in two days. While Agile is simple in some ways, it really is far too complex to be fully understood in 2 days. In my opinion, there is still much I need to learn about Agile; much I can get better at. Even after years working at this.

OK it's an awkward question. Still, beginners need some help in starting. (Now, as you learn these dance steps, remember that you will never be a good dancer without feeling the music. In Agile, this means you must let the Agile principles become gut instinct. This will take a long time; keep listening to the music.)

So, what are the basic steps?

At one level, they are Deming's Plan-Do-Check-Act. In fact, at several levels. (See the Deming Cycle.)

But let's take it to the next lower level. This is what I tend to do...

1. Confirm that you have a meaningful effort to work on.

Many times, someone "says" we have a project, but often it is a bunch of nice, somewhat useful work. Don't accept that. You want work that is very valuable. You only have one life on this earth. Do something meaningful with it. And let the team have something truly meaningful to work on.

[Note: I assuming "you" are a manager responsible for a large set of work (eg, a project). But really "you" could be any team member. Or other people.]

2. Gather a team.

It is always good advice to get the best people you can. Recruit them. (Note: it helps to have a juicy piece of work.)

3. Assure that the team is on the same page, and agree on a definition of Done.

Important step. Many parts to it. Often forgotten or minimized. Agree that the definition of done will change later.

4. Prepare a Product Backlog of user stories (and other work).

Identify the stories, identify the Business value of each story, identify the story points on each story, identify other factors (risk, dependencies, etc.)...and then order the work. Do initial Release Planning (for now, I will say that means laying out the work into Sprints, and seeing when the first release will be).

This does not have to be perfect and complete; you will revise, add and improve as time goes on. As you understand the effort better.

5. Work on Iteration Zero.

Prepare the infrastructure that the team needs to do its work. (In some ways, this step could start earlier.) This work does not have to be completed before starting a real Sprint 1. And later Sprints might also include some infrastructure work.

Do I need to say that every Iteration is time-boxed? Yes, even Iteration Zero.

6. Start Daily Scrums (standups).

Start them in Iteration Zero.

7. Do Sprint Planning.

8. Do daily Sprint work and Daily Scrums.

Completing the stories. And this includes refactoring the Product Backlog and preparing Agile specifications for the stories in the next Sprint. And other things.

The ScrumMaster always has an updated Impediments List and is working on the top item. (In effect, this list started on day one.)

9. Do Sprint Review.

This always includes a demo of some sort. We want feedback. We want to learn faster how we were wrong.

10. Do Retrospective.

This meeting must identify actions. And some actions (with some impact) must be taken before the next Retrospective. The actions should be addressing one or two top items on the Impediments List.

11. Repeat steps 7-10 until effort is finished.

When you repeat, you must use Velocity to adjust how much work to bring into the Sprint. And the team must, almost immediately, be thinking of every way to increase their velocity. Every way but working more hours than, say 40 per week.

* * *

Those are the basic steps. There are a hundred questions about each step. The questions (and answers) vary depending on the situation. And usually there are some standard, expectable impediments that arise very early. So they in effect add more big steps in the beginning (or whenever they are discovered).

As with dance or sports, there are lots of variations on the steps, depending on the situation.

"Solve no problem before its time." A catchy way of saying, as you start, don't look for extra trouble. Work on only the most important impediment affecting team velocity. If you worry about every problem that is affecting, or did or will affect the team, you can become too discouraged. (The team can actually "work around" more problems than you probably think.)

More on this "getting started" topic later.

"Kids, careful trying this at home." Some say they actually did try this at "home" without help from an experienced person. With success. Usually, if they had much success, they actually did have lots of help from people experienced with Agile, although perhaps less help than other large firms got.

A metaphor. Kind of like NCAA Final Four basketball, it looks easy until you actually try to do it yourself. It's hard on the body, the head, the mind, the will. Still, if you want to, you can be a winner with Agile. Certainly lots better than where you are now.

Keeping with the Beat

Where would I go to find the latest information on Agile and Lean? What if I had a question and wanted expert advice?

Try these "boards". Sign up. They are free.

ScrumDev

Extreme Programming

Agile Project Management

Lean Software Development

Industrial XP

I am a particular fan of the last one. It's theme is applying XP in large, enterprise situations. Some very good conversations.

Advice: As with most things in life, you get more by giving more. Dive in, don't just lurk. Receive postings in a Daily Digest (change it at "edit membership").

Caution: There is some "inside baseball" or "inside the beltway" stuff going on. Bring your salt shaker. Sometimes a board or several boards will seem to become obsessed with one topic. There are many reasons for this, but if you need a discussion of a topic, search the history or ask a new question. Ask and it will be answered. Seek and you will find. Be selective. Use common sense.

There are some great people on these boards. Some of the comments are pearls beyond price. (And some are rubbish.) YMMV.

If you are interested in similar boards, tell me. There are others for more specific topics.