Wednesday, December 17, 2008

Waterfall is efficient...

If you want to see how Dan Rawsthorne gets to the following statement, you'll have to read the full post-
To put it quite simply, "waterfall is efficient -- agility is effective", and when we try to be efficiently agile we often wind up introducing false predictability into our process that winds up hurting us in the end.
I'm intentionally teasing you because it's a worthwhile read.

Tuesday, December 16, 2008

Specialized resources can't be outsiders...

Disclaimer: To protect the innocent, I'm quoting people from a forum conversation, but I'm not going to mention where or who. If you don't agree with this approach, feel free to drop me a line and complain. It just wouldn't be fair for me to put their names in the limelight without explicit permission.

In our company some resources like DB developers (and architects) are shared. This makes sense as one team seldomly utilizes one DB developer 100% through the whole sprint. I know we have to use specializing generalists, but you inevitably end up depending on specialists outside of your team and there is nothing I can do to change that. I have problem with planning their demand and availability in v1 [our project management tool].

I need some way to predict when a task will be started in the sprint, so I can notify my shared resources in advance and make sure they are able to focus on that task.
My proposal:
This is difficult and is one of the anti-patterns in agile. Dependencies (especially on resources) are a major problem and require lots of management. You should read Mike C's recent post on this.

One of the changes of going agile is creating a dedicated team where people swarm as needed on the right things. Unfortunately, as you already know, not every skill area can be dedicated in larger organizations. I used to be a usability guy, and my first experiences with agile were excruciating because I couldn't keep up. Things happened when I wasn't allocated and I was always playing catch-up. Also, the team was always upset I wasn't there when they needed me (which meant they started to ignore my role).

Eventually we moved towards "simulated" dedicated resources. I would be "dedicated" to the team every morning every day. In the afternoon's, I would "consult" to other teams and float. This meant I had one main priority project and the others were in maintenance or ramp down. This allocation was tweaked every sprint (most project sprints were aligned). We did the same thing with our QA folks. They had to sit in the team room for at least 3 hours every morning. The whole team was present in the same room for a window of time each morning. This helped a lot. As a specialized resource, I had to prioritize my backlog across projects and work accordingly (and let people know what I couldn't do).

This created a balance. The team might have a dependency on a missing resource for a few hours, but they always knew the resource would be back tomorrow and they would work around that dependency until then.

If you can't dedicate your resources, then you need to lighten the spread of things they work on. Another good post by Tim Ottinger on that topic.

None of this is a tool issue. By going agile, you could trick yourself and plan it out in MS Project or MS Excel, but the reality is that it wouldn't play out as you planned. Instead, you are dealing with a process and culture issue. You have to get your team together and talk through it. See what they can negotiate would work for them. The shared resource is going to have a different set of needs than the scrum team since they are a member of multiple groups. It's a great retrospective topic and it will take time to work out. I'm guessing you won't end up with the textbook agile solution, but part of being agile is adapting.
Response summarized:
I really am not in control of this problem and can't change it. Thus, I need a way for the tool to help me trigger notification that a specialized resource is needed at a point in the middle of the sprint.
Last words back:
Having super-specialized resources like that will make it very difficult. To manage, schedule, and predict dependencies to that level of detail lends itself more to GANTT charts than backlogs. There's little flow or adaptation when you have to manage to these details and therefore this will be a hindrance to maturing agile and letting your team become self-empowered and self-managed.

I'm not being a purist and saying it's not possible, just that it is a difficulty to be overcome within agile. At a prior company, we overcame the architect role by allowing the team to build whatever they wanted and handling the standardization and schema naming convention issues as a refactor by the end of the sprint. Unfortunately this led to a different set of problems.

Good luck.
A 3rd person weighing in:
... In reading your post, I'm not sure what your role is in relation to the team and scrum master, but it appears that you may be trying to manage resources, instead of shifting the responsibility of self-organization to an empowered team.

Friday, December 12, 2008

UX and Agile (part 2)...

One of my highest visited posts is the one I wrote about usability. I've since added updates to direct people to other ideas. Sometimes I feel like I should write more on this topic because there is a large void on it within the agile community, and I spent more than five years focused on it. But the reality is that I have been focused on process, PM, agile for the last 4 years now. Usability is like SEO, you need to be living it today to be an authority. My history in it allows me to carry good conversations, but I'm not going to pretend I'm still an expert.

With that lengthy, wordy introduction... here is a good second part about usability in agile. I just happen to not be the one who wrote it.

Wednesday, December 10, 2008

Get constant personal feedback...

Agile is about constant feedback loops. Release, iteration, daily scrum, pair programming, unit tests... they all provide feedback.

How are you getting feedback on yourself? Are you doing a good job? Do you communicate well? Do your team mates like working with you? Is there anything you can improve?

Something I took away from Agile 2008 is that regular personal feedback (weekly) is much more impacting than a yearly or quarterly review. This is why I've started using Rypple. After every presentation, I send it out to the attendees. I've sent it out to solicit peer feedback to support my self-review with my manager at the end of the year.

I tried something like this before using index cards and received good results, but this platform makes it so much less time consuming.

Try it... it might help you also. Check the site out and watch the quick video for more info.

Tuesday, December 9, 2008

Raise your hand...

There is an interesting discussion in a LinkedIn group about how much side discussion should be allowed in a stand-up. Many of the answers revolve around the famous three questions and why they are important... unfortunately, this may be missing the point of the original question. The question didn't preclude the "3 questions", but instead is focusing on how long tangents should be tolerated as a result of the answers to the 3 questions and the pursuing discussion.

I'm a believer that the stand-up is about saving time and creating a feedback loop. If someone has something to share that most people should hear, then the stand-up is potentially the most efficient time to have this discussion. Telling people to stop talking after answering the 3 questions is going to turn the meeting into a status meeting. In my group, people use this time to also talk about lessons learned in their prior day (I screwed up and here's how you can keep from repeating my mistake...).

I have two possible solutions for this question:
  • parking lot: In my last group we went around the group once and answered the 3 questions. Any tangents or questions that lasted more than a few seconds were halted by the scrum master and written down into a "parking lot" list. After everyone had taken their turn in the stand-up, the parking lot was quickly prioritized based on urgency and overlapping resources and quickly knocked out post-stand-up (or scheduled later).
  • hand raising: My current group is still learning what it means to be agile and is shifting from a command and control culture towards a self-managed one. Our rule is simple... people say what needs to be said at the stand-up. If anyone in the stand-up feels that they are gaining nothing from the current thread of conversation, they slowly start to raise their hand. When the majority of people have their hand up, the minority of people still interested simply state that they will take the conversation offline and we go back to the 3 questions and working through the stand-up. If I'm the only one with my hand up, then I quickly drop it with the realization that the team finds importance in the topic and that the most efficient time to have this conversation is right now. Maybe we aren't doing a stand-up for that brief moment, but we are being adaptable (agile) in our needs.
That being said, our average stand-up runs between 10 and 15 minutes every day. The hand raising approach creates a sort of peer pressure system where people are conscious of the potential that hands will go up.

Monday, December 8, 2008

You make your software suck!

Uncle Bob has spoken again... this time to the masses, not the managers or agile leaders, but to the folks doing the coding.

My take... quit whining and uphold your craft. Your complaints are valid, but they aren't an excuse to create crap.

Again, his post is here if you want to read more: How to Guarantee That Your Software Will Suck

Thursday, December 4, 2008

Snake on the wall!

We found ourselves in a retrospective and there was a general feeling that there were a lot of interruptions in our day caused by "other people" outside the team. Nobody could put their finger on it and everyone had different unique examples. We couldn't easily say if we handle this problem or group of people then it will stop.

So how do you handle this?

Invoke the Snake on the Wall!

Every time a team member feels as though a task they are responsible for is delayed, they write it down on a post-it note. The note includes the time lost (compared to if they didn't have the delay), the thing affected, the cause, and their initials. They take the note and add it to the "end of the snake" which is a growing row of notes on the wall.

Over time the snake is monitored for repetitive patterns. The issues consuming the most productivity time are prioritized to the top of the list for the manager, scrum master, and team to focus on reducing or removing. Scrum masters look at it daily, managers look at it weekly (or when it grows suddenly), and the team reviews it right before retrospectives to trigger new topics. When an item is solved, those related stickies are removed from the snake and it is collapsed back down (you can't let it grow infinitely, otherwise you demoralize the team).

What does this accomplish?
  • it validates real issues
  • it kills false beliefs and misdirected complaints
  • it quantifies the impact of impediments
  • it creates transparency for managers who don't believe what you say
  • it empowers the team
  • it is immediate
  • it self-prioritizes
  • it uncovers surprises
On my last team we quantified for upper management how much time was lost EVERY DAY due to a bad source control system we were forced to use. It also provided insight into things we would never have thought were a problem. If used properly, it does a good job of quantifying the ongoing costs of certain types of technical debt.

So, I'm trying it a second time with my new group. We'll see how it goes.

Wednesday, December 3, 2008

Customer Feedback...

This may not seem like an agile post, but it is... I'll tell you why at the end.
  • To all commercial businesses... stop playing holiday music before Thanksgiving (as early as Halloween). Surprisingly, I'm already sick of hearing it. I almost walked out of my grocery store last night because of it. If your goal is to remind me of the holidays to I spend more... you have passed my threshold of repetitive torture. (At least find something different than everyone else).
  • To all retails stores with Black Friday doorbuster deals... people shouldn't die trying to get into the store to get a deal. Not only is this sickening, but it can be prevented. Use the Best Buy ticket model.
  • Lastly, this whole situation with flight charges is starting to get out of hand. Fuel costs rise, so we get charged more for a seat. Then more for extra luggage. Now overweight people are being discriminated against. Please stop. Can't we just charge everyone by total weight? Put me and my luggage on a scale and charge accordingly. We are paying to move freight. Though I am human, I am a fuel cost just like my luggage and therefore I am freight. I could have 200 lbs of make-up and shampoo in my luggage which is no different than weighing 300 lbs in a seat. Kill the complaints and discrimination issues by charging us all the same way... by weight. (Note: this happened to me on a small plane flight in Costa Rica many years ago, so it is not a new idea.)
What's this have to do with agile? Agile includes customer involvement and transparent feedback. If someone reads this and changes something in their store or airline... then that is agile in action.

Cue groans... now.

Tuesday, December 2, 2008

The Agile Salesman...

Many of us find ourselves explaining Agile to others. What's good about it? Why to do it? How it helps?

The problem is that many of us have been burned by waterfall so badly that we take a "waterfall sucks and agile doesn't" approach. Unfortunately this approach doesn't work because it just leaves a bad taste in people's mouths and we then justify it with the concept that you have to experience agile to truly get it.

I've been following Seth Godin lately since he is a master marketing guru and his viewpoint provides insight into how to sell a new idea. Today he wrote a great post about how to pitch a concept. He uses the metaphors of gravity vs. evolution and how quickly these concepts were "sold". Here's a snippet:
Tactic 1: Try to tell a story that complements an existing story rather than calling it out as false.
Tactic 2: Try to make the 'proof' as vivid and immediate as possible. Like an apple falling on your head.
This is why I like Mike Cottmeyer's recent work around bridging the traditional PM's point of view with Agile's (he has a bunch of posts, so keep looking past this recent one if you are interested). Instead of saying waterfall stinks, he explains how agile enhances.

Monday, December 1, 2008

Agile is a Chinese Buffet...

James Shore has put out an article called the Decline and Fall of Agile. Within the past 2 weeks, I've seen it referenced in many places, including here on InfoQ, and it has definitely sent tremors through the community. Some people have misunderstood his intentions. This has led to many people talking about what languages and labels to use when discussing their agile experiences and whether using these labels properly matters.

Here's a quote from James's article:
It's human nature to only do the stuff that's familiar and fun, and that's what has happened with Agile. People look at agile methods as a chinese menu of practices, choose the few that look cool, and ditch the rest. Unfortunately, the parts they leave out are the parts that make Agile work.
Here's my opinion-
  1. If you are not experienced in a successful agile transition that covers more than one denomination (XP, Scrum, Crystal, Lean), then you are at risk for making incorrect assumptions about what you can change or discard from the practices and still be successful. You either need experienced mentoring, or you need to follow the rules until you know why you do things and what adaptations will increase the value of Agile in your environment. You can't understand value without a baseline. You need to try the things unfamiliar to you to understand their value.
  2. If you are experienced in a successful agile transition, then you MIGHT be able to adapt agile practices and patterns to a specific environment because you have experience and the foresight to see anti-patterns and other issues as or before they occur. You have to constantly take into account that your environment is unique and adapt accordingly.
To the chinese buffet metaphor-
  1. If you've never been to a Chinese buffet, then you don't know what you like or don't unless you try it. You don't know which sauces belong on which items unless someone tells you.
  2. If you have been to this Chinese buffet before, then you have a good idea what makes a good meal for your tastes.
  3. If you have been to a good Chinese buffet before, but not this specific one... you might not realize that this one has very good versions of things you didn't like somewhere else unless you try it again.
Shu, Ha, Ri folks... Shu Ha Ri!

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
  1. obstruction; hindrance; obstacle.
  2. any physical defect that impedes normal or easy speech; a speech disorder.
  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.

Friday, October 31, 2008

Sprint is a bad metaphor...

Some people hear the scrum term "sprint" and get confused. They ask, how in the world do we run at full speed all the time and not get burned out? Well, you have to keep some history in mind. It's a term from Scrum, other agile flavors call it an iteration (thus it's not a blanket term). Also, when people do 30 day sprints, there's a tendency to hear that you should sprint for 28 days, do a review/planning/retrospective cycle for one day, and possibly have one day down time to work on "other" stuff (recognizing that it is hard to keep a heightened pace all the time).

The sprint metaphor is simply supposed to convey that your goal is so close and visible, that you are motivated to put extra energy into trying to reach it. It means that you don't come to work every day for 6 months and chip away at the goal. Instead, it conveys a heightened sense of awareness and focus allowing you to try and grasp at the goal right away.

It doesn't mean you are supposed to go as fast a possible... which is where the name fails. For most people, that is the definition of sprinting.

So, lets talk about the iteration a little bit. Imagine you are a distance runner working through a marathon. You can run the entire marathon without looking at your watch very often and just focus on getting there. If completion is your only goal, this might work for you.

But if you want to finish the race in a certain time, then you need to constantly check your pace. If you aren’t running a 5 min mile on the first mile, then you almost surely won’t have a 5 min mile avg over 20 miles. It’s very hard to make up lost ground.

Software works the same way.

Actually, many runners these days are buying heart rate monitors and other pace measurements so that they know by the second whether they are ahead or behind making their goal.

The real point of the sprint is to have a measurement cycle. If you don’t measure progress frequently, you can’t validate that your predictions are working out. By declaring you will take a measurement on a predefined cycle, you can't allow yourself to fall into a deep hole of trouble before realizing you need to dig yourself out of it.

That, in my opinion, is what the sprint concept is about.

Thursday, October 30, 2008

How to explain Agile to a PMI certified person...

There are many situations where I find myself explaining what I do and what Agile or Scrum is. It's hard to do this with family members that don't understand software development, but it surprises me how it is sometimes just as hard to explain this to a PMBOK experienced PM in my same industry. After all, you can't respectfully explain it by saying why their way sucks and yours is better (elitism is not the answer).

Because agile is so much more than a process or methodology, but it redefines interactions, teams, and communication... it is hard to put into a perfect box and hand to someone.

So what do we do?

Mike Cottmeyer took a really good stab at this on the Agile Software Development blog. He takes the approach of pointing out what issues project managers face and then discusses how agile addresses them. Once you have their attention, then you can go into some of the deeper concepts behind agile.

Here is an excerpt from "How to Talk to Project Managers":

...ask them what happens after they communicate the project costs and delivery date of the project? I would bet money that their response will be somewhere along the lines of: we are given a date, we are given a budget, and then we start de-scoping the project.

...This is where you can explain that they are given the date and the budget because those were really the project constraints to begin with, not the requirements. We pretend the requirements are the constraint because, like most people, stakeholders hope that we will be able to get everything we want for what they are able to spend. Most of the time that is not the case.

...The reality is that by demanding ALL the scope, in the face of data that says otherwise, the business is making the implicit decision that their project will be late. You are generally not rewarded, or very popular with your stakeholders, if you bring this to their attention. Project managers are often incented to keep their heads down, do their best, and take their lumps when things are late.

Wednesday, October 29, 2008

Competitive parallel projects...

If I were to say that you should run the same project with two separate teams in parallel to insure against project failure, you would probably call me crazy. Pay twice for one thing? Yeah, right. Even when I remind you that 60% of software projects fail, you would still assume that doesn't justify the pay twice approach. (That's why we do agile, right? ... to avoid that failure!)

BUT, what if that failure normally happened in the first 20% of the timeline? Would that change your mind?

Peter Stevens wrote a great post about using competitive sprints to select a vendor. It's a pretty interesting read. It even suggests that just because a parallel team "loses" doesn't mean that parts of their work won't get incorporated into the winner. Check it out.

This is an agile focused topic, but I think you would very easily apply it to non-agile but iterative work of any type. I think I've even heard stories that Toyota or Mazda uses this process to create new car models. Different teams create concept cars and as they show with focus groups and auto shows, certain teams get disbanded and removed and the winner slowly emerges. Now that is a good way to bring a car to market that will have demand behind it.

Instead, we normally put all our eggs in one basket.

Monday, October 27, 2008

Don't work for jerks...

I tend to follow a few leaders outside the industry when I can. It keeps teaching me how to best bridge the technical community with the non-technical. One of those people is Seth Godin, a leading voice in the branding, marketing and communication field.

He recently put out a post about considering your choice of employment and how it affects you and your career. Here's an excerpt:
Work in a high stress place and you're likely to become a highly stressed person, and your interactions will display that. Work for a narcissist and you'll develop into someone who's good at shining a light on someone else, not into someone who can lead. Work for someone who plays the fads and you'll discover that instead of building a steadily improving brand, you're jumping from one thing to another, enduring layoffs in-between gold rushes. Work for a bully and be prepared to be bullied.

- Seth Godin
I got to thinking about this and reflected on my past jobs. I have to admit that whenever I work for a company where there is doom and gloom, I tend to get depressed. After surviving quite a few layoffs and bankrupt companies in the .com bust, I'm always keeping on top of the rumor-ville and pessimistic side of business so that I stay prepared. My experiences working with usability focused people after having a science degree make me very analytical, but yet creative. My time in the agile community has put extra power behind my feelings of integrity, respect, and the importance of team and transparency.

It is amazing to see how experiences wipe off on you and mold your personality.

If you are in the situation where you are considering future employment, you should be measuring the potential employer by this type of criteria. I dug up these notes from the Agile 2008 conference and think they are a good starting point for interviewing (full-time or contract) if you are looking for an agile-like environment:

  1. Integrity is No. 1 and I look for this in the people I enter into business with. (Want to enjoy my work!)
  2. I will not sacrifice/trade away building long-term relationships for short-term profits. (Want to build repeatable business!)
  3. I will not sacrifice/trade away enjoyment in my work over generating dramatic profit growth. (Want to not burn out!)
  4. I want to be intellectually and socially responsible to my customers, family, and community (Want to grow and learn!)
  5. I look to enter into engagements with strong sponsorship and clear authority for me to execute. (Want to be able to do what I promise!)
  6. I recognize individuals are the ultimate source of value and need environment where they can make a difference (I value people over process/tools)
  7. I look to attract and mentor talent and partnerships that shares my objectives and values. (Want to work with good people!)
  8. I look to engage customers through frequent interactions and process transparency – prefer customer collaborations vs. contract negotiations. (Want to earn and keep trust!)
  9. I look to deliver simple eloquent working solutions over complex and unsustainable solutions (I want to deliver results!)
  10. I look to enter engagements that leverage all my talents and grow my business reputation – innovate, solve the unsolved (SWAT), and deliver full-solutions where others won’t. (Want to build my niche!)
- Lynne Ralston

Friday, October 24, 2008

Think of the children...

Why should we think about finding something better than the old way of doing things?

So your little boy doesn't make a sign saying "My daddy doesn't have time for me anymore."

Enjoy your Friday!

Thursday, October 23, 2008

Embrace Change != Schizophrenia

One of the most common misconceptions about Agile is that "embrace change" is a mantra that implies "do whatever you want". This is not true.

Instead of writing more about this, I'm just going to direct you to a great post I found this morning about the top five secrets to successfully implementing agile by braintrust software. Summarized, their points include:
  • Ease Your Way Into It
  • Be pragmatic in your approach
  • Embrace Change
  • Practice Servant Leadership
  • Find the right customer for a pilot
It's a really good description (better than I can write) and I really like their 3rd and 4th points. So feel free to click through and check it out.

Nail, meet Hammer....

I've touched on the topic before:
Well, Jeff Langr tackles a similar question. Complete Stories, not Iterations. Nail, hammer, bang. Repeat.

Figured it might make sense to hear it from someone else if you haven't gotten the message yet. If you have, then here's another source to use when explaining it to someone else.

Wednesday, October 22, 2008

What is Shu Ha Ri?

There are times when we try to communicate an idea to someone and we struggle to do so. My dad is a mechanic, so when he tries to explain the inner workings of a combustion engine to me, I'm lost. When I try to explain to him how software is built, he's lost. We have to recognize that as an expert on a certain domain, you can't talk to others as if they are too. This is where the concept of Shu Ha Ri comes into play. (For a more formal description of Shu Ha Ri, check out Martin Fowler's description.)

Shu Ha Ri is borrowed from martial arts. It defines 3 levels of learning-

Shu - Imitation. You do something by copying someone else. You don't question it. The teacher gives you a prescriptive solution to a problem that covers most of your needs. It may not be the most efficient or best solution, but it is simple to learn and covers most of the situations you encounter.

Ha - Understanding. You start to see the reason behind what the teacher taught you. You modify it to still fit the core philosophy, but streamline it for you. You also start to see that the solution doesn't solve every problem and therefore seek your teacher for new ideas and solutions, or you might even seek other teachers for solutions.

Ri - Mastery. You take everything you learn and apply it at will. You solve problems by blending solutions without even thinking. When someone asks what you just did is called, there is no name because you adapted a new solution on the fly. It just worked in that situation. Your own experiences outweigh your formal teachings.

(Literally translated: Shu-> Following | Ha-> Breaking Away | Ri-> Fluency -Cockburn 2007)

Important notes-
  • a Shu level person can not teach. They are not prepared to guide a peer in the journey of making mistakes and adapting.
  • a Ha level person benefits from multiple sources of teaching.
  • a Ri level person thinks in a language that the Shu level person can't understand since it is not prescriptive.
Why is this important? When you are having trouble explaining a concept, it's worth taking a moment to understand the gap of knowledge and experience between the two of you. You might realize that you are speaking at a Ri level when the listener is seeking a Shu level answer. They don't want philosophy or meaning, they want an answer for their immediate solution. There is also the reverse of this... don't talk down to someone who already knows the concepts and needs help blending them together.

Finally, don't teach above your level. Masters learn from their students, but students posing as masters can be dangerous.

The problem with having a Ri understanding of any topic is that you don't realize it. You don't know why they aren't getting it because it is so obvious to you. Stop and remember how you got to this point and strive to help them down that journey also.

Monday, October 20, 2008

Don't mulch your backlog...

Jeff Patton tells a great story about his work with Gary at Mimi. It's a discussion about the typical approach to flattening product backlogs and how this is destructive to understanding the larger picture. Favorite section:

"We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details - the pieces of functionality we'd like to build. In my head a see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations."

"After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag - then cut down the tree."

"That's what a flat backlog is to me. A bag of context-free mulch."

I need that context in order for me to really tell a story about the system.

He goes on to discuss the problem further and also the approaches to solving the problem. Very good post. I'm adding it here for my own reference and in hope it helps you too.

How do I know if I'm Agile?

There are a lot of discussions around Agile and the minimal requirements. I agree that there are many in the industry slapping the agile name on their process because of the positive association. Of course, this only leads to the dilution of the term's value.

There are also many who are pushing back on this and taking too strict of a tone and painting a black and white line. To them, you are either in or out. Of course, these are the same people who will acknowledge it takes months for a team or organization to grow into agile... it's not an overnight transition.

Taking that into account, I typically look at it through one of these lenses:
  • The organization is not agile, and does not care to be
  • The organization is interested in agile, but does not know enough to pursue it yet
  • The organization is going agile without knowing it due to internal coaches who dare not utter the word "agile" for fear of ruining the current momentum
  • The organization is striving towards agile intentionally, but can not call itself agile yet because it has too many areas to still work on.
  • The organization thinks it is agile, but this is limited to what it knows
  • The organization is a leading example of agile, but now the burden is on them to keep pushing the envelope
  • The organization states they are agile, but are lying.
Note how the last bullet accounts for the groups who jump right in without taking the journey down the path.

I've seen tests for agile before, like this nokia test for agility. But personally, if you are just trying to get a simple start to it, I prefer using Cockburn's Crystal test. My group has shifted points 1-6 to a positive position, and now needs to work heavily on #7 before saying we are almost agile.

Friday, October 17, 2008

The Platinum Rule...

If you know me personally, you know that there are a few specific agile leaders that have made a stronger impression on me than others. One of those is Alistair Cockburn. I believe he is slightly under-promoted in the community. People who know his work understand its value, but many people don't know about him or his Crystal concepts. He's a great presenter and he covers great ideas.

Just the other day I was going through my old agile notes to revive any dormant concepts I'd forgotten. One of those gems was Alistair's platinum or Adamantine Rule:

The Golden Rule is self-centric – it instructs us to impose our value system on other people and expect them to be happy that we are treating them well in our value system!

Instead, using ... the Adamantine Rule, the subtext instructs us to
learn the other person’s value system, and treat them well in their value system!

He expands on this slightly on his bliki.

Thursday, October 16, 2008

Sprint Zero...

Many of us eventually learn about the sprint zero concept in Scrum. It arrives when a team is experienced in agile, but is starting something new and realizes that the end of the first sprint probably doesn't warrant a demonstrable / releasable product. There are a lot of ideas on this and it's not really that mind-bending of an idea, it's just one of those topics that you don't learn when sitting in the Agile 101 classroom.

I simply view sprint zero as an adjustment of who the customer really is. Instead of thinking of your end users, it might be managers in the company that haven't approved the project charter or budget yet.

If you are thinking about how to approach sprint zero when you need seed money or sponsorship of some form, then your first sprint should focus on how to spend the initial funding (or getting it).

If you are earlier in the process and working through a formal relationship with a customer that requires an RFP, this can be a different set of challenges. Peter Stevens talks through his personal experience on the topic of writing agile into an RFP.

Update: Peter Stevens continued on this RFP series and has links to all the pieces here.

The train game...

To follow up on a previous post about agile coaching games... today, Infoq posted an article about the session run by these guys at Agile 2008.

I'm happy to announce that a game I recently created and tried successfully in my own company was submitted and accepted by Don McGreal and Michael McCullough into the Tasty Cupcakes wiki.

If you would like to try the Train Game and have questions, feel free to contact me. I'd like to polish it up a bit and improve it based on other people's experiences since I have only run it once.

Update (10/27/2008) - another good post on agile coaching games.

Wednesday, October 15, 2008

How do testers fit into agile?

I'm a strong believer they must be part of the team.

If you have a testing organization within your company, then before agile was implemented you were probably used to pitching "completed" work over the wall and crossing your fingers. Then there was a period of quiet before the wave of bugs came flowing back over the wall.

Going agile is about decreasing the distance between these two points drastically. Actually, TDD (test driven development) is about removing that distance completely. With this philosophy, it is important for a team going through an agile transition to deal with this issue. Instead of the test team relationship being "us and them", you have to find a way to fold the test resources directly into your team. Resources should be slightly more dedicated and must participate in planning and sprint review. Even if they don't aid in prioritization, planning, and design, their presense in the room insures that testing is built into the DONE criteria for sprint work and the timelines are realistic. Their insight can catch issues early, especially those surrounding performance or mis-use of the system. They get a view of what is coming down the pipe so that they can get ahead of the curve and stop being behind the eight ball.

My best experiences with testers on a scrum team occurred when they attended the daily scrum. Also, if they sat with the team throughout the day, they could mentor the team on their unit and acceptance tests to insure the basic logic and validation was covered. They spent more of their time catching the "really hard to find" bugs. They could modify performance and load testing scripts before the work was complete so that system tests could be run almost immediately instead of always being a sprint behind.

The sooner you embrace non-developers into your agile team, the sooner you see these types of benefits. These same points would hold true for usability, user interface, or business analysts.

If you want to know more about testing in agile, I just read a great post by rfleming on whether testing is about uncovering defects or changes. It triggered me to write this because I like his points and they are insightful, but I believe the issue he discusses can be reduced if you strive towards the points I raise here.

Tuesday, October 14, 2008

Is the Product Owner part of the scrum team?

Michael James over at Danube picked up a discussion about whether the product owner should be considered part of the team. At first I thought he was saying no, but as I absorbed his points, I believe he was saying the PO is part of the team. Schwaber has come up with the term "scrum development team" to refer to the team without the PO. This point concerns me a bit... do we need other terms as well such as "scrum analyst team" and "scrum test team"? Why do we want to silo the team off?

The team is the team. It's everyone involved to deliver business value to the customer.

Not every member of the team is committed at the same level and the same way. How team members interact with their peers is important, and different people have different levels of authority when they speak. PO's have a stronger customer and market voice, usability and analyst roles have a stronger requirements and user voice, and developers have a stronger technical voice. But all voices impact each other so excluding any one from the group can be detrimental. Everyone on the team has to understand how to work as a team and not behave in ways that are harmful to the team. Just because a PO is a manager doesn't mean you should treat them that much differently when in the team circle.

What do you think?

Monday, October 13, 2008

Darth Vader was an agile coach too...

I swear I'll stop with the Star Wars references, but I'm not the one making these up and it is complete coincidence that they are back to back...

Courtesy of Sebastian Bergmann on Flickr

Friday, October 10, 2008

Princess Leia was an agile coach...

Great article about managing, anxiety, stress, etc. Includes a Star Wars reference for the fanboys:
The problem is that the more we try to control, the more pressure we put on people, the less likely we are to get what we really want. Princess Leia said it best back in the 70's… "The more you tighten our grip Tarkin, the more star systems will slip through your fingers". The more we scream… the more we demand… the more we try to control… the less likely we are to get what we want.

Being anxious leads us to demand control. The more we try we try to control, the less likely we are to actually get the outcomes we desire.
It wasn't until after the fact I realized that Mike Cottmeyer wrote it. Met him at Agile 2008 and he's got some good ideas rolling around in that head of his.

It's Friday... I'm not going to add to this one, I'm just suggesting you go read it. It gave me some good food for thought, maybe it will for you also.

Thursday, October 9, 2008

Don't create a terrorist...

Peter Stevens over at Scrum Breakfast had an interesting article about questions to ask your CEO about agile. The idea is in line with items I've pointed to previously around explaining agile, specifically Mike Cottmeyer's elevator speech used to grab a CEO's attention.

The item in his post that caught my attention though was around the topic of being "ambushed" which he described as:
... a peer (i.e. rival in the company) learned bad news about your project before you did and surprised you with it in meeting in front of all your peers. Very embarrassing. Operational staff often learns about an ambush through a very heated discussion with said top manager after the fact.
This reminded me greatly of something a prior (non-agile) mentor shared with me about being a good PM and dealing with a "terrorist".

A terrorist is someone who doesn't believe in the same side of a debate or cause as you. Typically it is cultural or political. They hide in the shadows. They wait to strike. (If we exclude the recent surge in suicide attacks, ) terrorism was originally an attack from someone that was in hiding to make a point (and hope to make it again and again until they win). Typically, a terrorist fought this way because they were in the minority in that situation and knew they might lose their cause if they fight out in the open.

You could easily imagine this general description of a terrorist as the group behind any number of bombs left outside any embassy... but you could also easily envision this terrorist as a co-worker that agrees with you in meetings with many peers but soon after seeks out a higher manager to undermine everything that has been said and done in that meeting.

Agile is a cultural change. On some level it requires a company to undergo political or organizational change. It's not uncommon to find people that can't fit within an agile culture. These people can quickly hide once they realize they are outnumbered by the peers around them that embrace agile with enthusiasm. You need to be aware of these people when you are driving agile coaching and transitions. One of my favorite quotes is from J.B. Rainsberger who says... "don't inflict change". Tying this to my other mentor, I believe that if you do inflict change, you are at risk for "creating a terrorist" in your organization. To Peter's point, this will lead to you being "ambushed".

My old mentor also said that once you create a terrorist, it takes a long time to overcome that problem. Sounds a lot like that Bin Laden problem, doesn't it.

Being a good diplomat and reaching out to build relationships with people that are least aligned with your intentions is a good way to create respect across areas of disagreement. I believe it is also imperative to dealing with the above issues. Whether you are driving agile changes, or any other changes... this is something I've found valuable to carry in the back of my mind.

Wednesday, October 8, 2008

Agile coaching help...

If you are looking for great coaching games within agile, check this wiki out.

I leveraged the balloon game and the coin game this week while running training in my company and it seemed to go well.

I saw a session with these guys at Agile 2008 and was impressed with what they are pulling together. Use and contribute!

Agile, where to start...

This is not the end-all-be-all silver bullet answer... but I answer this way because it is what others have shared, I have learned, and there is more support with these approaches.
If you are adopting Agile bottom-up from a tech team perspective... start with XP. If you are adopting agile top-down from a business perspective, start with Scrum.

And yes, at Agile 2008 in Toronto, during the keynote banquet Uncle Bob Martin basically declared that XP and Scrum need to unite and that they complement each other. I attribute this to the fact that XP focuses on engineering practices and Scrum focuses on PM approaches. Someone at ObjectMentor once told me that XP is the content and Scrum is the box it ships in.
Why is the previous in quotes? Because it was part of a discussion that I contributed to Peter Stevens description of what is agile after he attended an agile conference in London. I do agree with him that there might be too many flavors, many mis-applied labels, and that Lean is a great complement to the above.

Backlog Poker Prioritization...

Peter Stevens wrote a great post over at the Agile Software Development blog about how to tackle prioritizing your product backlog when starting a new project. He lists several approaches to this including:
  • Minimum Marketable Feature Set - the first pass to narrow the list of stories
  • Business Value First - Focus on High Value Functions
  • Bang For Buck - Go for easy wins
  • Technical Risk First - Do the hard things first
  • Defer Risk - Do the hard things later (or never)
  • Vote - Ask your users
He then provides an overview of each of these which I will let you read on your own there.

When he asked for other experiences, I mentioned the following:

We had a product where the backlog clearly could not be covered in the first release. Our customers were hospitals that didn't budge on "their needs".

We pulled our top 10 highest paying potential customers into one site and gave each one a bag of poker chips. They were asked to "pay" using their chips for certain features. They were told they could plop all their chips on one feature, or spread evenly across many.

As they saw each other "pay", they shifted their chips around. They didn't "waste" money where their peers didn't care, and they spread money to provide emphasis where peers needed help.

We walked away with a greatly pared down set of features that everyone was invested in (pun intended) and they felt like they were part of the process.

That's what we ended up building.