How many pairs of underwear should I bring?
The Appalachian Trail is approximately 2,186 miles long and extends from Georgia to Maine. Each year hikers undertake the challenge to “thru-hike” the entire trail. That means they hike for months, carry their own supplies, and sleep at camp sites on the trail. In 2014, the Appalachian Trail Conservancy received notification that 2,742 people undertook the challenge, but only 729 or 26.5% reported completing the trek. One of the reasons people abandon their quest is that they bring either too much or not enough equipment. Zack Davis editor-in-chief of AppalachianTrails.com offers this advice on packing for the Appalachian Trail thru-hike:
Carry too much and you increase your risk of injury, unnecessarily reduce your pace, and above all, increase your likelihood of quitting due to constant physical discomfort. All of your time, money and effort goes for naught.
Carry too little and you run the risk of death (in the form of hypothermia) or an increased likelihood of quitting due to psychological discomfort. Again, nothing to show for all your preparation efforts.
Software development projects can also be long and perilous journey that experiences a fair share of setbacks and dropouts. In my experience too much or too little initiation/planning efforts can also cause waste and introduce risk into the project.
If you spend months and months creating extensive documentation and excessive procedures you can “over-pack” thereby introducing a variety of risks (lost time, lengthen time before stakeholders can interact with the product, rework, inability to react to change, procedural overhead, etc.) Conversely, if you start writing code without an understanding of the key fundamental project dynamics you can “under-pack” thereby introducing different risks (like scope creep, external blockers, surprise blockers, misunderstanding the objectives, etc.)
Finding the right balance is not always easy and you should be wary of a one-size-fits-all solution. In my experience, there are some product fundamentals that needed to be quickly gathered. I would hope you can gather most, if not all, of this in the first sprint. If you discover and document the following items, you should have enough to get started for most projects.
Why does this project exist?
Someone decided this project is worth funding, so what is that reason? There might be multiple smaller reasons, but make sure the group identifies the driving reason. This can help you “hit the mark”. Is this project funded because the existing process is too hard or is the reporting inadequate? If the CEO finds the on-boarding of employees takes too many days in the current software, you will know the new systems needs to reduce the number of days it takes to on-board. Sometimes projects provide the needed functions, but miss the driving reason. Once the team has identified the main driver, make sure that is communicated to all stakeholders. The driving reason can help the product Owner and team set priorities in iteration planning and sprint planning.
Create a project elevator speech
Sometimes projects are like ink blot tests in that people see in them what they want to see. Interested parties can sometimes assume this project is about meeting their need too. A concise and specific elevator speech can help communicate an understanding of the true nature of the project. The elevator speech can be useful for communicating to all levels of the organization. Additionally, if the speech is well written, it can become really useful PR for the project. One formula for a good pitch is below with an example included in brackets:
For – (vehicle drivers)
who – (park in uptown Charlotte)
the – (Charlotte EZ Park)
is a – (parking availability tool)
that – (informs vehicle drivers which parking garages are available)
Unlike – (today when you need to drive around to read the sign in each garage)
our product – (is a mobile app notifies you when your preferred garages are available or full)
Create a product benefit sheet
Thinking from the end-consumer’s perspective, what are the 3-4 main reasons why the end-consumer would buy or use this product. You don’t want or need a complete list of reasons, just the most important. These high level product benefits can help fill your backlog. Additionally, these benefits frame the project in business terms and encourages the development team to think about the end consumers of the product. Zippy Idea – you can have fun with this. Maybe give stakeholders colored markers to draw an ad for the product that highlights the features the end-consumer would enjoy.
Create a Not-Now list
At a very high level, help the team determine what is in-scope and out-of-scope at this point in time. In Agile we courageously accept changing business drivers, but for the sake of focus and of controlling cost, we need to understand the scope and when we exceed it. If the business drivers change and the scope needs to change, then we can be transparent in showing what is additional scope.
Identify what is scary about this project
Discuss what could go wrong on the project. As a group the development team and the stakeholders should brainstorm risks and issues. Also explore the likelihood of realizing the risk and what the impact would be if it actually occurred. Depending on the risk tolerance of the stakeholders, don’t worry too much over risks where the impact is small, the likelihood is low, or there is nothing you can do about the risk. However, as the impact and/or the likelihood increases, the more you will want to find ways to manage the risk appropriately.
Create a back-of-the-envelope solution architecture
Identifying the tools that will be used and the major pieces that will be connected. This will not only help you determine which skill sets are needed on the development team, but also let you identify your neighbors. Additionally, it might also reveal pieces that you don’t have a solution for just yet or tool sets not “approved” by the organization. Be careful here. This is a quick architecture that is open to later change. Don’t spend too long here and don’t think of it as set in stone. Permanent architecture decisions (really all permanent decisions) should be made as late as prudently possible in Agile.
Meet your neighbors
Establishing a positive environment amongst your development team, Product Owner, and stakeholders is an absolute life or death necessity. But what about groups outside the team you might need to rely on? Start the team making contacts with those groups. Think about the Infrastructure, Help Desk, User Provisioning, Security (information or otherwise), Database team, Marketing, Legal, third party providers, and software vendors. Using your elevator speech might be helpful. As you are establishing relationships with them, make sure that the project is getting in their queue or preferably on their calendar.
Wing an initial estimate
High level understanding of the size of the work (is it 2 months or 10 months) can help you figure out if your project is in the right ballpark to meet stakeholder expectations. Assess the estimate on a regular basis to see early if you are still in the ballpark. A second more accurate estimate can be contemplated after the team has determined velocity and gotten their hands around a well-groomed Product Backlog. If you have been around software development projects, you already know that estimates are always hard and often wildly inaccurate. Set your teams best guess and try to tell anyone who will listen that this is a size forecast and not promised date and time.
Starting a new project using an Agile framework can be a lot like starting a hike from Georgia to Maine. You grab what you think you will need and go. You can’t see ahead to the mountains you need to climb or obstacles you need to overcome, but you proceed courageously with the knowledge you will adapt and persevere. Keep calm and Agile on.