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.
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.
Read the full series of articles about Agile Methodology: The Basics, Who and Why, How to Deliver, User Stories, Estimation and Planning.
Read more: Jonathan Rasmusson. “The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)” Pragmatic Bookshelf
Carlose Lopez 
Leave a comment