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.

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.