Getting Started with Scrum

Let's talk about the basic standard patterns in getting started with Scrum. (We have talked about these ideas before, and so have many many coaches and advisors.)

• Start a pilot team

This also means pull together a team with the best possible criteria for success. These criteria are worth reviewing in more detail later. But let's at least mention now that it ought to be a full time team (every member full time), about 7 usually, and dedicated to the full success of only one mission. And the environment around the team should be set up for success (at least as compared to set up for failure). Start only one or two teams at a time. The organization needs to support them. The people (eg, you) and the org can only handle so much change at one time. Once you have the one or two teams going well, maybe add a third.

• Team training

We recommend that the full team be given training together. And that should include key people around the team. They all see each other buying-in to the lean-agile-scrum ideas, or maybe not fully. But they can all see. This makes it much easier for the beginning ScrumMaster, for example.

• Team coach

Everyone (AFAIK) agrees that a team coach is essential. This needs to be a senior agile person, an experienced coach. That person is coaching the whole team and the organization immediately around the team. The person is teaching them Scrum (what they do wrong compared to what they learned in the course), advising, coaching about details, answering all their 'how do I do it exactly?' questions, etc. Both in the team and for people outside the team. There is not much agreement in the Scrum community on how much the coach is there. Some say, for example, full time for one team for 2 months (40 days). Others say 3 days or 2 days at a time for 4 sprints (let's call that 9 days). But, that beginning teams need a coach is understood. Should this coach be internal or external? At first, no one internal is usually ready to be a coach. And at first you need an authority, and an internal person usually does not carry that authority. Later, you need both internal and external coaches. The internal ones help make 'realistic' choices and address 'realistic' problems. The external people keep the internal people 'honest', and keep them from compromising too much. The external people tend to pursue change more aggressively. Always a good thing as long as people are willing to learn through mistakes. Enough for a start?  

Starting agile adoption

Imagine that you have gotten some interest in Agile. Perhaps you read a book, and talked with a friend who is doing it at his firm.

And then you take a Scrum course.

Now what do you do?

Let’s take a middle of the road case, where you have a software development group of 80 or so, and business people for another 20 people. You are one of the 80.  You’ve come back to the office on Friday morning. You want to do something with Scrum, but you are unclear where to start.

Here are some ideas.

1. Take a deep breath.
You are a beginner. You won’t do everything in one day, and there is no need to do everything in one day.

It will be a long, up-and-down climb. Get ready.

2. Convince some people to do a pilot.

Talk to some people who seem interested. Get them more interested.  Ask if they would like to try it.

Talk to a boss, and ask if he would be ok to try it. Maybe 6 Sprints (2 weeks each).  One Team.  Probably the pilot would be longer than 6 sprints, but you ask him to commit to at least 6 sprints as a fair trial.

3. Do the pilot

One team, 7 volunteers.  Get people who want to try it.

Work hard to make it successful.  Get some important impediments removed!

Almost surely, by 6 sprints the Team will be clearly better than what you all used to do.

4. Tell good stories

You have to tell the stories of success. Of how and why it was better.  About some happy people.
About some good numbers.  Depends partly on your culture.

5. Continue the first pilot and start a 2nd pilot

Make these a success.  Again, get volunteers.

6. Consider a Open Space event

About now, you may have some momentum.  And also a sense that some things must change to make this new thing (agile) work better around here.  Use the Open Space event to identify and attack those key impediments.

Both impediments to the 2 existing teams and impediments to a broader agile adoption.

7. Deepen the existing 2 Teams

The deeper and stronger they become, the more they become hardened ships that can cut through the deepest arctic icebergs.

Build their stories till the stories start to sing themselves.

8. Widen the teams.

Add another 2 teams. Do not widen too fast.  Take care of these teams. Remember that they are new.  They need more help.  The culture is now feeling a threat, and is starting to resist.  The volunteers are not quite a gung-ho.  The overall complexity is mounting.

Do not widen the agile too fast. Give yourself (and those you have gathered) enough bandwidth to support these new teams properly. And still support the 2 original teams.

9. Start an management IRT

IRT stands for ‘impediment removal team.’  This Team (and it may be part-time) takes as its backlog some of the impediments from the 4 existing teams. And the managers in this team must deliver, sprint by sprint, solutions to impediments.  Implemented solutions to reasonably sized impediments. One each sprint.

It keeps the managers off the streets. Gets them actively supporting agile.

10. Rinse and repeat.

Well, there are many more things that could be said.

But continuing to do these same things, as the adoption widens, is not a bad idea.

And it allows me to close this blog post for today.

At first, when Scrum and when Waterfall?

When your company is first starting Scrum, how do you decide which projects use Scrum and which ones do it 'the old way'?  (Let's assume the old way is a form of waterfall.)

Here are some factors that might tilt a project toward Scrum.

1. Is the Team willing to try Scrum?  The more positive they are toward Scrum, the better.  At first it will be new, bumpy. And you want a Team willing to work through the bumps to get to some success.

In part, you need a little success in your company to get the more skeptical types to feel comfortable using Scrum.

If the Team starts in a skeptical a mood about Scrum, they start to make it fail.

2. Will someone help with the Impediments?  The more this is positive, the more you choose this work.

3. Good product owner.  If for one project you can get a good PO available 80%, and for another the PO is weaker and available 40% -- choose #1.

4. Reasonable stability of work in the Scrum.  If project 1 will not want to change the work during the Sprint much, and project 2 needs the work more often to change in the Sprint, then choose 1.  But this is reason #4.

You want the Team to commit to work in Sprint Planning Meeting, and start to see the positive momentum of completing it by the end of the Sprint.  Fewer changes (zero is even better) increase the chances of that.

5. Do-able project.  It is fine to give a new Scrum Team a challenging project. But do not give them an 'impossible' project the first time out.  Simply because they are just learning Scrum.

Now, sometimes you have to anyway.

6. The skill sets are more fungible.  Fungible is a fancy financial term.  It means that person A is more likely to be able to do (some of ) person B's work.

We want that with Scrum.

And we want it work things can be done more 'all at once'.  For example, we don't feel that we must finish all of A before we can do any of B.

7. More likely to change.
I will use that phrase, but let me explain. Project 1 is more likely to change.

Project 2 will have less change.  And project 2 is a project that we feel confident we know how to do.  Many of the people in the team feel they have done similar projects.  And we have high confidence that project 2 will have few major surprises.

In that case, I think Scrum will help project 1 more. Because Scrum will enable the Team to learn faster and adapt faster.  For project 2, at least now, it appears that learning and adapting will not have as much value.

Still, I find it hard to say this. I have had too many projects that seemed 'stable' at the beginning, and yet when we got into it, all hell broke loose.  And there was plenty of change and learning.  So, watch out for the accuracy of your initial assumptions.  You know about how the word 'assume' works.

***

I think those are the major factors.  I may have left out one or two.  Probably I will revise this post after a few comments.

Blue pill and Red pill

In a class in Romania, a participant asked me: "don't you think you are setting false expectations? Scrum may help but it will not help that much. This sets false expectations and disappoints people."

Good comments. Good concerns. But I don't agree that we are setting false expectations, although I think these issues must be addressed.

As background, I said that we want each team to increase their productivity by 5 to 10 times. And we want that by working normal, sustainable pace. And with everyone (as far as possible) having more fun. And we want to double productivity in 6-12 months.

Now, this assumes that we get aggressive about removing impediments. Creative in identifying them. That we make a good business case for many of them. That we act rigorously and professionally. And that the managers and the firm permit us to fix things, if we make a reasonable business case.

I admit these the managers often don't let us fix enough impediments.  Sometimes almost none.  But usually the biggest problems are elsewhere.

So, if someone has managers who won't let us fix impediments readily (and yes this situation exists in the real world some), I still expect them to try to fix things. Yes, it will be harder, and maybe it will be hard to double productivity.

And I think a lot of 'bad' managers are just decent people and they just need someone smart like you to help them see the light.

As another partial answer to his question...

It helps to tell the truth even when it is hard. And I think adults should not lose heart even when things aren't good and the path forward is unclear. In other words, adults should not get discouraged.

Scrum does not believe in taking the Blue pill.

For those who have not seen the Matrix movie in a while, let me remind you. The Red pill means that you can see the truth, and it is painful and hard, but you have a chance at freedom.  And a chance to fix things.  The Blue pill gives you 'happiness' as the Matrix would like you to see it, with a blue filter.  But it is false and it is not the truth you are seeing. And freedom is not possible. You give up freedom for a false 'happiness.'

So, people can and do complain that Scrum makes them see bad things. And, so far, Scrum compared to waterfall, does do that.  You do see more 'bad' things using Scrum.  Because Scrum makes them visible (not because Scrum causes them to exist).

Except that seeing the truth makes it easier to fix things.

The next thing to say is that Scrum, after everything, is still more fun than waterfall.  Well, if they play real Scrum.

Leading Fearless Change

What is the hardest thing about Scrum?  (Maybe in life.)
Probably, it is that we must lead change.
Getting people to change is difficult. And in Scrum, for example, we are always trying to change people. Always continuous change. Always removing impediments.
But first, we have to change them to agree to a fully dedicated real Team. Then to fewer disruptions and only one product (product release). Then to doing all of Scrum. Then to really understanding self-organization.  And on and on.
And then we start with the real hard impediments. Technical impediments. People issues. Managerial issues. Organizational issues.
Here are some resources to start with:
Leading Fearless Change by Mary Lynn Manns and Linda Rising. A good article by them. 3 pages.
This leading change course. With Mary Lynn Manns. In Charlotte in April.
By the way, this course will be about change. Any change. Not just change using Scrum or Agile. Any change.

Where to start?

Some of us have been doing lean-agile-scrum for awhile now. And we forget that others are just starting.

So, where does one start?

The first answer is that you start from where you are. One thing this means is that one starts with the impediments one has today. And you use Scrum to help tell you "what is the biggest impediment today?"

And there is always a biggest one today. And it is hard to predict what will be the biggest impediment tomorrow. So many different things can be slowing down the team. So many things can come up in an instant.

Is it useful to work on a less-important impediment? Well, yes, but not nearly as useful as working on the top impediment. THIS IS IMPORTANT. We should always be working on the top impediment (presuming that it can be improved, or that 'they' will allow us to fix it).

Why should you start Scrum? (This gets to the core issue of starting with right intention. As any good Buddhist would want us to.)

Well, some people want a work life that is more fun. Some want to get rid of a bad manager. (BTW, I think very very few managers are 'bad', although I do think lots of managers have been taught badly how to do their work.) Some want money. These are all good reasons.

But I think the best reasons are phrased a bit differently: To make my life better, to make our team's life better, to make our customers' lives better. You will note how that starts from the center and moves outward.

And it raises a fundamental question: what does it mean to make someone's life better? This is a difficult yet important question.

I think it is bigger than software. And I think that important words, like freedom, love and self-responsibility, are in there. And working as a team and at the same time fulfilling oneself as a person. Perhaps we may say a connectedness that that makes us more individuals rather than less. (I am in eastern europe (Romania) as I write.) We do not join a collective to lose our individuality, but rather, seemingly paradoxically, to become yet more our own individual selves within the team.

Within the dualisms we are used to thinking in, this sounds a paradox. But it is the truer organic reality.

Learning how to do this can be painful, but, as the song says, and as every mother knows, a deeper pleasure is on the other side. (See http://www.metrolyrics.com/save-room-lyrics-john-legend.html for the lyrics, if you are interested. Good song too.)

One team recently was going through this pain. One wondered how long it would take. One wondered "will they get to the other side?" Still, one has confidence that people learn from scraping their knees.

A re-write....

I have taken an article out of context, and re-written it below. Here is the original:
http://www.only-positive-news.com/archives/1232

See how you like the re-write:

If social psychologists have proven anything during the last 30 years, they have proven that the actions we take leave a residue inside us. Every time we act, we amplify the underlying idea or tendency behind it. Most people presume the reverse: that our traits and attitudes affect our behavior. While this is true to a certain extent (though less so than commonly supposed), it is also true that our traits and attitudes follow our behavior. We are as likely to act ourselves into a new way of thinking as to think ourselves into a new way of acting.
There is a practical moral here for us all. Do we wish to change ourselves in some important way? Perhaps get better at Scrum or convince people of the principles behind Scrum? Well, a potent strategy is to get up and start doing that very thing. Start doing Scrum. And ask them, as Coleridge said, to willingly suspend disbelief. Don’t worry that you don’t feel like it. Fake it. Pretend that you want to do it. Feign optimism. Just do it. Do it as an experiment.
In doing Scrum, they typically find that all the fears of how it won't work melt away, or at least become much less. And they also experience all the good things about Scrum (one example: the building of trust between the technology side and the business side).
Yes, telling people to act or talk positively sounds like telling people to be phony. But, as usually happens when we step into some new role–perhaps our first days “playing” parent, salesperson, or teacher–an amazing thing happens: The phoniness gradually subsides. We notice that our uncomfortable sense of being a parent, for instance, no longer feels forced. The new role–and the new behaviors and accompanying attitudes–have begun to fit us as comfortably as an old pair of blue jeans.
The moral: Going through the motions can trigger the emotions. Surely you’ve noticed. You’re in a testy mood, but when the phone rings you feign cheer while talking to a friend. Strangely, after hanging up, you no longer feel so grumpy. Such is the value of social occasions–they impel us to behave as if we were happy, which in fact helps free us from our unhappiness.
Granted, we can’t expect ourselves to become adept at Scrum overnight. But rather than limply resign ourselves to our current practices (waterfall?), we can stretch ourselves, step by step. Rather than waiting until we are utterly and completely confident that we *know* Scrum will work in our new special situation, we can begin. If we are too anxious, modest, or indifferent, we can pretend, trusting that before long the pretense will diminish as our actions ignite a spark inside–the spark that will lead to happiness.
* * *

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.

How to learn more about Lean-Agile

Several people who have taken recent courses have asked "where do we find a discussion group where we can learn more about agile?"

Here are some answers.

First, find local people.

Agile Alliance has a list of agile groups. And the Scrum community has identified some local groups (often the same ones) here. In fact, the Scrum community has identified its community more broadly and specifically, here.

What are other ways to learn? Certainly there are many books. Here is a list, although not complete.

There are discussion groups, especially on Yahoo. Here are my top four:

scrumdevelopment
extremeprogramming
agileprojectmanagement
leandevelopment

There are other very good ones.

And there are some good blogs as well. Carnival of the Agilists highlights better blog posts. And the Scrum community has listed a lot of great blogs. And don't forget the blogs in the Blog Roll to the right (some repetition in these lists).

That should get you more than started.

The Agile Recipe; on second thought...Not

I have been asked recently to provide a recipe for how to do Agile. I am sympathetic with this request, but I feel it misses an important point.

First, why am I sympathetic. Well, because I look at Agile as an art form, like playing the violin or learning Hapkido (Korean version of Aikido). It is an art that one continually learns. And, at the beginning one feels lost. How do I learn this thing that seems so strange? How do I start to make un-ugly noises from the violin? And the teacher must give you instructions of some sort, and you start to play. Perhaps ugly at first, but you start to play. And then you start to be…as a friend pur it recently, you start to suck less.

Of course, Agile is more like a team sport than playing a violin. But it is still an art. Where one starts with little skill and builds and builds. Agile is like the "ballet with force" that is basketball.

OK, So how do you learn to play basketball?. Well, start by dribbling. (Which one can break down.) Learn to do a layup. (Which one can break down.) But the real thing about basketball is not the individual skills. The real juice is learning how to play as a team. To improvise on the court. To maintain your confidence if the other team dunks on you twice in a row.

In basketball, there are a few set plays that one can diagram. With perhaps many variations. One cannot just follow a recipe in playing championship basketball.

This is where giving the recipe can mislead. By giving a recipe the coach can suggest to the beginner “all you have to do is follow the recipe and all will be well”. Maybe with an ordinary dish, but not if you want a meal that dazzles. And don’t you aspire to produce something that delightful?

If you have studied an art, you know that great artists will tell you that being really good requires a certain something that is hard to define. In Agile, we often say that you must "get it". You must start to reflect, in your every thought and decision, Agile values and principles. And without these values and principles, just following the cookbook or the recipe will make only a small improvement.

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.

Proposed Reading List

For the CSM Class in NYC on Sept 5-6.

A teacher recently told me this: “To know and not to do is not to know.” And we know from many teachers that we learn best by thinking a bit and then practicing some, and then thinking some more and practicing more.

This is embedded, as one example, in the Deming Cycle.

So, I have already suggested that the best way to learn for you, right now, might be to practice for a while. A short while.

Next, one needs to say that each of us is different. So, if we want our learning to be effective, we need to consider our individual needs and abilities. Some of you think in concepts, some in pictures, some with stories, etc., etc. Some of you understand (or have no interest in) User Stories, for example. Others have pressing needs to understand engineering practices.

Also, now that you have been infected with the Agile virus, you can read almost any book from an Agile viewpoint. War and Peace by Tolstoy is one of my personal favorites. This might be the best way for you.

Now, after all these explanations (and you might say, excuses), here are some suggested readings.  I have these books on my website, with direct links to Amazon, so you might want to go there:

User Stories Applied by Mike Cohn. Great book on how to write and use User Stories. And once you feel you get the ideas yourself, go to his site (www.mountaingoatsoftware.com) and download some of the presentations on this subject. To use for your discussions with associates.

Agile Estimating and Planning by Mike Cohn. Here he discusses planning poker, and lots of other subjects around Release Planning and Iteration Planning. Again, he has very useful presentations on this subject as well.

The New New Product Development Game by Takeuchi and Nonaka. Article. This is where Scrum started. To me, it is essential that we view our selves as creating new products. Passing this one around starts to get light bulbs turning on.

Extreme Programming Explained (2^nd Edition) by Kent Beck and Cynthia Andres. Kent Beck, Ron Jeffries and Ward Cunningham are the three guys most responsible for extreme programming. Kent is an excellent writer, and his discussion of values, principles and practices is wonderful. (Be aware that some people prefer the 1st edition (2000), but that is now hard to find.)

The Knowledge-Creating Company by Nonaka. This is a HBR article that summarizes many of the key concepts in the book (of the same name) by Takeuchi and Nonaka.

The Concept of Ba by Nonaka.  This is an article that summarizes some of the key concepts that are discussed in the Hitosubashi on Knowledge Management book, edited by Takeuchi and Nonaka.

Fearless Change by Manns and Rising. This book is about introducing a new idea into any “group” (such as your company). These ladies are actually Agilists, but the book is about introducing any idea (not specifically Agile). The book presents a little theory and lots of patterns on how to influence various people so that Scrum/Agile/Lean will succeed in your group. The majority of these patterns you know, but the reminders, tips and tricks are very valuable. Arguably, this is the most important book for you right now.

The Power of a Positive No by William Ury. Bill co-wrote Getting To Yes. This book, about saying no sometimes, is essential. Almost everyone in Agile that I know is not practicing sustainable work because they can’t say “no” enough. Frankly (although Bill is a friend) the title is a little hokey to me, and the basic idea seems obvious (you have to say “no” before any “yes” can have meaning). Again, in theory there is no difference between theory and practice…in practice, there is. As you read the book, I think you will learn useful ways to say "no" almost as often as you should. Priorities.

Working with Legacy Code by Michael Feathers. This book has lots of ideas about how to deal with legacy systems. Michael is an excellent Agile Coach (a bit more in the XP flavor).

Lean Thinking by Womack and Jones. The first chapter of this book is an excellent introduction to Lean. Some of you will be amused to learn that Ohno, whom many credit with inventing Lean, said that he learned it all from Henry Ford’s book Today and Tomorrow.

Implementing Lean Software Development by Mary and Tom Poppendieck. Excellent source for taking Lean ideas and applying them to software development. This is their second book. Not a bad book for you to read first, in fact.

Godspeed on your journey.