Ten Tonne Baby!

Where's Mama?

Archive for the planning tag

• The Dark Side of Agile Planning

  I spoke a little about all of the good things you get from adopting an agile approach to planning development of a product, so to keep the universe in balance I should point out some of the evil lurking around the corner.

  I think the success of this approach ultimately is totally dependent on having the right people involved. Try this with the wrong team, and there would be a big mess on your hands. The headline is that agile planning requires a mature body of thought behind the design, and proper consideration of each change that is proposed. You should be refining and enhancing the design, with clear purpose and structured thinking behind each decision. If you’re in a situation where you’re just chucking new features at a product that would be cool then it’s all gone bad.

  The very few times that we’ve rushed to work on a change without this process, it’s gone wrong.

  I think it’s a very healthy thing to have someone on the team who is very creative, and always coming up with new ideas and suggestions. However that needs to be balanced by someone who is very focused on the interaction design of the product as a whole, and is able to push back and say no if necessary.

  The benefits are really significant. I continue to be surprised by how much you learn as you go during development, and it would be criminal to waste all of the new information and thinking.

  An agile approach should mean a continuous, rigorous design process, rather than design upfront, then implementation. If it means that you bypass the design process and are using it as an excuse to jump straight to code, then you’re an evil monkey. Evil, evil monkey.

  Posted:

  December 12, 2007 @ 9:21

  Categories:

  Personal

  Tags:

  agile, evil, methodologies, monkey, planning

  Comments:

  No comments so far

• Why Use Agile Planning

  I think the main benefit that this approach has is that you don’t accumulate assets and invested time around the original plan (which was inevitably wrong). Rightly or wrongly people are always reluctant to admit something is wrong. The more time you put into creating the perfect project plan, the more reluctant you are to change it. The more outputs required from the planning process, the more effort there is in any change in direction.

  In contrast, in agile planning, you have a bunch of cards on a board. You can move them around, chuck them in the bin, add new cards without any real negative impact. The whole process is designed upfront to accommodate change. I usually find the board becomes out of date about every week – sometimes we manage 2, but quite rarely. I’ve just totally refreshed the board to reflect our current situation, and the whole thing took a couple of hours.

  The process is totally visible and accessible to anyone who wanders into the room. The easier it is to see what is going on and become involved, the more thought people put into features that are being proposed.

  It’s always the case that you learn more about what you’re building as you build it. The problem is how to make the best use of the additional learning that you pick up as you go.

  Posted:

  December 5, 2007 @ 9:12

  Categories:

  Development

  Tags:

  methodologies, planning

  Comments:

  1 comment so far

• Agile Planning

  Our team has been using the agile planning process as described in Extreme Programming since the start of the project, and I’m currently thinking quite a lot about how this has been going, and how it should integrate with slightly more formal methods.

  The basic idea is probably familiar to most people. New work is measured in terms of User Stories, which are tangible scenarios for the end user. This sets the main focus to be deliverables that make sense to a consumer, rather than the tasks required to implement them. Cards are scored in terms of relative complexity to each other. There are different approaches to scoring cards, but we’ve been working with the simple model – 1 represents the smallest piece of work possible, 2 is twice as complex etc.

  Work is carried out in 2 week iterations. At the start of each iteration, there is a budget available that can be spend on new story cards based on the amount of work completed the previous iteration (velocity). The focus about which cards to work on is based on what is most important to the business / consumer. The main thing is that planning work is purely based on the speed at which the team has been delivering.

  All story cards are put up and organised on a large whiteboard. One side has a ‘menu’ for new stories that can be picked, organised by category. The other side has the next 2 or 3 iterations, and the story cards that we are planning to work on.

  Each card is intended to be a placeholder / memory jog for all of the discussions and thought that has already exists around the team about the designs issues and details of what is required.

  This is the basic method we’ve been working with. I’m out of time, so will discuss some of the issues in another post…

  I just listened to a NOFX song that made Monday morning seem like a nice, happy thing, just like it should be.

  Posted:

  December 3, 2007 @ 9:26

  Categories:

  Design, Development, Personal

  Tags:

  methodologies, planning

  Comments:

  2 comments so far