The Support Team...

An Agile LinkedIn group participant asked how to run an agile team focused on supporting a product that a different team built and delivered.

First thought... who decides which resources get the glory of working on the sprint team that creates and delivers features and business value each sprint vs. the hazing of working on the support team that fixes the crap. I really hope that if you decide it is necessary to split into these two groups, you at least flip flop the assignment or slowly rotate resources between teams to make it feel like one big team. Otherwise, the supporters will only be mad at the creators and you will fall into the typical us/them developer/QA turf war.

A sub-question was posted on how to handle "critical" issues. It was stated, these are the things that are more important than anything the sprint currently being worked. Several points here:

• If these critical issues are bugs or defects, and they happen often... then it's time to have some courage and discipline and go upstream and ask difficult questions. WHY are these things happening, and HOW can they be reduced in frequency? Instead of adapting to handle them, go to the source and stop them. If you can't because "they" are a different group under different management, then you aren't in an agile organization.
• If they don't happen very often, then this is a simple answer. Let the product owner decide whether the item is more important than items currently in the sprint. If it is, then it should be estimated and should displace a set of stories that are lower priority and of equal cumulative value.
• Work one week sprints. As a support team, you need the ability to be more flexible. Shorter sprints allow for quicker reaction and re-prioritization. Also, work can't stagnate without being noticed. Deployment is quicker (although you might deploy daily and not wait for the sprint end).
• Think about applying Kanban. Loosen the strict requirements of scrum and use Kanban to drive how many things you have in flight at a time. Use iterations as a measurement and assessment tool, and use Kanban to drive priority and work. Walking the board will put the daily focus on priorities.

I know that last bullet blows some of the Scrum rules out of the book, but his questions were Agile questions, not Scrum questions. So, I went with the blended solution approach.

The Crying Developer...

I've talked about the support team before, but David Bland wrote a very disturbing post about a new hire that ended up crying under his desk due to his abuse on support assignments. The post is short and leaves out some of the details to create a complete picture, but the essence is clear. He summarizes with:

What lessons can we learn from this tragedy?

- Good developers want to create code, not continuously patch it.
- Do not leave a team member isolated on a project with no end in sight.
- Training new team members should be mandatory.
- Single points of failure do not save you money in the long run.

As part of the LinkedIn discussion, I added the following:

A developer shouldn’t be forced to do full-time support indefinitely, especially not on code he didn’t write.

I agree that developer’s need to create AND support, but it is much better when they have to support the things they created themselves. It forces them to reflect on their work and the process around them. In the right environment, this can lead to great improvements as they communicate what this forces them to learn.

When one person indefinitely builds and another supports, it becomes to easy for one person to be motivated and another to become depressed.

Incorporate challenges, don't protect against them...

Precondition:
Everyone working for a company should be assumed to have a vested interest in its success because, selfishly put, they want the company to SUSTAINABLY make money so they can SUSTAINABLY make money. (Hopefully they also have pride in the work, their team, and the company's impact on the world.)

Theorem:
By working within a company, employees are likely to have as much or more insight into the domain than the average user of their product or service. Therefore, if one employee has an idea and another employee challenges that idea, it is very likely that eventually some portion of your paying customers/users will have a similar reaction or be affected by the raised issue.

Proposal:
When someome challenges an idea, they are not challenging you personally but instead they are helping insure that the idea will improve the company future and will not detract from other ideas. If the idea is one you support, then it is your duty to accept these challenges as a way to collaborate and make the idea that much stronger.

1. You must first try and UNDERSTAND what they see
2. You can communicate your idea differently in the hope that CLARITY will enable them to support your idea
3. You can enlighten them with FACTS you might have that will change their point of view
4. If they still can't see your idea as one they can support, then you should attempt to debate, collaborate, and COMPROMISE until the idea is one that everyone in the conversation can support and go out and sell to others. [Note: this can be bypassed if the person challenging you can agree that your idea doesn't detract from the larger set of ideas and you have the authority to make said decisions. (This is to combat the everyone-can't-be-involved-in-every-decision momentum blocker.)]
   

The fundamental thought here is that people need to stop baking ideas alone in their head (or a mini-sub-group) until they believe it is perfect and then expect the world to accept it as is. Humans are tribal social people and we have different perceptions of what we want. Once you state any idea that you want others to desire and use, you must accept that you don't control it any longer. It must be molded to the needs of the group you expect to utilize it. Anyone that can help you do this will get you a step closer to success.

This is fundamental in usability, marketing, business... even the selection of what to put on your grocery list (if people other than you share in consuming those items).

Summary:
If your employees aren't drinking your Kool-Aid, then why do you expect your customers to do so? If your team doesn't have the passion you do about trying something new, then they aren't likely to support you as a team when you pioneer new paths!

Credit:
This was inspired by some thoughts triggered by Dale Emery's discussion about resistance as a resource and Denise Caron quotes found in this slideset about agile:

Open yourself to critics and take your capabilities to new heights
Don't fall in love with your product, someone will be there to change it, it's a promise

How to handle interruptions...

There is a great discussion about how to handle interruptions on InfoQ. In many environments, teams have to not only build a product, but also support that product's existing customer base. Fires arise all the time that diminish productivity and velocity for the team. How can this be handled?

Suggestions included:

• separate backlogs
• emergencies (work stops)
• manage support like features
• sacrifice someone

Having seen Alistair's presentation at Agile 2007, this was one of the points I wanted to add to in the discussion. The "sacrifice one" idea is described properly in the post as: "assign one person dedicatedly to take care of that interruption. Though, this one person would feel sacrificed, rest of the team can make progress by working on the primary task."

My thoughts:
"As for Alistair's idea to sacrifice one team member, I do believe he supports that this is a rotating role (per iteration or sub-time window)... and that it is important to assign your most important person first to make it clear that it is an important role and is not dumped on the newer/weaker people in the team. Otherwise, it can become something that breaks the team dynamics into a group of superstars (those that create) and pledges (those that support)."

Don't abuse the metrics...

Tim Ross blogged about his concerns on burndowns. He offers some interesting points on how they can hurt including:

1. too much pressure early on
2. it doesn't handle the unplanned
3. it is unforgiving
4. PM's and customers misread it
5. it discourages refactoring
6. it focuses on a predetermined time

Hmm.... my responses:

1. really? most people feel it at the end
2. it is a reminder of the reality of the clock
3. neither is the market, it is changing whether you deliver or not
4. well... yes, that's true with any data point
   
5. not if you refactor constantly
6. or you could say it focuses on meeting a completion of commitment
   

Okay... some of that is me playing devil's advocate. I can relate to some of the points that Tim makes. Unfortunately, he proposes a solution where teams focus on the task board and maybe even hide the burndown for only the manager's eyes.

Umm... no. If you are really interested in going agile, then you have to understand that there is a power shift from the managers to the team. Instead of having people above (who aren't doing the work) ask for ridiculous things and make useless statements, the team is now more in charge of the process. But, the idea of a self-empowered, self-managed team is that the team has to be willing to be accountable for the work. This is not just the validation and quality of that work, but also the predictability of its timely delivery.

My view on this matter is two-fold:

• The burndown is an indicator. Bad trends in burndowns should be a flag for resetting expectations. When expectations are adjusted (be it the developers, customers, or managers), then everyone should know about it (that is why we do sprint planning and sprint review together, right?).
• ANY METRIC can be abused. If your culture stinks, or there isn't a trusting relationship between the team and the customer or managers... then any metric can be abused to support finger pointing. This is not specific to the burndown.
  

This is why many waterfall projects fail. It takes so long to uncover problems that when they are realized by lower management, they can delay the discovery further by gaming the metrics and reports to protect their jobs as long as possible.

"My definition [of agile] is that you accept input from reality, and you respond to it" - Kent Beck

A burndown is one of many measurements of reality! Unfortunately I think the answer in this situation is that the group needs to improve the cultural issues instead of throwing out the burndown.

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?

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.

Startups are agile by their nature?

Yesterday I had the privilege of presenting the topic of Agile to the portfolio of new companies being mentored by a company called DreamIt Ventures in center city Philadelphia. It's a great program, and I'm proud to have taken some time to support it. I'm sure that some of these smart folks will be successful.

The interesting thing I noticed when walking through their space was how they worked. Each "company" was a group of 2-4 people sitting around one table next to wipe boards filled with thoughts, requirements, plans, etc. The energy levels were high and everyone was focused on the short time they have together to ship this new product and form the foundation of a future company.

One of the disadvantages to selling the agile philosophy to this type of audience is that they aren't overcoming a legacy of problems. Instead of talking about the "downfalls of traditional management" and sucking them into the "wonders of agile", you have to focus on a completely different issue. Instead of saving them from their past, you are instead trying to save them from their future.

It's almost like startups are agile by their simple nature! And it's our job to point at the things they need to protect as they grow (team culture). We have to point at the guardrails they should put into place today before they are too large to recover (examples: focus on technical debt and backlog management). Their team behavior is such that they "just do stuff".

It's very similar to the environment I'm in now. It worked well under 30 people. But when my company grew to 60+, suddenly we needed some process. So, what does all this tell me? It tells me that it's time to start working on those slides for Agile 2010, because this is the exact topic I'll be talking about (Agile Transitions). See you then!

Pit Bull for a moment...

To understand the pit bull reference, read my post about pit bulls vs. puppies that focuses on extreme personality types in the work environment.

Many of us have had a work day where we are facing a major problem. We stayed up all night trying to fix the problem and we are tired, grumpy, or even downright nasty. We go into a standing meeting and vent. We might even talk about how we should have seen the problem coming months ago and shouldn't find ourselves in this situation. Grumble, grumble, GRUMBLE.

STOP!!!

You are asking for help. You are attempting to point out a problem. You are calling attention to a cause that should rally the troops. Is your current attitude the best way to achieve this goal?

We all do it. Take a breath. Point out that you were venting and apologize. Start over on the topic.

If you want to solve a problem, it is important that you communicate things in a way that empower people to help you. Don't create a situation where they leave you alone for the day.

If you are the leader in the group, speak up. Don't let the temporary pit bull deflate the team's energy for the day. Protect the team, and provide the disgruntled support. They aren't grumbling for nothing. Remember, it is a frustrated cry for help.

Best Of- you've listened to me ramble for over a year!

For those of you who follow this blog, I apologize for my recent calm. I've tried very hard to provide you value, and you've rewarded me with wonderful support, great conversations, and plenty of good feedback. But... in case you haven't heard, I do have a good reason. Before her arrival, I knew this might happen and tried to combat it with my pre-written Quote Series... but I underestimated how long it might take to regain normal life flow (this topic was raised in my last personal retrospective).

I've had the energy and sleep to continue absorbing from the community; but the only thing I've been able to contribute back is my agile focused Twitter stream. It has been over a year since I started blogging and I'm pleasantly surprised by the traffic and global coverage of my visitors. Until I can get back into the rhythm of things (hopefully in the next month), I wanted to leave this "Best of Agile Commentary" list in case you joined me on this journey mid-stream.

Top 10 blog posts in the last year based on your clicks (in reverse order)!

1. Participate in change, don't expect it to happen Agile is not just about managers changing
2. Cadence... I used a metaphor of cadence from the military to understand stand ups and feedback loops in agile
3. What is Shu Ha Ri? An overview of Shu Ha Ri… a very important learning principle
4. What is sprint planning about? Focus on the core intent behind sprint planning
5. Shorten your iteration... One of my first posts… shortening your iteration avoids mini-waterfall
6. Walking the board... We were one of the early adopters of the "walking the board" approach where we don't follow the "3 questions" in our stand up
7. Create a proper estimate scale... Popular how-to on creating a story point estimation scale
   
8. UX and Agile, how do they mix? Riding on my past usability experience, one of my first posts about User Experience within Agile
   
9. Snake on the wall! A great way to easily put your finger on waste and distraction with the team… every time this post gets quiet, it suddenly fires up with traffic again after a few weeks from a new source!
   
10. Post agile, one third of you will be gone... Most popular blog post ever about my first agile transition. It created controversy, was picked up by Kent Beck and flagged high on Reddit. Some even went so far as to say I sounded like a cult-member! You either get it, or you don't. When it happened to me, I was a convert, I'm now a pragmatist.
    

And here are three of my favorite notables that didn't make the traffic-based cut:

1. Puppy vs. Pitbull... One of my first posts about team dynamics and personalities
2. Before agile came along, life was easier for me... Reverse psychology at its best about the good old days
3. Bored in the standup? Raise your hand! How we combat tangents during our stand up

Thank you for your continued reading, challenges, and criticism!

Downstream testing...

No, no, no.... and no.

The word "downstream" and "test" should not be near each other in a sentence.

Kevin Rutherford had an interesting post about how better testers allowed the developers to become lazy. As humorous as this was (and I can definitely see it happening), I started to think about what he was saying. Especially as he asked: "What did you do to harness the skills of your great testers so that they constructively support your great coders?"

I got to thinking about the flaw and whether or not it was obvious to him. Even if it was obvious to him, maybe it wasn't to readers of his post. So I had to comment.

Tests need to be run before the story is accepted, reviewed, and closed. If you work in an environment where a testing team runs manual scripts to do testing, then this is included. If this means that your story isn't closed for a while, then so be it. If this is painful to you, then work as a team to shorten that time frame and remove the waterfall.

Paul Richie had some similar thoughts (thanks for the reference Paul).

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.

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.

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.