Mitch Lacey & Associates - Scrum and Agile Training

When the Team Becomes the Product Owner

Sun, 05 Feb 2012 07:19:00 -0600

Jim was working as the business manager inside the company. He had years of experience and was a few years from retiring. Jim was working on a project with Michelle and he had been voluntold (told he would volunteer) that he was the teams product owner due to his rich expertise, background and knowledge on the business end of what the project was to deliver. We find Jim having a conversation with Michelle, where she is showing some frustration with Jim’s lack of involvement with the project.

“We’re doing Scrum” said Michelle, “and you’re the product owner!”

Product owner thought Jim? He had heard the term around the water cooler, and he had been skating by doing the job in a half-assed fashion, but now his real job was beginning to back up. It was time to do some homework.

After some digging, Jim discovered that the product owner role was a Scrum role whose primary goal is to ensure the vision that was asked for by the stakeholders/customers is being executed by the team and that he was now responsible for managing and representing the interests of the stakeholders and customers to his development team, who executed the work. He found that the product owner was responsible for working with the stakeholders to understand the functionality of the system under development as well as writing user stories and working jointly with customers.

“Great” he thought to himself, “more work.”

He kept reading and discovered the stories go into the something called a product backlog, an ordered and prioritized list sorted by business value and risk of the work needed to accomplish the project. It contained user stories and other things like bugs and various issues.

“Even more work” he said out loud. He began to wonder how to push this off onto the team. He went back to Michelle to share his concerns.

“Michelle, I’ve been thinking about this product owner role. I didn’t commit to the responsibilities of this role. My manager said I would do it because of my background. I don’t mind helping you out but I just cannot take this on at this time. I need you and the rest of the team to do this type of work. I’m far too busy. You know what we need to do this year so just make it happen and if you need anything critical, pull me in, but I need the team to drive this” said Jim.

Michelle was shocked.

“Jim, I don’t think you understand. You are best suited for this job. You have the experience, the background, relationship with the stakeholders, and you know how this thing should work. We need what’s in your head. You’ve been working on this for quite a long time. I’m worried that if we just come to you for critical items, we’ll end up building the wrong thing. Can we really afford this?”

“I don’t have time, do your best” said Jim.

The Problem

You might think this is isolated and uncommon, but unfortunately in today’s overloaded and understaffed businesses with multiple simultaneous projects, its reality. People are often “too busy” and can’t do their jobs because the business lacks the necessary slack in the system to allow for flexibility and change.

In the story, we have Jim who is essentially handing off his product owner responsibilities to the team (never mind the fact that he was not committed in the first place). We have the team who doesn’t have the insight into the business or the vision and has been tasked with moving the project forward. This is a recipe for disaster.

Jim, as the product owner, is responsible for managing the vision, keeping it on track in the form of user stories and keeping those user stories prioritized and ordered through frequent interaction with customers and stakeholders. Jim, as the business manager, has the industry and business background, and owns the relationships with the customers and stakeholders. By handing off this responsibility to the team, he is essentially signing both of their death certificates.

The team, working to please its product owner through frequent releases, working software and collaboration, has now lost its primary source of knowledge. Jim’s responsibility is to provide the team guidance and to answer questions when ambiguity arises around user stories, and that is now gone.

A Solution

I say “a solution” and not the solution because there is no single, all-encompassing solution to this problem. I see this problem more than you might expect and here is the advice I give to my clients.

Help the product owner/business manager understand their role. The product owner is a full time job, especially with projects that have a lot of change. The longer the project, the more likelihood for change. To read more about the product owner, click here
Discuss the impact of this decision. The decision to have the team become the product owner will end in failure. The impacts of this decision are

The team will build the wrong thing. Why? Because they don’t have the background or knowledge of the vision the way the product owner does. The teams focus is a shorter term technical focus, where the product owner holds the long term vision through active product backlog management and customer interaction.
The product backlog will become stale. When there is too much pressure in a system, something will give. The first thing I see give is the product backlog. The team will not keep it up to date, nor will they have the frequent interaction with customers and stakeholders like a product owner would (this is called grooming). This is because of the focus of the team – executing the project – not managing its scope and area of focus.
Money will be wasted. If you believe that these impacts don’t come with a cost, you are wrong. Time will be wasted, as well as money, and opportunity cost will be lost while the product owner is too busy. Meantime, team is struggling to build the product or service and trying to manage the stakeholders and product backlog (the job of the product owner), doing both poorly.

Track data. I’m a data guy. While my friends tell me I make impulsive “hunch” type decisions, I do so with at least 51% of the available data. If you believe that having the product owner push off his responsibility to the team is the wrong thing to do, like we saw in the story, complaining about it is not going to help. You need data. The things I capture are…

Velocity. You will see a significant drop in the teams’ velocity. This will directly result in a slippage of stories. Publish this data, and once you have three to six sprints worth of data, go back to the all-too-busy product owner and say “here is our new release schedule,” which should be much farther out than it was before due to the increased overhead in the team in doing both roles (team and product owner).
Customer satisfaction. This is a little harder. In your review meetings, ask the customers if they are satisfied with team performance and their delivery. Show them the velocity numbers and the projected release plan. If they are happy, the team is in great shape. Most likely, however, they’ll be a bit worried and/or upset with the performance of the team due to its increased overhead and the longer release schedule.

Business priorities. To me this is a no brainer, but for some it’s a huge challenge. I have clients that often have 20 or more “critical” projects that they need to deliver in a year and each project has equal priority. This is one of the main reasons people become too busy as the business cannot provide direction as to what is important and not important as they relate to company short and long term objectives. As a result, everyone tries to work on everything and practically nothing gets done.

That’s it. I hope you found this article of value. if you liked this post, check out my book, which is full of good tips like this.

Additionally, there are several resources you may find of value to help you identify/prevent this from happening.

Book: Slack by Tom DeMarco – read it and give it to everyone
14 day sprint timelines – print them out
Intro to Scrum section on this website, specifically

Even 3rd Graders are Project Managers

Sat, 21 Jan 2012 13:52:00 -0600

I was chatting with Mike Cohn Agile 2005 about user stories. He told me how he applies some of these techniques to his kids. This got me thinking - what is important to me, as a parent, when it comes to my kids homework.

I want to know what assignments are active, pending and complete
I want to know the measured quality of the work turned in and the time spent on each assignment.
I want my daughter to have a sense of ownership when it comes to her deliverables

I did not want to invent a new proprietary system in solving these. I thought to myself, if user stories work for the team at work, why not at home?

Required Tools

A cork board, hung in a public place where your child frequently visits (in front of the TV might just work for some)
Multi-colored 3x5 cards
Pencils
Thumb tacks or push pins

The Exercise

Every Monday (in our case, our daughter only gets homework on Mondays, so this is any day your child gets a new assignment) we have Ashley write down each of her homework assignments on a single note card. Different subjects get different colors, like red for math - easy enough.

Each card gets the following attributes

Assignment name
Estimated time to complete
Date due

Once complete with the assignment, she will add the following information

Actual time to complete
Actual date turned in
Grade (once provided by the instructor)

She is free to add additional items on the card, like where she found the information, how she liked the assignment, and so on. On the board, create three areas - "Queued (or pending), Active, Completed". This allows you (and her) to see what the backlog of work is, how much work your child has bitten off at any given time and how much work has been completed over time.

Sounds a bit crazy, I know. We want her to learn to be accountable her herself and to her work. We want her to see that the effort she puts in may not give her the grade she desires (quality and reward) and that next time she should work harder. This helps her realize that when she puts in 30 minutes to some work, does a crap job at it and then gets a poor grade, she is the only one she can cry to. We coach her along the way, but ultimately we leave what "done" means to her. Granted, we can coach a littler harder from time to time when she's off in la-la land.

You get the point. Try it out with your kids and let me know how it goes.

The Experiment

Wed, 13 Apr 2011 21:59:00 -0500

I wrestled with this on the train from Arlanda all the way to Stockholm Central. Got to the hotel, unpacked my stuff for the two nights I would be there and said “screw it, I’m taking a nap” – well this was at 1:30pm local time and I got up at 3:30pm. I spent the rest of the day wandering around the city, watched an England Euro cup qualifier and went off to bed at 5:30am the next day.

Feeling overly refreshed, I got up around 3pm and met my friend Robert (MS guy) and we went for what I would consider breakfast – he considered it a late lunch. It was 3:30 in the afternoon and I had been up for about 30 to 45 minutes. We went to a fantastic restaurant called Grill Ruby where I was able to get eggs – and a beer! It was my breakfast beer. Well, turns out having a beer when you get up from a night’s sleep is not the best thing. We wandered around a bit and I took a nap at 9pm for an hour. I got back up, went back to the same restaurant for a late lunch and then worked out in the gym.

This cycle went on for the entire five nights I was there. The hardest thing I found was to make sure I was sound asleep by the time the sun came up and next was to find food. On any given day, I would wake up between 2:30pm and 3:45pm – and I would go to bed around 5am to 7:30am. Most restaurants closed at 11pm or earlier, which was just about lunch time for me. To have dinner would mean I would need to stay up until about 6am to get breakfast in the hotel. Well, this does not work out that well with the sleeping before the sun comes up rule, so I’d often skip dinner.

This really was a fun experiment, one which I will do again. Wandering the streets at 4am in a city is totally different than doing it during the day. If you can manage your food intake, meaning it when food is available, you’ll do fine. Give it a shot, let me know how it goes!

TechEd Europe 2010 Recordings and Downloads

Sun, 06 Feb 2011 20:30:00 -0600

You can grab all sessions here:

http://www.msteched.com/Speakers/Mitch-Lacey

Here are links to my specific talks with slides and audio. Enjoy!!

http://www.msteched.com/2010/Europe/ARC208 - Architecture in Agile Projects – How to do it right

Architecture: Big design up front, or cowboy ‘design-it-as-you-go’ coding? In agile projects we hear that BDUF is evil. Does that mean that agile requires no architecture? Is there no more need for architects in agile projects? Neither could be farther from the truth. In this talk, Mitch Lacey, former Microsoft Program Manager, will walk you through a case study of one of his projects to show you how they architected a system that required 99.999% uptime and supported 5 million users – all while using Scrum and XP.

http://www.msteched.com/2010/Europe/ARC207 - Working Software is Not Enough!

The true measure of project progress is working software - or is it? Our team thought it was, and we were wrong. This is the story of our team, a team that set out to build a new order tracking system for a worldwide vehicle manufacturer and failed. So, what are the factors necessary for a successful project? In this session you will get insights into our team’s key-learnings on critical success factors - insights you can definitely use to ensure your project’s success.

http://www.msteched.com/2010/Europe/ARC206 - Scrum for Managers

The role of the manager in a software company is changing. No longer is it about driving people to achieve results. Now it is about enabling teams to be hyper-productive. But how can this be accomplished? Scrum, an agile framework, has been used successfully to build hyper-productive teams. What is Scrum? How can a manager build hyper-productive teams that outpace everyone else? In this talk you will hear exactly what Scrum is, its base components, and the traits required to help ensure success. Mitch Lacey, former Microsoft program manager will share his experiences helping teams adopt the Scrum framework. In the course of his work he identified four patterns that were present in teams that succeeded, but were absent in teams that failed.

Scrum: Adding the Fourth Question to the Daily Standup

Sun, 05 Dec 2010 06:03:00 -0600

On one project team, when we would do our standup, team members would answer the three questions with energy.

"Yesterday I finished the IAS web service and today I will begin adding the key tables to the new DB, no blocking issues"

We all knew what this meant, after all, we were all sitting right next to each other in the team room.

Near the end of the Sprint, however, things changed. People would still answer the three questions with the same accuracy and gusto that they had been all Sprint long, but they would grumble that we were not on track to meet our Sprint goal. I asked myself, how could this be?

What I noticed was that people were still uncomfortable with raising issues. We were a new team and none of us had worked together before.

I pulled out an old trick, a thermometer test. I first experimented with this in early 2005 and it's a tool I have been using ever since. Simply put, I introduced a new question into the Daily Scrum, which was....

"On a scale of 1 - 10, how confident are you that we will accomplish the goal of this Sprint?"

Now the issues started to surface. While people were not comfortable stating blocking issues caused by other team members, they were comfortable in saying "six" instead.

How to use this on your team

Add the fourth question. Let the team know what it means and what it is for. Then listen. If you, the ScrumMaster, notice a variance in the numbers, discuss it. It's that simple.

Here is an example:

Joe: 9
Mike: 8
Bill: 8
Michelle: 9
Sarah: 5

Whoa! a FIVE??? time to start probing.

Be Cautious

Be cautious - people may want to discuss their numbers in private. Encourage team participation. Let the strong personalities on the team know that they will need to scale back the "strong-ness" and let people talk. This is not a time for attacking, it is a time for building trust and comfort in the team.

How Long?

I see teams use this technique early on and, once trust and communication is established, it dies down.

Stage Producer 101: Building the Best Stage Possible

Thu, 01 Apr 2010 02:03:00 -0500

So you want to be a stage producer for the Agile conference? Great! This post is meant to give you a primer not only on how to get started but also on how to build a wonderful experience for the attendees.

You should skip this job if…

You are doing it for the money. (As I explained way back in my first blog post, stage producers get at most $1,000 plus hotel and free conference admission.)
You don't have a lot of time. (I find I spend about 100 hours just to get to the point where I send the accept/reject letters. At that point I have another 60 - 100 hours to go.)
You are using it as a way to build your business. My advice, build your business on your own time.

Why do the job?

Because you enjoy the challenge. Running a stage is like running a project. You have to build a team of people you like to work with, and others that can work together. You have to motivate people through leadership and communicate with them frequently.
Because you get to meet other people in the community that you might not otherwise meet.
Because, most importantly, you get the opportunity to give something back to the community.

Stage producers have to meet certain date milestones and have a firm grasp on what will happen when.

August - November: Build your team.
November - March: Review and communicate to the team
March - April: Acceptance and reject emails go out
April - August: You will need to do small things to get your stage ready
August: As the conference nears, things ramp up again

Build Your Team

Setting up your team is a lot harder than you think. I start out by sending an email to 10-15 people that I think might be interested. I ask people that I have worked with in the past and new acquaintances that I think might enjoy being a part of the review team. In 2009 I asked people to review at least 20 sessions each. Doing it this way did not work because we received more submissions than we anticipated. In response, this year I gave people a percentage of submissions for which they would be responsible. You can download the email I used to build my team here. (I should take my own advice: I sent it 17 Jan 2010 - a little late).

Reviews - Giving Them

Reviews are fun and quite challenging at the same time. When doing reviews, or having your team do reviews. Follow these guidelines:

Make sure there is a vision, a well structured outline, and clear learning objectives.
Give yourself ample time and do them without distractions. I like working in 45-minute blocks.
Provide actionable feedback.

Your review does not need to be a novel, but it should also not be one sentence (unless the submitter really nailed the submission and you're going to accept it).

Here are some examples of feedback that I used for Agile 2010:

"As other reviewers have said, there are a lot of things thrown about freely. On the surface this seems very good. In order to get accepted, however, it needs the sources to back up the claims."

"This feels like it has everything, which I view as a detriment. While attempting to cover a broad range, it feels like it lacks focus. Hone in on a specific set of items and drill them home."

Here is a piece of feedback I gave to a submitter (one of many) who submitted late and did not have a well-built submission.

"This submission lacks the detail necessary for serious consideration. If you are to run a 90-minute tutorial, you need to outline the timings in detail and expand on the exercises you will use. I have read the comments and feel that if you had submitted this before the deadline was approaching, it would have had at least one round of reviews and feedback with the review team, allowing you to adjust the submission. In its current form, I cannot advocate it for the conference this year."

I will always give a review over a comment as it allows me to get a picture of the program as it's being reviewed. I instruct team members to provide comments in the review and put in a recommendation (accept, maybe, reject) and use this data to manage the stage.

Reviews - Managing Them

The submission system, as built today, is not a very good tool for managing reviews. As a result, I use google docs to keep track of how the reviewers have rated individual submissions. I import the submission titles, ID numbers, and reviews and list them out like this:

The count is the number of team members that have reviewed the submission. Each reviewer gives each submission a numerical value of 2 for accept, 1 for maybe, and 0 for reject. These individual ratings are then averaged out. As you saw in the email, I like to have all reviewers review at least 75% of all submissions. This is to ensure that I get at least four, ideally five, reviews per submission. The conference committee only requires three; but I like to have more eyes look at the submissions.

Once the submission system closes, we go back one last time, review all of the stragglers and any updated comments from the review that we missed and solidify the plan. For our stage this year, this was done about five days after the submission system closed. A week later, we had a team conference call to discuss any submissions on the edge of accept/reject. We had about eight to discuss; two were promoted to accept. At this point the review team’s job is done.

Post Acceptance

As of today, 31 March 2010, we are in the accept/reject phase. Acceptance emails went out on the 30th of March and reject letters will go in a week or two. Why the delay? Because not all the people who were accepted will be able to go. We give people 7 to 10 days to confirm. If they don't, we move onto our backups. Once we’ve heard back from all of the submitters, the reject letters go out.

The Conference

Jim Newkirk, conference chair for Agile 2010, instituted some new rules that I think are wonderful. First, stage producers and assistants must open each session on their respective stages, introducing the talk and the speaker. They are not required to stay for the session, but they must collect the feedback at the end of each session and build a report in real time on how the stage is doing based on the scores for the sessions that were accepted. This report is given to the conference coordinator, Jessica, to build into a larger report. The chair will then write a larger conference report to submit to the board at the end. All of this is kicked off by the conference retrospective on Sunday, which all producers are required to attend.

In Closing

All in all, I find working on the conference very rewarding. Because I have done this for many years, I have worked out most of the process bugs for my stage. Every producers approach is a bit different, but in the end, we are all working towards a single goal - build the best conference program and experience we can.

Your takeaway : I encourage you to be a stage producer, but only if you are doing it for the right reasons and you have a firm grasp on the commitment you are making. Though the process isn’t perfect, every producer and every review team is working hard to create the best possible conference. If you have any suggestions on how we could do better, please send them to me. I’ll pass them along at our August retrospective.

Agile Conference Stage Reviews: How it Works

Thu, 01 Apr 2010 02:02:00 -0500

If everyone did his or her part, the stage review process would work very well.

How it Should Work

Submitter gets submission in early
Review team provides feedback inside the conference review system
Submitter gets notified and updates submission
Review team gives it a final pass just after the submission system closes
Stage producer builds program
Accept or reject letter goes out

Unfortunately, in the four years I've been doing this, I’ve found that things don’t always go that smoothly. It starts with a flood of late submissions, many incomplete, and ends with overwhelmed reviewers who cannot respond within the review system.

How it Really Works

Submitter gets submission in just under the deadline
An overwhelmed review team reviews the submission, inside or outside the review system
Submitter gets notified and may update the submission
Stage producer builds program
Accept or reject letter goes out.

This year was no exception. The vicious cycle began when most of the submissions came in all at once. This in turn caused many review teams to push through a lot of submissions very quickly (this is why your first impression is so important—see blog post 2). The rapid turnaround time and volume, then caused some stage producers to bypass the review system to do the reviews.

Why is it that such a bad thing? Simple – it breaks the feedback loop. How is a person to know how his submission is doing without comments or reviews? As I write this, acceptance letters are going out. At the same time, there are submissions remaining in the system that have no comments or reviews. Transparency and a feedback loop are essential ingredients in a fair submission review, yet we have submissions with zero feedback. It’s bad for the submitters, it’s bad for the reviewers, it’s bad for the producers, and it’s bad for the conference. People do the best they can, but when the process breakdown, the system fails.

Your takeaway. You can help make things work the way they should.

Submit your talk early
Email your stage producer
- Ask them directly if they are using the submission review system
- If they are not, ask them how they will be giving you feedback and what the update mechanism will be

I’ve given you a good idea of the reality of the submission process and what you can do to give your presentation the best chance of getting accepted. My next blog post will show you the other side of things: how to be a great stage producer.

Getting your Session Accepted to the Agile Alliance Agile Conference

Thu, 01 Apr 2010 01:57:00 -0500

The following three factors are crucial to a successful submission for the Agile Alliance Agile Conference:

Structuring your Submission
First Impressions are Critical
Timing is Everything

Structuring your Submission

Too often I see submissions that lack the basic elements of what the author is trying to communicate. This has everything to do with timing (see below). Your submission should follow the following guidelines:

Have a good title. Yes, we can rework the title later but, remember, this is your first opportunity to make a good impression. If it grabs the reviewer, it'll grab the attendees.
Have a well thought out introductory paragraph that tells attendees why they should come to your session over others. Consider having a short call to action in this section and a problem statement.
The process and mechanics should tell the review team, as well as the attendees, how you plan on spending your time. Can it change? Sure it can. Should it at least be complete? You bet. This section should include the timings of your session and how you will use the time. Don’t skimp on this part; it should be the meat of what it is you want to do. Additional items to include in this section are
1. Audience. Understanding who your primary audience is, and communicating it, is key to a good submission. People need to understand why they should come to your session and why it adds value. Sure, you are listing if it is introductory or expert as a checkbox, but I look for additional details here, like, "this session is targeted at senior managers inside the company who want to introduce XP and Scrum but are not sure how to get started."
2. Presentation Format. Yes, there is a dropdown that allows you to check tutorial, talk, workshop, etc, but you should still consider weaving a description of your format into this section of the submission. For example, a piece of text from a tutorial session that was accepted says "I’ll start with an introduction and purpose of the game, then explain the rules and show an example of how to play. They’ll have one hour to complete the game." This tells me a lot and I can see how the game will roughly play out.
3. Presentation Delivered Before. This is one of the things I consider a best practice. I think it's pretty straight forward - have you done it before or is it new? If you have done it before, provide a link to a video or some piece of detail where the review team can read about it. If it's new, call it out. I like new things.
4. References to Your Speaking Ability. I know how this sounds, but remember, this is a volunteer effort. These volunteers vary from year to year, so even if you’ve submitted something before, not every reviewer will be familiar with your speaking style. Having a couple names that people can follow up on is beneficial. Having references might be the difference between one submission being accepted and another being rejected.
Learning Outcomes. Good learning outcomes list what people will take away - e.g. "Learn that effective and efficient meetings are focused strategically, tactically or daily - not all mixed up." Bad ones say things like "get an understanding of agile" or "learn new coding techniques." Reviewers and attendees cannot make a determination on so vague a description.
Your takeaway: Have a clear vision of what you want to present, lay out the benefits to attendees of coming to your session over others, highlight why your session is valuable (through data or other means) and tell us, if you have presented it before, what you have learned and what you will do to improve upon it.

First Impressions are Critical

I cannot stress enough how important it is that your submission looks well thought out and organized at first glance. If your submission exhibits any of the following characteristics, you're in a hole before any of us have even read the first word:

An overall submission that is less than 10 sentences
- A process/mechanics session is five or fewer sentences.
- An intro that is five or fewer sentences
An introductory paragraph is bland and does not relate to the conference.
Learning outcomes that are light or non existent

How can the review team understand what the structure of a 60 or 90 minute talk will be when the submission says, "I will be giving a 60 minute talk with time for questions. We will do one exercise." Compare that to a submission that illustrates, clearly, the vision, the goal, and how the session will flow. Which one do you think we will choose?

Your takeaway: You are guaranteed that the review team will look at your submission once. Make that first glance outstanding.

Timing is Everything

In real estate, it’s location, location, location. In conference submissions, it’s timing, timing, timing! The submission system for Agile 2010 was open for 52 days. Nevertheless, 80% of the submissions were added in the last 14 days. What does this mean to you? Everything!

If you submit early, you are all but guaranteed (at least on my stage) to get one actionable feedback loop with the review team. Simply put, if you get it in early in the process, we have time to review it and are very likely to give you feedback via comments. Because you submitted early, you may be able to revise your submission based on our feedback and resubmit, thereby increasing the likelihood of your talk being accepted.

On the other hand, if you wait until the last minute to submit, your submission is more likely to get lost in the noise. Due to the sheer volume of submissions we receive during the last few weeks, reviewers only have time to give each submission a quick read and form an impression as to whether it’s worth a second. If it’s too short or too vague, the reviewer will likely write "not enough information" and move on. That's it. Even if you are able resubmit or provide more information before the final deadline, first reads will get priority over revisions, so the team may not get back to yours before the system closes.

And don’t send us your submission at the last minute with placeholder text where the details should be. We will not be impressed by notes that tell us you will update your submission on a specific date via comments. In fact, when we come across such submissions late in the process, my stage team throws them out. Comments exist so that you can clarify what is already in the submission. They are not a replacement for the submission itself.

Your takeaway : Get a complete submission in early if you want to increase your chances of it being accepted.

I’ve shared with you several ways to increase your odds of getting a session accepted at the Agile Alliance Agile Conference. My next blog post gives you a behind-the-scenes look at how conference stage reviews work.

Agile Conference - A Stage Producers Story

Thu, 01 Apr 2010 01:54:00 -0500

The Agile Alliance "Agile" conference has become the preeminent event for our community each year. It boasts, on average, 1500 attendees and this year received nearly 1000 submissions. Organizing this is no small task.

This post is meant to share with attendees and submitters alike what my experience working on the conference for the last four years has been like. My next three posts will show you what it is my teams look for in submissions, how we make decisions, and more.

I have broken the posts down to these three areas:

I have been working on the conference for four years. In 2007 I was a reviewer and shepherd for the Experience Report (XR) track. In 2008, I worked as a team member for the Leadership & Teams stage that was being run by Johanna Rothman and Mike Griffiths. Along with Pollyanna Pixton, the four of us made up the team and reviewed 150+ sessions. In 2009 I picked up the Stage Manager role for the Organization and Culture stage and this year I am running the Leadership and Culture stage. I have submitted papers each year and have had some accepted and some rejected.

Despite what you may have heard, working the conference is a paid position for only a few people; most who dedicate their time to the conference are volunteers. Even those who are paid aren't making a living off the money. Stage producers in 2008 (if I recall correctly) received $10,000. For 2009, the number went down to $250 because we wanted to ensure we had more money to get good keynote speakers (among other things). In 2010, the stage producer is paid $1,000. In addition, each stage producer is given free conference admission and hotel nights. Prior to the conference we build the stage program. While at the conference, we are expected to introduce each session, with the help of our assistant producers, as well as attend the conference retrospective, write up a report on our stage and to handle the feedback and survey data. Assistant producers and reviewers are often never compensated and dedicate countless hours of their time to helping review hundreds of sessions. My team this year and last year were invaluable. It is truly a labor of love and a way to give back to a community that has given so much.

With that out of the way, it’s time to share with you what my team looks for and what a good submission looks like. My next blog post will deal with ways to increase your odds of getting a session accepted at the Agile Alliance Agile Conference.

How does Scrum Help the Individual?

Sat, 09 Jan 2010 10:34:00 -0600

In November, 2008 there was a discussion on the Scrum Development yahoo group about how Scrum benefits the individual, and why anyone would want to work on a Scrum team. Here is what was asked:

What does Scrum (or other Agile umbrella method) offer to an individual seeking improvement?
I realize that TDD helps one improve one's skillset and so do some of the other Agile practices.
But, specifically to Scrum, which practices are intended to address individual achievement/improvement?
The reason I ask is because teams have stronger and weaker members and would like to know both what the team can do to help the weaker embers and what the weaker members can do to help themselves. While till attaining/maintaining a high velocity, of course. Preferably without overtime.

This got me thinking, what are the values and benefits? It turns out it was easier to answer than I thought. I had been saying these things for years, in workshops and on teams. Here they are:

People who work on Scrum teams will have the opportunity to improve/practice/polish/learn/grow in the following areas

Technical skills (any) by working in a collaborative space, hopefully pair programming
Interpersonal skills through daily conversation and human interaction
Presentation skills by having to show working software every two to four weeks
Relationship skills by having to work with people you may or may not especially like
Leadership skills by teaching others your unique perspective on how you have solved problems in the past
Self confidence by going out of your comfort zone, stretching yourself and growing
Self awareness by understanding what actions, or inactions, your decisions have on others and the system you are building
Communication skills, both verbal and non-verbal, through daily standup meetings, pair programming, customer demo meetings, sprint planning meetings
Estimation skills by having a better understanding of the whole system through the practices of collaborative estimation and collective code ownership
Continuous improvement by having the discipline and trust in your team to allow the items above to become a reality

I use this list when I meet with new teams that are adopting Scrum. Try it out and let me know how it goes!

Microsoft patterns & practices Team Space

Tue, 17 Nov 2009 01:33:00 -0600

Many people ask me about team spaces and how to set them up. Not long ago, colleagues Ade Miller and Ajoy Krishnamoorthy did a walkthrough of the Microsoft patterns & practices space - it is built around agile teams. When watching this video, consider that this team started out in a two person office with 6+ people crammed in it. From there, they began booking conference rooms, one room per team member per day. They were told they could not do this, so they got creative and started booking random times to ensure the conference rooms (aka team space) were always available. This went on for a couple of years before facilities asked what they needed to stop the madness. This video shows you the end result of a team room.

Click here to see the video on MSDN Channel 9.

SQE Agile Dev 2009 ScrumBut Tutorial

Thu, 12 Nov 2009 14:07:00 -0600

What is a ScrumBut? As originally coined by Eric Gunnerson in 2006, he wrote:

ScrumBut: the words of Scrum, the actions of waterfall.
"We're doing Scrum but..."
- our sprints are 12 weeks long...
- we do two normal sprints and one bugfix sprint...
- we do all our planning up front...
- we skip the daily meeting...
- our managers decide what's in each sprint...
- we haven't read the books yet...
- our team has 30 people...

The original idea behind the workshop was to break into three groups, having each group come up with their most common ScrumButs. When we did our group introductions, we discovered that everyone had multiple ScrumButs. In true inspect-and-adapt fashion, we quickly realized that the original approach would not yield as much value as the one that was emerging, so we quickly documented the list the attendees generated.

We had quite a list to work through! We prioritized the work and divided each item into twenty minute sprints and we were off. Here is a summary of each item.

Documentation in Agile

There is a common misnomer that “agile means no documentation” which could not be farther from the truth. In our findings, we discussed what the right documentation is and how to get there. Most importantly, people need to focus on not just documentation, but the right documentation at the right time. For more information on this, please see my Learning Scrum article titled Defining Done.

Big Design Up Front

The next item we discussed was big design up front. Several people were dealing with situations where architects were pushing down designs not early but late. As a result, the time and money invested in these designs was not fleshed out but they were often implemented due to the investment made. We discussed how much architecture is the right architecture and how to build and deliver working software at the end of every sprint with architecture emerging over time. We found the correct amount of architecture for our group to be planning two to four sprints out, with more attention focused on the near sprints and less on the far sprints.

Scrum Teams Working with Traditional Teams

This was a common problem in our group. We did not spend a lot of time on this but what we did discuss was how to build mock objects between our application or service and the other services that need to be integrated. We do this so we can have stability in our system while the other teams build their architecture and services. Scrum teams cannot wait until “everything is done” – the behavior of traditional teams – and we found this approach to work best.

Selling Scrum to Management

The biggest part of selling to management (and customers) is to help them realize that change is common in software projects and that it is nearly impossible to predict the future of time, scope and money. We walked through the building of the Stacey Uncertainty Matrix (below) on a way to help people understand the amount of change that is common in most projects. Scrum is ideal for projects that are complex and less so when they are simple (because we just know what to do!).

Sabotage

Participants had problems of sabotage on their projects, where people were knowingly or unknowingly derailing the project and the team. We discussed ways to deal with this and with rogue team members.

Relinquishing Control

This was a big one. There was a common thread with people where others had a hard time letting go, thinking they needed to control what people did, how they did it and (sometimes) when. This conversation on leadership lead to a discussion on what we can do to help make leaders in our companies, specifically on how we can deal with “the guy” who is always called on to save the day.

Offshoring and Distributed Teams

This topic was a bit short due to the time. The main topics we touched on were planning on a lot of travel, ways to build teams locally for three months and then transplant them to their new location, using technology like webcams and phones to help open communication channels, have a single-team mentality and ways to stay focused (e.g. the removal of IM and email).

In Closing

Thank you to the people that came to this workshop and made it a great success. Both Cory and I had a blast! You can download the photos here.

Scrum for Managers

Mon, 09 Nov 2009 13:23:00 -0600

I had lunch with my old general manager and friend at Microsoft recently (his name will remain anonymous). He told me he is building a new agile and wanted to know if I knew of any developers that would meet my criteria that were looking (I have a high bar). I said I knew of a few and asked him how his current people are responding to him looking for more agile focused people – specifically what he is doing with his “lead developers” – the people that are one level up from individual contributor and typically have three to five direct reports.

“I set them straight by saying I hire leaders not managers and I expect leaders to lead and do work” he said. We continued our conversation and where the issue lied was that there was a sense of superiority with a couple of the leads – a sense that their job was now to manage people, to direct them, manage their time and monitor their progress as it pertains to development tasks. This was the complete opposite of what my friend was looking for and these development leads were having a hard time doing actual work.

This then takes us to Scrum – what is the role of a manager is Scrum? My last eighteen months at Microsoft were spent helping teams get started with agile principles and Scrum and XP practices. Through this and working with companies since leaving Microsoft in late 2006, I have come to notice management behaviors that are absent in the teams that fail and present in the teams that succeed. Let’s look at them now.

A Common Set of Principles:

First, the managers that had the successful teams clearly understood the agile principles and values and were able to distill these values to their people. People were aligned and understood why they were working the way they were and they understood the vision and goal of the entire organization. The why is extremely important because without the why, all that is left is the how and the how can be quite confusing without knowing why you’re doing it. The vision and goal is equally important as it creates a rallying cry, giving people the knowledge needed to do the right thing and to solve problems without asking higher power to make the decision for them.

Multitasking

The next thing I observed is that teams were able to stay focused. As I investigated, I found teams that were working on one project and one project only – full time – all day long. The teams that failed were always working on multiple projects splitting their time. This was fascinating. The teams that were dedicated to one project were able to not only deliver faster due ot the elimination of switching costs but were also significantly happier. Further, due to having a common set of principles and values to work from, these teams were able stay extremely focused and deliver systems that always delighted the end users. The teams that were multitasking across projects often lacked the vision needed to delight the end users and, as a result, more projects were needed to fix that problem, creating a never ending cycle.

Rewards for Failing Early

Performance reviews are all about how a person does against a set of goals or commitments. When people fail to meet their goals, they are often penalized. If people accomplish their goals as expected, they are rewarded and if they take a risk and succeed, they are rewarded greatly. The problem is when people take a risk and fail. When this occurs, they are often penalized with no reward and a perception that they are failures, at least in the short term. As a result, people seek work that is in their comfort zone because it is the safe bet for success. This behavior limits growth opportunity and creates a company based on strict functional roles, not cross functional teams.

Failing Early

How I have seen managers get around this is by rewarding for failure, but only if it happens early. Failing late is not acceptable. In this model, people that stayed in their comfort zone received a minimal reward – say a base cost of living increase. People that took risks and failed were given the average reward and people that took risks and succeed were given a high reward. The difference here is the shift from staying in the comfort zone. This builds complacency and does not create a learning organization, neither does negative reward for failure. This model allows people to learn from their mistakes early, when the impacts are low.

The other thing that this shift does is drive innovation. When people are taking risks, they are learning and when they are learning they are often innovating. Everyone in software wants innovation and creativity, and the enlightened manager will realize this and shift the reward structure to enable it.

Protection and Transparency

Too often I have seen people get filleted by customers or senior managers while their own managers stood by and let it happen. This spineless behavior drove teams into their comfort zone. However, for the managers with a good understanding of why (going back to the values and principles), they understood that this was unacceptable behavior and would not only defend the teams but would often shield them entirely, allowing them to stay focused on innovation and delivery while they played the political games that plague our companies.

Providing this protection was dependent on transparency. The teams who were open, honest and truthful about their projects gave their managers the ability to provide the protection they required. The teams accomplished this by having daily reports (burndowns), regularly scheduled demos at the end of each sprint with everyone invited and a common definition of done so that there was no question at the end of the sprint or a release if the teams were “really” done. What was most important, however, is that the teams highlighted both their success and their failures. This builds trust among management and the customers.

Accepting Transition Costs

We have all learned how to ride a bicycle, yet when we first started we were not that good. Our parents did not yell at us and tell us we were worthless, instead they guided and coached us until we were able to understand the basics of balance and motion on our own so we could learn and grow our skills.

Too often I encounter managers who have read about Scrum, often hearing about teams and companies that were able to achieve greater results, higher quality and be faster to market while spending less. They then believe that if they implement Scrum that the benefits that may come with it will be theirs. All they need to do is get buy some books, get people trained and voila! the cure to all their problems!

Unfortunately, like learning to ride a bicycle, adopting and doing Scrum takes time. Doing it overnight is not acceptable and will cause more problems than it solves.

In my observation, most (e.g. 80%) teams can be off the training wheels in three months and can be an entry level racer at six months. After a year they may be achieving output that is five to ten times greater than their original output.

In Closing

It is the managers job to allow the team to learn and grow on its way to greatness. First is to understand that this curve exists in life and next is to understand the items written above. Failing to do so will likely result in a bad Scrum implementation and will all but certainly guarantee failure.

I give a talk on this subject on a fairly regular basis. You can download a recent slide deck on the resources page.

Agile Adoption: Structuring and Building an Agile Team

Thu, 05 Nov 2009 10:56:00 -0600

Colleague Jean Tabaka posted a question recently that asked "How we can motivate these people as much as possible before having them leave the newly anointed agile organization?" The context around this question is that there are people who are viewed as hero's in organizations. These individuals "are very specialized individuals with knowledge outside just the software development realm (physics, mathematics, fluids mechanics...) These individuals are used to being highly prized for their very specific subject expertise. They have a sense of significance hooked onto their unique role."

This poses an interesting challenge to Agile teams, where everyone should be cross functional, working towards a common goal. What if you do not need the hero gal full time? What if you need a designer, but only for 10 hours a week? Are these people core team members or what?

I left Microsoft in November 2006 to work at a consulting company, Ascentium. This gave me the perspective I was looking for to answer these questions.

We have people in our company who fall in the hero bucket, but I prefer to call them "Team Consultants". We also have people who do not fall in the hero bucket, and I call them "core team members"

Team Consultants:
What is a consultant to the team? Simply put, these are people that choose to work in a consultant capacity. They are not core team members, but instead are internal “guns for hire” to provide the team with what it needs to get its project done. Consultants work for multiple teams. Yes, the consultants are hired by the team itself. People in this role are typically very specialized. They would not be a good core team member because they are so specialized. They get bored with the work and derail the team. People choose to be a consultant or a core team member. Team Consultants may be booked full time on a project, but not for the entire lifecycle of the project. They will come in to solve an immediate problem or be booked out for a limited number of hours per Sprint, iteration or cycle. We have a person in our company who is great at ETL and cubes. He chooses to be a consultant. He spends 8 hours a week with us. He also spends 20 hours a week with another team.

Core Team Members: The core team is just that, the core team members that are dedicated to the project. They collectively own the work. These people are cross functional and fully dedicated to the project - read - no multi-tasking BS. An example of this happened in my current project recently. We are building a winforms application that talks to a big backend and integrates with 6 systems. We needed to create a user interface for our system and, frankly, had no idea on how to do it. We hired an Information Architect and a designer to guide us through the development of the UI. They coached us on how to interview our customers from a UI perspective (we are all good at the backend stuff, but not the front end). In return for their services, we “paid” them with billable hours. They are happy, we got what we needed without having the specialized person dedicated to the team. We were able to buy time at 5 hours per week over a 6 week period and it worked out great.

Deciding Who Does WhatPicking who is a core team member is not up to management. It is up to the person. So if you're a manager, welcome to the world of empowering your people.

I'll update this post with pictures and I develop them over time.

A Messed Up Interview Question

Sun, 18 Oct 2009 07:52:00 -0500

Here is a messed up interview question that I like to ask when I have at least 1.5 hours with people. Sovle it now and you've got a job!

1 0

1 1 1 0

3 1 1 0

Solve for this line

The History of the Agile Manifesto

Sat, 17 Oct 2009 20:16:00 -0500

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.

Scrummerfall - Mixing Scrum with Traditional Software Development Methods

Tue, 13 Oct 2009 20:37:00 -0500

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.

Breaking the Rules of Agile - Working Overtime

Sat, 03 Oct 2009 20:11:00 -0500

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.

Film Cameras are Prescriptive, Digital Cameras are Adaptive

Sun, 26 Jul 2009 18:08:00 -0500

In 1996, I worked as the assistant photo editor for the Daily Aztec, the San Diego State daily newspaper. I had just come home from Atlanta where I had a store selling officially licensed Olympic landfill (shirts, hats, mugs, etc) and I had some extra cash, so I bought a Canon EOS 1 and a 1N – both film cameras. The majority of my work was sports photography. My press pass provided me special treatment at Qualcomm stadium (formerly Jack Murphy Stadium) where I was able to shoot the Chargers, the Padres and the Aztec football games.

As I aged, got married and had kids, I found that I wanted to do more portrait photography, so I invested in lights for my film cameras. I found that I spent hours setting up the shot. I used all tools I had available to me: light meters, reflectors, umbrellas, drops – you name it I used it. Considerations had to be made with regards to film speed and the compositional elements of the picture. I knew my kids would not sit still so I had to spend this time getting everything just right.

I’d shoot several rolls of film and get it developed, waiting in eager anticipation of how the shots would turn out. Sometimes I was happy, sometimes disappointed. I was able to look at the pictures and see where I made errors in my setup and if I wanted to make changes, I would now know what changes to make to improve the shots. The problem was that the studio session was over. I packed up all of the gear and put it away for future use. I never remembered all of the tweaks I needed to make for my future sessions, so the learning curve was very slow. The feedback loop – the stimulus to response time – was too long, and I didn’t want to invest in a very expensive Polaroid back for my cameras.

When Canon released the EOS 5, the first full frame “reasonably” prices digital SLR, I jumped.

We have all become accustomed to digital cameras now. What drives us to them is their ability to provide us instant feedback. When I use the EOS5 for shooting now, I can test my setup with my subjects, making small incremental changes to the setup to make the shot the best it can be in real time. Gone are the days of planning and spending hours with the meter. Instead I can quickly erect the lights, meter it and snap some test shots – and adjust based on the feedback the camera gives me.

The process of setting up and getting everything “just right” so I could snap the pictures was, and still is, an expensive endeavor. What the digital camera has allowed me to do though is to reduce the cost. The old process:

Setup – 4 to 6 hours
Take pictures – 20 to 30 minutes
Waiting time to develop – 1 to 2 days
Study pictures and review camera settings – 4 hours
Take notes to improve next set of portraits – 2 hours

Now, the time I need to execute the process is dramatically lower due to the instant feedback the digital camera provides.

Setup, iteration 1 – 1 hour
Test and review – 5 to 10 minutes
Refactor setup, iteration 2 – 20 minutes
Test and review – 5 minutes
Refactor setup, iteration 3 – 10 minutes
Take pictures – 20 to 30 minutes
Take notes for future sessions on current settings – 30 to 60 minutes

So how does this apply to software? I’ve had many tell me it doesn’t and I think it does.

Traditional development approaches are like using a film camera. The setup must be done right – or as close to right as possible – because snapping the photos need to be perfect the first time around. Not until the film is developed do we have a feedback loop, and often it is too late to make changes at that point unless the customer wants to spend more money. Costs are high and the feedback cycle is long and the photographer is constrained by what film is in the camera.

Empirical (agile) development approaches are like using a digital camera. Digital cameras are adaptive. They allow the user to change film speed (ISO) to any condition. They have the ability to review the environment and provide users (or customers) with real time feedback. That feedback is used to make small adjustments to the camera or the environment that is being photographed. Applying this approach to software means that customers are able to provide feedback to the application under development, allowing the team to make small adjustments to ensure what is being delivered is what the customer wants. The cost of change in this model is small and the feedback loops are fast.

In photography, not every scenario calls for a digital camera. Some subjects require large format film bodies to give the photographer the desired result. The same applies to software. If a team finds itself doing a project that is similar to one is has done hundreds of times, it may be that a different approach is required. Just as digital cameras are not the end-all, be-all solution to photography, agile development is not the end-all, be-all solution to software development. If, however, you are developing a system and you find that the technology or the requirements are far from certain, requiring, multiple and quick feedback loops, agile is the right fit for you.

Innovation Games Course Review

Fri, 10 Jul 2009 11:18:00 -0500

I’ve taken a lot of workshops, sat through a lot of presentations and done a lot of conferences, but this class was the best class I’ve taken in the last five years, hands down. There were several factors that made it great – the presenter, the content and the applicability to the real world.

The Presenter. Luke is a wonderful instructor and his energy is out of this world. He is a straight talker and, while I had never met him before this, we hit it off. If you have not seen or heard Luke present, you will be in for quite a treat when you do.

The Content. This was the focus of the two days. We broke into teams and Luke presented us with case studies. We had to determine what games would fit the case study and why. I was a bit overwhelmed on the first day as I did not prepare (aka read the book) as well as I should have, but by the second day, I picked it up and was off to the races. The games that stood out the most for me were Speedboat and Product Box. I had done Product Box before, but the twist Luke put on it was for us to make a box for our “perfect customer” at the customer superstore. I will begin factoring this into all my project and training work moving forward, tossing my old version of Product Box.

The Applicability. Since leaving the class, I read the book digested what it meant to me and did some research on how others are using Luke’s material. My conclusion? This is great stuff that will help drive out issues, problems, solutions, ideas – you name it – to help product development be better. Luke has some high ambitions for the games and I’m beginning to think how I can apply them to everyday life, outside of product development.

In conclusion, go take this class from Luke. Buy his book, Innovation Games and use the material. It is truly amazing stuff.

Also, be sure to read Luke's interview from the Wall Street Journal!

Running a Productive Daily Standup - Scrum Meeting

Tue, 10 Feb 2009 13:40:00 -0600

The daily standup meeting, or daily scrum, often does not get the respect it deserves. Done correctly, daily standup meetings keep everyone on the same page for the daily deliveries and moving as one toward the sprint goal.

Productive daily standup meetings can be a challenge for some. If a team strays from the strict three question and answer format, they soon will find that they’re spending far too much time talking and not enough time doing. Common obstacles teams run into include:

Should we do a deep dive in the meeting?
What do we do when people show up late?
What if one person constantly dominates the meeting?
We can’t get our meeting done in fifteen minutes. What do we do?

Solving these all-too-common problems is essential to running a productive daily standup meeting. Let’s take a look at a story about an ineffective daily standup, discuss what went wrong and how to fix it, then find ways to ensure that your team’s daily standup becomes/stays productive.

Download the PDF - please provide feedback.