Thursday, November 27, 2008

Agile Turkey Day...

Last year my wife decided to be ambitious and host Thanksgiving for her family at our condo. I thought this was a bad idea based on our small place and having two new kids to deal with, but I accepted responsibility to clean the condo from top to bottom so she could focus in the kitchen.

Preparation went pretty well, she even made many dishes in advance. But the one dish you have to cook on the day of the event is the turkey itself. (Well, you don't have to, but part of thanksgiving is stinking up the house with the bird.)

Unfortunately this was the day the oven thermostat broke, meaning it couldn't hold a steady temperature. We didn't realize it until the turkey should have been done and the thermometer said it was still a few hundred degrees off.

It quickly turned into a scrum process:
  1. Check the bird's temp
  2. Estimate a new time for when it will be done
  3. Wait the the oven to work its magic
  4. Repeat
Every time we did this, our estimate became more accurate, but the oven became worse at holding the temperature (and our constant opening and closing of the door didn't help).

Several hours late, we finally took delivery of the bird and ate our meal.

Customer feedback: That was the moistest turkey ever. Tasted awesome. Was ALMOST worth the wait.

Hope your and our Thanksgiving are going better this year. Happy Gobble Day!

Wednesday, November 26, 2008

Best day of week for sprint boundaries...

Chris Spagnuolo asked the Agile Linkedin group about the best day of the week to set sprint boundaries.

Some interesting points were made by the group including:
  • Mondays are sometimes focused on fires and recovery from the weekend break
  • Fridays are prone to people losing focus and being worn out
  • Vacation and holidays more frequently cover Monday and Friday
  • If a sprint ends badly on a Friday, people might feel pressure to work the weekend
  • If a sprint ends well on Friday, then the weekend is a clean slate
  • Sprint planning and review activities are a nice break from work and therefore work well on Fridays
  • We can't control a lot of this anyway
Pick your poison!

Tuesday, November 25, 2008

Non-Functional Requirements...

If you haven't heard, there's been some buzz about non-functional requirements in both the community (InfoQ) and from the experts (Mike Cohn). I'm also seeing some activity in the Agile Alliance LinkedIn group.

Monday, November 24, 2008

Agile Risk Planning...

I'm going to oversimplify a lot of things in this post. I'm doing it for two reasons... it's not the most interesting topic, and I'm really just trying to throw out a very basic solution to what can be a very complex process. Many environments don't even do risk management, so my theory is that something light covering 60% of your needs is better than nothing at all.

What do we know about Risk Management?

Well, we are supposed to do our best to anticipate what might happen and mitigate it. The best way to do this is:
  1. make a list of all the bad things that make you lose sleep (or just worry you)
  2. assign a probability of each happening
  3. assign a cost of impact if they occur
  4. multiply all of the probabilities by all of the costs and get a total cost
  5. put that money in the bank (or time padding on the project plan) to protect against it
  6. constantly manage the list to your best knowledge
  7. make decisions about how to spend resources to mitigate or remove risks (if you can do this for a fraction of the cost of it actually happening)
Your approach to this could be very scientific, thorough, and accurate... or you could just make some quick gut calls.

What is the agile solution I propose?

First, I believe that the amount of time needed to be invested in this process to make it very accurate is an amount of time and resources that most teams don't have. This is the same issue as estimation for stories and tasks in agile. There's a reason we do poker planning, and it think it might apply here.
  1. Let's start with the basics... have the team spend a few minutes each release (every few sprints) brainstorming risks with the guidance of a PM and the PO. The PM, PO, and Scrum Master should have already pre-seeded the list to speed things up since this isn't the main focus for the team.
  2. Now assume the risk will occur. Have the team estimate the impact of the risk using the same scale you estimate stories by.
  3. Using poker planning, assign a probability of each happening (but use a scale of 1%, 10%, 25%, 50%, 75%).
  4. Multiply each of the probabilities by its corresponding cost and sum for a total cost. This is your risk budget.
  5. Here's where I assume you have an electronic version of your backlog (be it excel, or a tool like VersionOne). Add a story to the bottom of your backlog called Risks. Under it, create a task for each risk. Put your total risk budget as the story estimate.
  6. Go.
Your system should include this story in any projections it makes for the burndown chart... so now you have that buffer built in to your projected product backlog. You have hedged your bets against the risk odds, and your are reasonably protected without being overly protective.

Responsibilities moving forward:
  • Management is responsible for keeping this list up to date. Add/Remove risks as appropriate.
  • Any work that can be done to reduce or remove items in this list at a fraction of the cost of the risk occurring should be pursued.
  • The team should re-estimate both probability and impact cost periodically based on their updated knowledge (this supports the cone of uncertainty philosophy)
That's it... that's my poor man's soluton. Time to apply it and see if it is "just enough".

Final Note- Since I'm not as experienced in hand's on Risk Management as I could be, I welcome any ideas or feedback on this post... especially errors in my thinking. Feel free to beat me up. Most of the places I've worked, I haven't had time to focus on risk because the biggest issue is teaching people how to make and follow a plan along with communicating well as a team (hence my interest in agile).

Update (11/25): Here are two very good articles by James Shore about risk management and estimate inflation if you want to see a more in-depth look at these topics.

Friday, November 21, 2008

What is an impediment?

I use agile terminology in this blog, and sometimes I get asked what a term means. One of these words is impediment.

According to Dictionary.com:
  1. obstruction; hindrance; obstacle.
  2. any physical defect that impedes normal or easy speech; a speech disorder.
or
  1. something immaterial that interferes with or delays action or progress [syn: hindrance]
  2. any structure that makes progress difficult [syn: obstruction]
In my mind, an impediment is anything that delays a team member from working as efficiently and productively as possible.

If you are a manager and don't know better, you tell people what to do and you find an appropriate point of blame for problems.

If you are manager in an agile environment, then you should also be a leader. In this environment it is your duty to help identify, track, manage, measure, AND REMOVE impediments. Your team will reach their goals if you lead and remove impediments. They don't need to be told how to do their job.

Thursday, November 20, 2008

5 minute retrospective...

Personally I view the retrospective as one of the most important parts of agile and one of the easiest first steps to implement. I find many of my peers agree with me. I've done personal retrospectives for self-improvement, and I've talked about retrospective accountability.

Peter Stevens wrote on the Agile Software Development blog about the challenge of working with a new team and introducing agile concepts. Knowing that "challenged" teams are so busy fighting fires that it's hard to interupt them even to make their sutuation better, Peter attempted to apply Ken Schwaber's idea of 5 minute retrospectives. Cue Bill Murray in "What about Bob" saying "baby steps" over and over again.

It's a good read and it furthers my belief that agile retrospectives are a agile practice gateway drug.

Don't use a germ ball...

I know about the pattern where scrum groups use a talking token during their standing meeting. It's some random object that is used to signify who is in control of the conversation. If I'm holding it, it's my turn to answer the three questions. If what I say leads to a short conversation, I am responsible for reeling it in and getting the meeting going back around the circle.

Some groups keep it interesting with random rules around the token. Last one in gets it and starts off. We go in different directions each day which is decided by the first person. We can refactor our standing sequence to change order of turn mid-meeting. Some groups pass it to someone in random order to keep everyone on their toes.

This is all good stuff, but do me a favor. Don't make it a germ ball. I've had this happen in two groups now. The token is something everyone touches. The first flu season comes around and suddenly it's the germ ball. It's the reason that everyone is sick at the same time. No amount of anti-bacterial spray can clean that stupid thing, and the talking token doesn't work if everyone is scared to touch it.

In my group, we have a squishy rubber ball. We kick it around. The downside is that it gets disgustingly dirty on the floor. We call it the dirt ball, sometimes the snot bugger ball. BUT, nobody touches it with anything other than their shoes. Nobody gets sick from it.

We even built a house for it out of a shoe box. I'm sure the cleaning crew is confused by the dirtball house with the dirtball at rest at night... but we don't get sick, so it works for us.

Wednesday, November 19, 2008

Embrace Change...

One of the mantra's of the agile community is to embrace change. Instead of believing that the requirements or customer needs are static while you work a project, you have to assume that the world around us in constant flux. By embracing this concept instead of fighting it, we have a much different outlook on our job.

In line with this, an interesting story was published on Productivity501:

Years ago there was a millionaire who was getting old. He decided he wanted to provide for his heir, but he wanted to protect them from poor investments that would make them lose the fortune he had built up. He had his lawyer draft his will in a way that would provide for his heirs, but only allow his money to be invested in a reliable, solid industry. The industry he chose was electric street cars. Within a generation, his descendants were pumping gasoline at service stations.

The millionaire had good intentions, but he was short-sighted. His basic failure was that he didn’t expect change. He correctly assumed that people would always need cheap transportation. He incorrectly assumed that electric street cars would be around forever.


I guess we should all embrace change!

Story Pts vs. Capacity Hrs...

I was participating in the VersionOne user forums and a question was being asked about capacity. I'm guessing the person was a scrum master or project manager and they were asking about whether they should plan their resource ideal capacity for 8 hour days or 6 hour days.

This is a question that comes up from managers a lot, but it sometimes gets confused with velocity. I've seen people thinking that sprint planning is based on understanding a teams capacity and scheduling to it. Though there is some overlap and dependency between these two concepts... here is some clarification.

Philosophically, you want to use story points and velocity to plan your sprint commitment. You want to use hours and capacity to measure how you track towards that commitment throughout the sprint. Thus, you are better planning capacity at a realistic level. If for your group that is 6 hours, then plan 6 instead of 8. Teams that do support work in addition to project work typically have a lower capacity. This will vary by team.

In other words, hours shouldn't be used to plan and commit to a sprint. Remember that estimates are faulty and full of human error. The point of story points is to normalize this error out. But, using hours throughout the sprint to track tasks and watch trends is a good way to raise red flags and work with the team. This balance is part of the magic provided by the scrum master and project manager.

This is where the old style PM asks, "what about known vacation and holiday issues?"

Yes, you obviously don't let the team commit to the same amount of story points as the last 3 sprints (your velocity) if you know they are all taking 2 days off for Thanksgiving. But a simple rounding math formula can help you figure that out. Determine the percentage of capacity lost (rounded in days) and remove that percentage from your expected velocity for the upcoming sprint. That simple approach will probably be 85% accurate or more. Any more time spent figuring it out will not improve your numbers enough to be worth the investment.

Update (11/25): Mike Cohn just posted today along these same lines.

Tuesday, November 18, 2008

Agile contracts...

Now that Agile is more widely accepted, the industry is shifting from grassroots efforts to getting requests up front to work the agile way. This means that consultants are being approached for engagements where agile is the desired standard. This is a good step, but it presents a new set of problems. How are contracts written for an agile project?

This has been a hot topic of late. Find out more with:

Don't work for jerks 2...

One of the reasons people pursue agile approaches is due to the culture that is found within it. Instead of treating people like resources (cattle), we treat them as trusted team mates. Instead of focusing on a waterfall GANTT chart and controlling impossible things, we focus on communicating with the customer and setting realistic expectations.

This is reflected in the agile manifesto.

It is reflected in Norm Kerth's directive about retrospectives:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
It is reflected in Seth Godin's comments about not working for jerks, and Lynne Ralston's things to look for (prior blog post).

But I have come up with my own list. I like it and I wanted to share. So here is Kevin E. Schlabach's work environment directive-

A good work environment is a place where:
  • everyone knows that we are all fairly compensated (removing distraction and providing stability)
  • my peers and I share a pride in our work and take accountability for what we deliver
  • our teams are respected and empowered (education and training is accessible, impediments are removed, feedback is responded to, there is a low level of politics/process/red tape)
allowing me and my team members to focus on:
  • helping the company make money (profit, not revenue)
  • keeping the customer exceptionally satisified (insuring long term viability)
  • creating business value for the users (sometimes different than happy customers)
  • staying prepared for the future (long-term sustainability, not short term money)
A good work environment is NOT a place where:
  • people work through checklists of tasks
  • meet the minimum requirements of their job
  • are compensated unfairly
  • therefore forcing them to constantly be on the lookout for better opportunities or ways to get ahead of their peers
What are your thoughts? Do you have your own version of this?

Monday, November 17, 2008

What is DONE?

A popular term for me. You probably hear me talk about it a lot... here is what DONE DONE means to James Shore:
A story is only complete when on-site customers can use it as they intended. In addition to coding and testing, completed stories are designed, refactored, and integrated. The build script builds, installs, and migrates data for the story. Bugs have been identified and fixed (or formally accepted), and customers have reviewed the story and agree it's complete.

To achieve this result, make progress on everything each day. Use test-driven development to combine testing, coding, and design. Keep the build up to date and integrate continuously. Demonstrate progress to your customers and incorporate their feedback as you go.
Wanna read more about done? Check out this InfoQ article on the power of DONE or this one on the Scrum Alliance by Mitch Lacey.

Friday, November 14, 2008

Quick links...

Disclaimer: I'll admit that this is filtered from the Agile Software Development weekly reading pack 21-
  1. What does it take to be a good product owner? 100% courage to prioritize a Backlog and stick to his decissions in addition to at least 6 other points.
  2. Coming from a UX background before getting into Agile, I value a thorough understanding of user roles for a given product. Here's a description of an exercise to quickly gain insight as a team into what these roles are.
  3. Case studes: if you are looking for a pile of case studies about agile implementations... look no further. Included in the list are papers written by Schwaber, Kniberg, and Rally.

GANTT chart evolution...

I've mentioned Mike's work previously on explaining Agile to a PMI certified person. He put up a practice post on the evolution of a GANTT chart into an agile project plan. He's not at all endorsing the use of GANTT charts, but he's correct in assuming that we have to speak the language of a PMI certified person to help explain the philosophies of agile. It's a good read and it has expanded on my tools for helping explain this stuff. This post was his way of flushing out his thoughts for the upcoming Orlando conference, so I'm sure he have even more to say in a few days after the conference.

Update: Here's a link to his final post which also links back to all prior posts in this thread.

Thursday, November 13, 2008

Agile Adoption Patterns...

Mike asks "Do you start with agile project structure or agile culture?"

My words on the topic:
Some companies already have an agile culture, many don't. I don't think you can create it out of thin air. If you are lucky to already have it, then jump into agile with both feet. Otherwise...

I like to use retrospectives first to build trust. Build trust by having the team raise issues and showing that the leaders will solve them. Then I like to apply stand-ups... show peer accountability and allow people to admit mistakes. These two things will catch the attention of upper management with happier, more productive teams.

This is the point where I jump to the agile process and structure. Sell your concepts, get buy-in, and start solving problems from the top down. Apply patterns to issues and gain credibility. People will start taking on this agile culture as they see it working.
His follow-up:
I think it boils down to this... you have to have culture, structure, and the necessary support from leadership to align business processes (HR, accounting, contract management, etc.) with development.
Click through to read the full post and what others have commented.

Are we there yet?

Are we there yet?
Are we there yet?

Have you ever been driving and heard this from the back seat? I don't have kids that are old enough yet, but I've seen it in the movies plenty of times and am not looking forward to it.

I once found myself saying this when on a flight to Japan. 13 hours on a plane will make you go a little batty. The thing that saved me was the projection on the wall showing the plane relative to the earth with a miles and minutes countdown to landing. Every time I asked myself if we were there yet, I had the answer right in front of me.

When the jetstream shifted and the flight was delayed, this was immediately shown on the screen with the new projection.

Sound familiar? Sounds like a burn-down chart to me (minus the history).

When the plane first took off, a projection was made immediately even though we hadn't made any progress yet. How'd they do that? Sounds like they used yesterday's travels to determine velocity.

When I download software from the internet to my computer, it gives me a sense of how much is complete and how much time remains. This is constantly adjusted as more pieces and packets arrive.

All of these methods make more accurate projections as progress is made.

In some form, ever since we've had the ability to provide this type of feedback on planes, gps devices, software downloads, etc... we've been staring the burndown concept in the face. Why did it take me so long to want this in my daily job?

Wednesday, November 12, 2008

Google's Agile Tester...

Ever wonder what it is like to be a Test Engineer at Google?

It might sound like a job with that title would be a slave to banging on the keyboard and trying to break the system, but instead you find a story about adding real value and making life easier for the development team.

If you work in a larger organization going through an agile transition and everyone is trying to figure out the new role of the quality assurance group... read this post to get insight into a good example of how it might work after the transition.

Tuesday, November 11, 2008

What is sprint planning about?

There is a good discussion forming on the VersionOne google group about sprint planning. As people were starting to weigh in, I found myself writing more than a forum response... so here's my blog post about it. On my last review, I cut chunks out of this to shorten it... so there is much more to say on this subject.

The following is a description based on my last environment since it was a more mature agile team. We always treated sprint planning as a time-boxed event.
_________

A major goal of sprint planning is to make a commitment to what is intended to be delivered by the end of the sprint.

To do this, you:
  • need customer/team input on what items from prior sprints need revisiting before moving forward (incomplete stories)
  • need product owner/customer input on what is important to tackle next
  • need estimates on these items to understand relative size (unless everything is sized the same)
  • need an understanding of team velocity
Sometimes sprint planning will already have all these things completed (may happen throughout the sprint and during review), but if not, this should be the first focus during sprint planning.
  • First bullet, assess the realities of where you are. There might be items that were rejected during sprint review for whatever reason that now need follow-up work before being marked as DONE. Also, a mature team might have a few stories started for the next sprint because they've learned how to keep their cadence and view sprint boundaries as a point of measurement instead of a true work-stop.
  • Second bullet, have a prioritized backlog. It might shift throughout the sprint due to changing conditions from the market, the feedback from the users, or the complexities uncovered while building the software. This needs to be reviewed and updated so the team understands what is near the top of the list.
  • Third bullet, perform just in time design. As items were put on the backlog, enough design should have been done to estimate them in comparison to each other and properly size them. Now the design should be discussed further to insure that anyone on the team has an idea how they would tackle the work and could see themselves taking it on (but leave the black-box details to the folks doing the work during the sprint). If you have specialized resources, then it might be possible that only those resources need to be involved in that conversation (not my personal preference).
  • Fourth bullet, how much does the team normally get done? This is your velocity.
In an immature agile team (or one with current difficulties) this may be as far as you get during a time-boxed sprint planning session. The agile coach or scrum master can guide everyone on how it will go forward from there. Slice of the top an amount of work matching your velocity and go!

Of course this isn't optimal. So, if you were well-prepared and still have time after answering these questions... then what?

The team reviews the backlog and makes a selection of work they will target for the sprint. They should take into account things like removing risk earlier, not stumbling over each other in the code, the knowledge they have on the team, specialized resource bottlenecks, etc. This may lead the team to negotiate with the customer or product owner to skip over something at the top of the backlog for now.

This is the optimal minimum point to get to for sprint planning. A list of backlog items (stories) that the team has committed to tackling that is also acceptable to the customer / product owner. This is a set list that can be statused, monitored, and managed throughout the sprint. Because the team committed to it, there is a level of accountability that people will take responsibility for.

If you still have time in sprint planning, I've seen some groups break down the stories into tasks. If the team is mature, they can do this without knowing/caring who will do the work later (including task estimates). If not, then they might want to wait until someone picks the story up themselves. In really immature teams (technical immaturity, not necessarily agile), the architect or senior members may lay out the task work and estimates as a guide for the junior team members when they get to it. At this point, there's a lot of variance based on the team's needs, culture, skill sets, agile maturity, etc.

The bare minimum is that the team walks out of sprint planning with a commitment for sprint delivery that they can hold themselves accountable to. Explicitly this is a selection. Implicitly, this is the top group of stories that add up to their prior sprint's velocity.

Monday, November 10, 2008

First-hand TDD experience...

TDD (Test Driven Development) is one of those things that I endorse, but can't teach since I no longer code (crap, there went my reputation in the community). I understand the value of it, I've seen it done successfully, and I can recognize when a group turns that corner and it just clicks for them.

It's great when you run across a first-hand experience to help explain TDD to newbies, especially when it contains the reality that it takes some time to learn. Brian Genisio put up a good post about his first year using TDD and his turning of that corner.

Friday, November 7, 2008

INVEST in your backlog...

Backlog Items are a unit of work with end to end business value being planned, implemented, and delivered through our process. They should attempt to be:
  • Independent – so that it can be reprioritized without dependencies
  • Negotiable – a starting point; everything cannot be known up front
  • Valuable – the story should communicate value to a user or customer, not the tasks or deliverables
  • Estimable / Small – fits into one or two sprints for confident estimation and management.
  • Testable – There has to be a way to verify you have delivered that value, if not with a true test or metric, then with an acceptance test by the customer.
This concept isn't something I created, but I was reminded of it when I ran across this post today on Agile Software Development about the six good features of a user story.

Early detection in cancer and software...

There has been a lot of discussion recently about how agility forces truthfulness, it exposes the realities of a project, and the importance of feeling pain earlier.

It was also during this time in the last week that I lost a co-worker to cancer.

Somehow, I found a link between the two topics.

I won't go into the medical definition of cancer and what causes it since many of us have been affected by it through the experience of a loved one.

How does cancer relate to software development?

Early detection, diagnosis, and treatment of cancer is critical in increasing the chances of putting it into remission.

Early detection, diagnosis, and correction of problems on a software project is critical in increasing the chances of successful deployment.

The longer cancer is left unchecked, the less likely there will be a full recovery and the higher probability it will come out of remission later.

The longer a major issue is tolerated on a project, the more likely the team culture is damaged and will not recover its rhythm because it has lost trust in peers or the environment around them.

I don't know if I'm stretching for this metaphor or not, but it just seems that there is a corollary here.

Early detection is critical in both cancer and software projects and agile provides mechanisms to insure the team (not just the mangers a.k.a. doctors) is empowered to be part of that detection process.

Is it possible that technical debt builds up like freckles and moles on the arm? At first they are benign and harmless, but when they build up the concern should be high?

Is the elephant in the room the malignant tumor lurking in silence soon to kill its host?

Next time you see the warning signs, get it checked out and taken care of. It might save you or your project.

Thursday, November 6, 2008

Measuring Technical Debt...

(Definition of Technical Debt). Fowler recently posted on how to quantify the drag of technical debt by measuring it's accrued interest. It's not necessarily a fully baked concept, but I'm guessing this is a first blip in a concept leading to many further discussions in the coming weeks.

The emporer has no clothes!

I worked with Mike Bria at a prior employer and he's a really smart guy that quickly switched from agile skeptic to agile champion (he says shepherd) when we went through the transition from waterfall. He recently wrote a great article on infoq about how agility means truthfulness.

Everyone read that book as a kid. The emperor is convinced and the townsfolk have a good laugh. How many projects have you been on where the project manager spends his time fudging the numbers so that you can all keep your miserable project afloat for another few weeks? You know the axe will come, but you've bought more time. Is that how we like to work?

Back to Mike's point, agility is about transparency and truthfulness. I love information radiators. Take key points of data (a burn-down chart or cards-on-the-wall for example) and put it in a really visible place. Allow people to see what is important at the moment. Let people see the progress being made, or the things that aren't moving. Allow debates and discussions to happen.

Before you know it, you aren't spending time fudging numbers... you are spending time seeing the trends and correcting. You aren't hiding the failures, you are managing towards success.

If you work in a company where this is the culture everywhere, then you can kill a failing project even quicker (because it is obvious) so that you can get moved onto a project that is successful and much more fun to work on.

Agile can be about being honest with ourselves about where we are heading and what we need to do to be successful. Don't get caught without any clothes on!

Wednesday, November 5, 2008

High release frequency can be empowering...

There are a few advantages for you and your customer when you release frequently (monthly or more). Here's one possible train of thought-

--- thinking like the customer---

Pro - Smaller changes are easier to handle

Instead of giving me one huge drop every six months or year, I get a smaller drop more frequently. I don't have to train users (and be trained) on a lot of changes that affect me, instead the delta is small and easy to manage. I can take a few changes in the software and focus on adapting to them. I have time to learn how to leverage this new functionality to my needs without splitting focus in as many directions. I can provide feedback to the software team based on what I learn instead of waiting for six months in the dark and wondering whether they will change that thing I complained about last release.

Con - the cost of change has a base price

But, it costs time and money to take on an upgrade regardless of how small or large. This minimal costs is never less than $X. This $X cost multiplied by the number of releases per year can cost more than the old single release approach cost me.

Pro - the customer chooses to take a new release

Ahh... but I don't have to take every release. Sometimes releases have changes in them that my group doesn't need or use. We can completely skip a release (or two). If I know what is in the release (and it's a smaller list to review now), I can very quickly decide to move along because there is nothing for me this time. End result, I only take releases when their value is worth investing in taking.

--- thinking like the software team---

Con - our customers are on many different versions of our software

Oh crap, the customer base is on 20 different versions of my software. How do I support all of this? Yeah, that kind of sucks. Is there anything you can do about it? Well, you have to have a good CM approach. And you have to make sure your team makes smart choices between when to fix/patch something vs. forcing the customer off of a version.

Pro - it forces you to provide value in each release

But wait, there is a way to help get people off of your older versions of software. If you are building something of value in each release, then customers are more likely to take the drop. Fix the things they don't like, add features they ask for, improve performance and next thing you know... they want to upgrade.

Con - you gotta stay on top of the market and customer needs

But this requires me to know what my customers want! That's hard! I guess I need them to be tied to the team somehow. They need a voice in prioritization. We need a way to get their desires onto the backlog. We have to mold and evolve our strategy to mirror the changing market.

Pro - you are in touch with the market and customer needs

HAH! We figured out how to do that. It was hard, and it costs a little more money, but we make soooo much more money than before. Customers are loyal and love us. They tell others about our stuff. We know what the market wants. People buy our stuff. In good economies we grow market share by beating our competitors. In bad economies we grow market share by outlasting our competitors. Case studies and leads are easy to find. We are spending a little more money, but we are making a lot more money because we can charge a premium for something we know the market wants.


Do you have a story to share to reinforce any of these points?

Tuesday, November 4, 2008

Iteration-less agile...

In case you haven't heard, some groups are starting to try iteration-less agile techniques. I like the idea, and I can envision it working; but I agree with Amit that it should be left to really mature teams.

But, it's not a stretch if you have been researching Kanban and Lean concepts.

Monday, November 3, 2008

F2F communication is always better...

Why is it desirable to have all team members in a co-located room?

1- Face to face communication is more efficient
  • facial expressions, voice inflections, and body language are all part of communication
  • it is faster to talk than type and read
  • you can pull in other forms by using a wipe board or pointing at a diagram
  • there is less mis-communication
2- Spoken words in the background can be absorbed or ignored at your discretion
You can jump in when you know something that helps. You can listen when you know it helps you. You can ignore it when it doesn't matter. Information becomes transferred by default and this is referred to as osmotic communication.

3- Communication decreases by the length of a school bus
I was sitting in a session with Alistair Cockburn at Agile 2007 when he started to describe this study he did for some big company. Simply put, a person's likelihood of getting up from their desk and walking to talk to someone about something they need decreases exponentially by the distance of a school bus (weird unit of measure, but it translates for most cultures). This means that even if they NEED an answer to something, they will probably make a guess and keep working (on possibly the wrong assumption) until the next time they see that person. With this data, you start to realize that next door offices aren't the same as two people in the same room (and that there is a difference when those offices have doors next to each other vs. 6 feet apart).

So this post focuses on communication instead of co-location, but the two are tightly tied together since communication is one of the main reasons for a team room. I know that co-location isn't always an option, so we need to adapt to the next best solution when possible. The point is not that non-co-located teams fail; it is that co-located teams are faster and more productive.

Final thought: Putting the right people together in a distributed fashion will always beat the wrong people together in a co-located room.

Follow-up note: Recent post on the "secret sauce of offshoring" posted on ASD.