My blog has moved - http://www.mitchlacey.com or http://www.adoptagile.com

I have moved my blog and am in the process of porting over the content on MSDN blogs. 

 See my new space on the web at

http://www.mitchlacey.com or http://www.adoptagile.com

-Mitch

I am writing a paper for the 2007 PMI Global Congress in Atlanta on Agile Transition.  Part of the paper covers the Agile Manifesto.  As I began researching and writing about it, I found that I had gaps in the historical data on the web.  I was fortunate enough to interview Jim Highsmith, Ward Cunningham and Ken Schwaber via telephone to get a better understanding of how the Agile Manifesto came about.  Here it is.

The Agile Manifesto (Beck, K., et al. 2001) describes a set of values and lists a set of subsequent principles (Beck, K., et al. 2001) that focus on a different way to build software.

In response to the popularity of heavyweight methodologies, such as RUP and CMM, in the late 90’s and early 2000’s, Dave Thomas, Robert Martin and Jim Highsmith proposed a working session to a group of follow lightweight methodologists. The group was comprised of 17 individuals, including Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas.

The working session organized by Dave, Robert and Jim had two objectives.

• Each person will present to the group his lightweight method approach to building software
• Discuss the surge of heavyweight methods and how to address them

The working session started with each person presenting his approach to development. As the presentations progressed through the day, a pattern began to emerge, but there was something in each presentation that was not aligning. It was the middle of the first day and people were becoming less focused. There were several informal breakout sessions occurring. A group of four or five individuals were working next to a whiteboard and one of them said “hey, let’s try a ‘this over that’ format and see what we get”. These people used the existing ideas that were written on the whiteboard and began re-writing the words in the new format.

After a period of about 15 minutes, four lines were written. The group had a lot of energy and others in the room began to notice. The rest of the people began coming over to see what was written. As each person read the four lines, they agreed – it was how each person felt. They had a unanimous decision that what was written was the alignment that was needed.

What was written was titled the Agile Manifesto. It states the following:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The group did not set out to create a document of common values and principles. They were the right people together at the right time and the Agile Manifesto was the outcome.

The following day, the group began work on the principles. The principles were refined over a period of two to four months. The principles state the following:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These words mean different things to different people and there is no right or wrong way to interpret them. The values and principles conveyed by the Agile Manifesto are simple, yet take a high level of discipline to follow.

I was watching the Chiefs - Seahawks football game last Sunday when it hit me. Ideal days do not exist.

Damon Huard was starting for the injured Trent Green for the Kansas City Chiefs. Huard was playing with an injured hamstring and sat out most of practice last week. In fact, while I was watching the pregame warmup highlights, Huard was barely able to take a snap and drop back to throw the ball.

This got me thinking that no player in the National Football League ever has an ideal day. Players in the NFL routinely play through pain, often on a year-round basis. Players inject cortisone into their bodies to mask the pain that haunts them throughout the long NFL season.

Then I started thinking about my own life, my own history. When I was 19, I broke a bone in my left foot playing soccer in college. I played through the pain it did not tell my parents about the injury until I was much older (about one month ago). I only told them because I had to have surgery on the foot to have the bone removed.

This seems extreme, except when you factor in that I have been breaking and re-breaking the same bone since that original day when I was 19, well, I guess I'm just a little stupid sometimes.

The point is, the last time I had an ideal day playing soccer must've been on the first day that I ever played. I think I was three years old.

Let's jump forward. I was working with a team and one of the program managers on the team told me that he scheduled his work and built his Gantt charts based on ideal developer days. I was confused because I did not know what an ideal developer day was.

Every developer that I know today, with the exception of one or two, plays World of Warcraft. I asked my developer friends what an ideal day was for them. Ironically, almost all of them said "an ideal day for me would be playing World of Warcraft, or writing code and add-ons for the game. It is just so engrossing."

I went back to the program manager who was building his wonderful Gantt charts and asked him if he had factored in World of Warcraft. He was astonished! Of course he had not factored that in, because what an ideal developer day meant to him was having developers write code to make his project successful. Note, this does not even address testing.

As his project progressed, he was surprised by the fact that no one was on schedule. He did not do anything wrong, he asked all the developers in the testers for their functional estimates based on the work that needed to be done based on the loose documentation requirements that he had.

From that he made a commitment to stakeholders in the organization that he would deliver his project on time and on budget. He estimated in ideal days, not in a practical team based estimation approach is such as Wideband Delphi or planning poker.

Call me crazy, but I assert that ideal days do not exist. If they do, they come far and few between.

Here is what an ideal day is to me:

• Have a full night's sleep which consists of eight to nine hours of undisturbed rest.
• Start the day with a good breakfast, and feel very refreshed.
• Have everything throughout the day work out exactly as it should with no interruptions, missteps, surprises or anything else that would throw our monkey wrench into my well-planned out, carefully thought day.
• Go home and spend time with my family, who also has had a wonderful day. My kids are happy to see the do everything that my wife and I ask of them without talking back are procrastinating and having them going straight to bed without a peep.
• Spend the rest of the evening with my wife, playing games or talking about the days events - basically having some good quality time together.
• Go to bed and get another full night of undisturbed sleep.

Now reality sets in, because the last time that actually happened was years ago.

So the next time you hear someone thinking of estimating, or actually estimating, in "ideal days”, assert that they do not exist and go watch a football game.

One of the things I love about XP (this is a principle of Scrum also) is the concept of Sustainable Pace.  Ron Jeffries aptly documents this on his site in the following text:

Extreme Programming teams are in it for the long term. They work hard, and at a pace that can be sustained indefinitely. This means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out. It's pretty well understood these days that death march projects are neither productive nor produce quality software. XP teams are in it to win, not to die.

The text I find interesting is "...means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out." 

I used to get hung up on this and even today I continue to see others getting hung up on this.  I used to think that I had to work at a sustainable pace and that I would fail if I worked overtime. 

Simply put, this is just not true. 

So, how does one know when it is effective or not effective to work overtime?  Simple.  Teams work overtime when its needed, not demanded.

Not demanded? From my experience, when things are demanded of teams, it's a sure sign of an old command and control structure. 

Mr. Program Manager, you need to have your team come in this weekend to ensure your project stays on track.  I didn't like what was reviewed at the last review meeting and you need to get back on track and stay focused.

Yes, I've had conversations like this in both supposedly agile environments as well as traditional environments.  I was lucky however.  The team I was on was fully agile - practicing XP and Scrum, absorbing and living the principles.

We asked ourselves: "do we really need to come in this weekend?  Is our project really in peril?"  Turns out it wasn't.  What happened in the case above was the upper manager was mis-informed because (s)he missed some meetings prior to the Scrum demo meeting (s)he attended.  As a result, (s)he was out of the loop on the project and didn't like the direction the team was taking based on customer input (architects in the larger organization were one class customers, for example).

By simply asking ourselves, as a team, "do we need to come in this weekend; do we need to work overtime at this point of the project?" we often found that we didn't.  When we did answer yes to these questions, we were dedicated and focused to accomplishing our work. 

The team laid out the work it needed to get done in order to go home at the beginning of the overtime sessions that spanned weekends.  For late nights, we would often have a quick team meeting at the end of the day and decide our goals for the night - the exit criteria that would allow us to leave.

Often times the entire team would not need to stay - this introduced an interesting conundrum - is it OK for some to stay and some to go?  What do we do if this occurs on a regular basis?  What we did is talk about it.  We surfaced the possible perception issue that some team members were working "harder" than others and talked about it.  What we discovered was that we were each very dedicated to the success of the project and that we would each do what was needed to make it succeed, within reason.

Within reason?  Yes - team members had families (some large).  As a result, it was not reasonable for some people to stay late, especially since they came into the office at 0700.  This, of course, will vary by team.

If you find yourself in the position where your team (or a team you coach or "manage") needs to work overtime, have the team ask itself if overtime is needed.  If it is, talk about it, define the goals of what will be done in the overtime sessions (or weekends) and outline the exit criteria.  Follow this with a discussion on who is needed to do the work, and as a result, work the overtime.  Remember, this is a team exercise.

Note: I recommend having at least two people work together as a pair when working overtime.  This helps disseminate the information to the rest of the team following the overtime session and helps keep the overtime session focused.

Try it out - I'd like to hear how this works for your agile team when it faced with the question of overtime.

I was reading Mini Microsoft for the second time tonight (I've really never read it) when I came across a post titled Dev vs Test vs PM.  This snipped from the post got me thinking - why would I want to work together with someone when I get rewarded for being a rock star? 

Well, I have to admit I lopped off how that paragraph ends. I believe there are some great team-building activities spreading through Microsoft, like Feature Crews, that have Dev, Test, and PM working together to create something great vs blaming each other when the should-be-expected unexpected problems arise.

It's like this is a new idea to some people.  Believe it or not, teams inside of Microsoft do practice XP and work together in a shared space.  A prime example of this is the CodePlex team (http://www.CodePlex.com). 

Check out an interview with the team here.  See how they work - heaven forbid they "throw something over the wall" for others to grasp.  They actually work together to achieve a common goal.  Weird for some, I know.

Friend and colleague Brad Wilson defines Scrummerfall as

Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

Which gets us to our story.  I was having an email conversation with a person that I am coaching on pair programming and some colleagues that will be helping (names changed to protect identity).  In his email, "Bob" said that the timeline for us to start the pair programming pilot with him and his team was inline with their "Sprint planning week".  This is a term I had not heard before - not from any literature on Scrum or agile practices or from my friends in the agile community.  I asked the obvious question:

"Bob, what is a sprint planning week - I've never heard of that" I asked.
Bob responded
"I’m probably not using proper Scrum terminology but in our team we commonly use “sprint planning week” to describe the single week before the 4-week sprint where we work out the sprint backlog, people resources, and timeline for implementing and testing backlog items."

What I found is that this particular team breaks their work out by the following:

Week 1 - Planning
Weeks 2 - 5 - The actual sprint.  During this time, developers code while testers write test cases and do light testing
Weeks 6 - 7 - Integration
Week 8 - Deployment to live site
Week 9 - Buffer, just in case.

This is further compounded by the following:

"Notice there’s not a period for writing PM specs, dev design docs, or test plan/specs.  We’re trying to address that starting in our next sprint."

What scares me in this approach is the fact that there are 5 weeks of work (and growing) to encompass a 4 week Sprint.  This is an example of a larger problem that looms in companies across the world.  Instead of working inside a time-box, the team chose to do its "coding" during the Sprint and do everything else outside the Sprint.  Being potentially shippable does not play in this model. 

Being Agile is a mindset.  It is understanding that writing code is only 5% of the work needed to ship software.  Yes, he actually did write that.  Writing code is 5% of the work needed to ship software.  By taking an approach such as the one listed above, that 5% swells into close to 50%.  As a result, things fall through the cracks.  Integration testing, stress testing, environment management, documentation, you name it - it will be forgotten.

Just remember, in the end, Scrum is a framework.  If projects fail, it's not because of the framework, it's because of the people.  Frameworks do not fail, people do.

There was a post on the Scrum yahoogroup if folks encountered resistance from the company and how they got around it.

This is a common theme - here is my experience from my first Agile project:

Let me see if I can quote the developers that are now on the team from back then:

• “Hell NO!  I will never do pairing, or work in a fishbowl, and that TDD stuff is all crap!  I like my office!  Go away!”
• “Mitch – seriously, you’re on crack if you think I’m going to do this”
• “Insert any string of expletives here”

That was in January of 2005.  These same folks now say to me:

• “Thank you for pushing this”
• “We are writing the best code I have ever seen come out of our group”
• And my favorite: “I will never go back to the old ways, the ways of the dark side”

Change is as hard as people make it.  One way to soften the blow is by taking baby steps.  Introduce the team slowly. 

It took me 3 months to go from the first serious of quotes to get everyone in a room to start working.  We initially agreed on the following set of principles to follow:

• Follow scrum by the book for 2mo
• Do TDD to the best of our ability and allow time for us to learn (e.g. read more books, talk to experts)
• Work in a shared workspace
• Do paired programming

As a change agent, you are asking people to go from what they know – what has been successful for them in the past, to going to something they don’t know, something unknown.  Make sure that in taking this risk and jumping on the boat to try this out that they come into it with an open mind.  Get management support of not penalizing the risk takers (one of my biggest hurdles in the change), instead reward them for taking risk, even if they (the team) fail.

Most of all, have fun.

Change is difficult, stressful and rewarding when you are open to it.  Personally, I love change, in moderation. 

When I coach teams, I ask them what they want to get out of the experience, and where they want to be in 6 months.  A common response is "we want to be better than we are today.  Things should just work - this agile stuff can't be that hard".  If you have ever gone through change, you know this is not true. 

Change is hard depending on the attitude of the individual taking on the change.  If it is not approached with an open mind and some clear goals to measure how/when you have arrived at the desired state, chances are you'll flop around like a fish out of water, never knowing if your next gasp will be your last.

Think about a paper matchbook.  The goal is to have your matchbook cover stay halfway open.  When you bend it back halfway, it flips back to a position close to it's original closed position.  Why?  Because there was not enough applied force to make it stay open where you really wanted it to, in the middle.

Apply this idea to teams going through change.  Since I'm a little intense in a lot of the things I do, I solicited guys to join our team with the caveat that we would be going full-bore, taking our virtual matchbook cover and folding it almost backwards in order for the techniques we experimented with to stick, and so we could make the best decision possible in keeping, dropping and recommending techniques to others.

We all start out with a closed matchbook.  We wanted to get to a desired state, which we define and map out so we know when we get there - this is our target state. 

When our team started out, we thought we knew what our target was.  We thought we reached our target just before heading off to the Agile 2005 conference.  Boy were we wrong.  After a day at the conference, we realized how much more we had to push ourselves to reach our target.

When going through change, set your sights beyond the desired target.  Doing so will allow you to reach it with the level of knowledge that is required to know the target has been reached. 

The additional stress, pressure and knowledge experienced while pushing beyond your comfort zone, beyond your target, allows you to sit back in the end and quantifiably say "this worked, this didn't.  As a result, we will tweak our process here by a bit and re-evaluate in a month."  This is our fully maxed out matchbook.

Once you have fully maxed yourself out, you can settle back at your desired state (see attachment book-max.gif) and be more productive than you have ever been.  No one said this would be easy.  Have the courage to see it through for at least 3 months.  You'll be a better person for it. 

Let me know how it goes.