Agile Methodology How to Deliver

1. Technical Solution: visualising the solution it helps to understand what we’re going up about technically. Talking about your solution and getting it out there in front of your team and customer is good because:

  • It set’s expectations about the tools and technology
  • It visualises the boundaries around the project and the scope
  • It communicates risks

If you are not a technical guy, you just get together with the technical guys on your team and talk about how you are going to build this thing. You draw architectural diagrams, play what if scenarios and try to get a feel for how big and how complex this thing is.

2. Project Risks: Talking about project risk is one of those things that most people would rather skip when starting projects. But talking about risk is a great way of letting people know what you need for the success of your project. Get together with your team (including your customer) and brainstorm all the possible risks you could see happening on your project.

3. Rough Timeline: This is about trying to figure out whether we have a one, three, or six month project on our hands. We can’t be more precise than that at this point, but we still need to give our stakeholders some idea of when they can expect their software to be delivered, even if it is only a really rough guess.

The risk of project failure increases greatly over time.

  • Think small: no development cycle should take longer than six months. The problem with large projects is they seem to perpetually over-promise and under-deliver.

4. The Project Trade-off: Budgets and dates tend to be fixed. Scope regularly seems to increase. And quality is always number ONE. These forces are often in conflict. Giving in to one means taking something away from the others.

  • Time is fixed: “schedules get squeezed”. Agile favor time-boxing the delivery efforts instead of pushing out release dates and delaying the delivery. Any delay has an impact on customer’s ROI.
  • Budget is fixed: “budgets also get squeezed”. One of the most difficult things to do is to go to the sponsor and ask for more money.
  • Quality: is fixed and always held to the highest standard
  • Scope: if there is too much to do, then do less or postpone to phase 2 once the phase to has been delivered

5. The team: at this point in the game you’ll have a pretty good idea what kind of team you are going to need.

Project Team

6. Identify the Who: you can’t have multiple stakeholders, all approaching the team with different ideas, what the priorities are, and what to work on next. You just want the customer to speak to the team in one voice.

7. Estimate the Money: you may never need to talk about money on your project. Your budget may have already been set. Simply multiply the number of team members over the duration of your project, at some rate, and you have your budget.

You have completed your first crucial step to successfully defining, getting people aligned, and kick-off your agile project.

Draft Plan

Read the full series of articles about Agile Methodology: The BasicsWho and WhyHow to DeliverUser StoriesEstimation and Planning.

Read more: Jonathan Rasmusson. “The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)” Pragmatic Bookshelf

5 thoughts on “Agile Methodology How to Deliver

  1. Pingback: Agile Methodology Planning | Carlose Lopez | Blog

  2. Pingback: Agile Methodology Estimation | Carlose Lopez | Blog

  3. Pingback: Agile Methodology User Stories | Carlose Lopez | Blog

  4. Pingback: Agile Methodology The Who and Why | Carlose Lopez | Blog

  5. Pingback: Agile Methodology The Basics | Carlose Lopez | Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s