Secrets of Handling Support In An Agile Team

1technical_support_pounding_fist_445455 Heads-up: I’ve recently started looking more closely into lean and kanban. Expect more posts like this one.

Typemock is a unique company. Developers’ work is similar to our customers’ work. And so, since day one, the developers have also been doing support work.

Support calls have their own life cycle. That’s why usually they are handled by a separate organization within a company. But at Typemock, the same development skills are needed for both product development and support.

Support calls come from different sources (email, forum, twitter, directly from sales). They are then reproduced and analyzed (understanding the problem, may include rounds of communication with the customer).  And finally, there is a solution, a patch or a workaround.

You can’t estimate how much work and timei t takes to complete a support call. You can’t estimate how many calls will enter in an iteration. If there are too many, this can clog up an entire iteration.

So how do you consume the support activities within an agile team?

At first, we’ve reserved a specific amount of time inside the iteration for support. Based on measurements, we knew the average capacity needed to handle calls,

But that’s not enough – the nature of incoming calls is disruptive. In order to maintain premium support level, we can’t delay handling them.  We could be prioritizing tasks as they come – but imagine how wasteful that would be.

In lean terms, this means wreaking havoc on the value flow through the system.

Reserving capacity is not enough.And so the dev team dedicates one developer per iteration for support work. The developer handles all support tasks.

Every iteration another developer assumes this role. The benefits are:

  • We hold great support as a value. To instill this value, all developers do support work.
  • Support work is tiring. The support person starts feeling an outsider within the dev team. To keep up energy and motivation, duration of the support duty is limited.
  • Apart from development skills, support work develops communication skills and also some sales skills. Everyone can and should improve.
  • Dealing with bugs enhances the knowledge of parts of the products, some usually are not touched during regular development. This kind of knowledge is dispersed in the team due to the rotation.

We get the benefit of focused support and uninterrupted development. All the developers are experiencing support work, but are not seperated from the rest of the team.

And it doesn’t stop here. Next time I’ll talk about how support work is implemented through a kanban system.

Gil Zilberfeld

The Agile Alignment

In my last post “What’s next for Agile?”, I talked about alignment between the development team and the business, from the customer focus perspective.

As I was watching “Agile is dead, long live agile” presentation by Jeff Sutherland, from Oredev 2010, I felt I needed to add something.

When does agile work? According to Jeff, when management commits to it.  In fact, Jeff as a VC, backs only companies that their management is committed to do the change (or already practicing scrum).

So it works when both management and the development team are aligned. This is inward alignment: From management into the development organization, and I assume others as well.

Where’s the customer focus?

I assume VCs won’t invest in companies that don’t have a viable solutions or products for their customers. So the combination of solving customer problems and an entire organization practicing agile are the formula for success.

So what’s next for agile? Whole business alignment – both process-wise and customer-wise.

What's Next for Agile?

Let’s take a look at the agile manifesto. It starts with:

“We are uncovering better ways of developing
software”

Next are the values. I’m not going to bother with the “right” side, which is of course the “dark side”. On the left we have:

  • Individuals and interactions
  • Working software
  • Customer collaboration
  • Responding to change

All this is very nice, and the last 2 even touch on the fact that there’s a customer involved. But where does it say that the customer gets what he wants?

In the Agile Tour conference, Mary Poppendieck presented “It’s not about Working Software after all” in her keynote.

Mary talked about the next inflection point in agile – getting back the customer focus. “Agile” until now was about the processes and tools that improve software development. These now have to align with the business goals of the organization -  provide what the customers need.

How does the alignment happen?

Throughout the organization, people need to understand exactly how their work solves their customers problems. Mary gave an example of Southwest Airlines – the ground crew can turn around planes consistently in less time than any other airline company, The crew understands that planes on the ground are waste. They understand that there could be a family member waiting for the plane they are tending to.

This kind of motivation starts at the top and trickles down to people who do the work. This is a cross organization alignment.

So far, “Agile” has created bubbles inside the organization. Self managed teams did their best to produce working software. But it’s not enough.

Can “Agile” make the next leap?

Apparently, Agile Is NOT Dead!

Yesterday I went to Agile Tour Israel. At the end of the day I was surprised, I didn’t think I’d enjoy it that much. Once again, being pessimistic saved the day!

The event organizers did all they could to push agile and show it as mainstream. Cynical as I am, I was surprised to see how agile gets adopted in big corporations. In the two case studies presented, going agile was an organizational management decision. The process of implementation sometimes hurts (beware the success of the pilot projects!), but organizations now tackle agile issues in disparate teams, globally. They now have sections of agile coaches internally, that are responsible for the implementation and improvement.

As organizations actually grow solutions internally, rather than just get consultants to drive the process – it’s a good sign for adoption. However, there was notably more focus on organizational processes, much more than on software development practices. Like I said many times before – scrum succeeds because it’s easier to explain to non-developers. Developer work is still considered black magic, and therefore not so easy to explain to management.

Let’s get that clear: You can’t succeed in your agile transition, if you don’t have the engineering practices in place. They go hand in hand, and half way will get you, well, half way.

Within the crowd you could see people from a different range of the agile persuasion – from being interested to adopters, and more important – modifiers. These are the people who tried and recognized that successful adoption is not about going by the book, but fitting the system to their organization.

Best presentation went to Mary Poppendieck. (although funnily enough, the auditorium was less crowded then – don’t people know who she is? Her presentation is what drew me to this conference in the first place.). For her presentation, I’ll devote a separate post.

All in all, a good conference. Good effort for the organizers, although with some glitches. I’m glad I went.

So, dear reader, and agile practitioner, what do you thing about the state of agile adoption?

Gil Zilberfeld

Place your bets!

The answer is yes. Microsoft is killing off Silverlight. Don’t underestimate the truth said in the PDC keynote: Microsoft is going the HTML5 way.

But this is not a review of the he said/she said MS is playing for the last week. It’s about the risks associated with selecting a technology, or making an architecture decision.

Let’s look at recent history: two years ago, Microsoft killed of LINQ to SQL, replacing it with LINQ to Entities and the Entity framework.

This year Microsoft has made another killing (pun intended): this time it’s Iron Ruby and Iron Python. The method of euthanasia: putting the projects into the community’s hands.

This is not the first time, nor the last time that Microsoft will be killing something that many organizations have invested heavily in (or in the best case, were merely interested in). Microsoft is taking business decisions, and there’s a fallout.

I’ve written before how Microsoft makes bad developers. In that post, I described the way Windows developers rely on Microsoft to provide guidance and tools. The immanent death of Silverlight is another side of the the same coin: The Microsoft addicts (e.g. we), don’t know what to do when the supply of the drug is cut.

This is vendor locking. We’re betting on the wrong horse and need to live with the consequences. Some say the answer is open source platforms. Once you own the entire code you can control your destiny. Others rely on standards to save them (Microsoft said they are moving to HTML5 because they will not be able to get Silverlight one every possible platform, but HTML5 will be on every platform.)

So what do we do?

We continue to bet. We move services to the cloud. We’re learning the new async keywords. We build on top of AIR. We do what we can to meet our business needs. 

And if needed, we cut our losses and bet on another horse.

Gil Zilberfeld

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More