Monday, June 29, 2009

Agile FAQ - Kicking off another Agile team

I recently gave some coaching to a big, well known, UK company get an Agile team started. Its interesting, this team have a few novelties all of their own, I’ll blog about that some other time. But they also have all the same questions and doubts that other teams have.

So here is a kind of Agile FAQ, the questions this team asked which all teams seem to ask sooner or later.

Q: What do we do about work items that are too big to fit in one iteration?
A: We will break the work down. We will break business requests into developer tasks. We will implement the minimally marketable feature the business agree to. We will talk to the business customer about what is required, we will implement the smallest thing that will work. It might be new, it might take some time to get the hang of it but it is doable.

Q: Should we have longer iterations? (Because our work items are so large)
A: No, if you have doubts you should have shorter iterations so that a) you see problems sooner, b) you get more practice at breaking work down.

Q: How will I know what to do if I don’t write a technical design?
A: Design is good but do not do more than is needed. Writing a document can be a useful learning exercise but there are other, and faster, ways to do similar things. Technical designs are best done at the white board with a colleague. If you need to document technical knowledge then document it after you have written the code/done the configuration.

There is no place for architects and software designers who are removed from the team. Design and architecture will evolve over time so needs guiding. This means experienced designers need to be involved (preferably coding) with the team daily.

Q: How will the business know what we are doing if we don’t write a functional design?
A: The business will be working with the team in planning meetings and will be seen the work as it is delivered.

Q: How do we manage dependencies between tasks?
A: Identify them and order the tasks accordingly. If need be break them down further.

Q: What if the business wants us to do A and B but not C?
A: Then do A and B but not C. The business pays the bills. If you need to do C for technical reasons - such as system quality - then do it. Don’t do C if its a feature the developers thing is worth having but the business don’t prioritise.

Q: What if the business wants us to do A then B but it would be quicker to do B then A?
A: Explain that to the business but respect their final decision. If they want B sooner then do it first.

Q: What if there is something technical which the business don’t understand and we need to do? The business won’t let us!
A: Explain it in terms the business will understand - this might require some learning and practise.

Q: Shouldn’t we have a detailed plan for future Sprints?
A: There is no point; requirements will change, your knowledge and understanding will increase and you will be better at estimating later. Only plan the next sprint in detail, you can sketch the work beyond that but don’t spend a lot of time on it.

You might sketch out what you expect to do in future sprints in “Release Roadmap|” but remember this will change as you go. Keep the roadmap under review.

Q: Should I include testing a documentation in my estimates? Won’t that make the estimates too large?
A: Yes. If that is work that needs doing it should be included. Not to include it would start to build an additional, hidden, backlog of work. Equally the customer should see the real price of the work, not the price you want them to see with more to come. And if the project manager gets a shock then so be it.

Q: Doesn’t Agile invite scope creep?
A: Yes but in general I find scope reduces on Agile projects. I call it running Scope Creep Backward.

1 comment:

  1. I'll remember that phrase 'scope creep backward'. I've just been advising a friend on a project he had outsourced to a group in Asia. It was supposed to be a two week project, but they had been discussion the spec for over two months. Why discuss for two months? Well, to be sure the developers didn't waste time coding the wrong thing! Hmmmm... well if they coded the wrong thing for two weeks, and then had to do another two weeks work getting it right, that is till much better than the current two months of specification discussions. :-)
    (my advice was just start coding, get regular prototypes to look and and make changes as you go - but perhaps I should have advised they find another outsourcing vendor ...)


Note: only a member of this blog may post a comment.