In the world of Agile development, it is still important to plan and design. Of course, you want to avoid detailed design of the entire application – if you did that, you’d be right back in the world of waterfall, which isn’t where you want to be, is it?
So you want to get started quickly – but what types of planning should you be doing?
Before you start, you should be sure that you have the business basics under control. We actually developed our own planning process to address this issue, called ID-GEM. We did this to ensure our teams, and our clients, thought through the basics and addressed the potential negative effects of the ever-present “planning gap.” This is a problem we often see with new customer engagements, where people come to us with just an idea, as well as throughout the industry in general. And, as has been documented by many software organizations, this is especially true with Agile development approaches.
Before rushing head-long into technical requirements, we like to pause with a “Sprint 0” planning phase. This serves to bridge the divide between understanding the core business value – what really matters – and the technological requirements. Often, this gap in planning is a result of simple miscommunication between the business and development teams.
Once you have a grip on the business value planning gap, on what you are trying to accomplish and why, you should be sure that you are looking at the following considerations before jumping into coding your application:
- Visuals and User Experience – while it may difficult to do all of these in the Sprint 0 phase, you should consider some or all to give guidance to the team:
- User personas
- Application flows
- Color comps (at least one)
- Wireframes of early screens
- Application Anchors
- What crucial pieces of the application need to be there to fulfill business goals?
- Functional Design – behaviors and data needs for the first subsystems and screens you are planning to build.
- Technical Architecture – This needs to be more than boxes on a whiteboard or an architecture diagram (though those are important). In addition to those items, you should have detailed plan for:
- Where your system will be hosted? (especially important if you are building for the cloud)
- How you will implement specific subsystems and components?
- How you will use technology to achieve specific application goals?
- What operational metrics are critical? How and where will you collect data, what data is important?
- Do you have specific performance goals? How will we build to achieve them?
- Project Plan:
- What is your project timeline and budget?
- What interim deliverables or important objectives need to be achieved along the way?
- How will we manage change in the project?
- Do you have the resources available to achieve your goals in the desired timeline?
The majority of these points apply to most projects. They need to be evaluated as part of Sprint 0 before any other sprints should take place. If you have solid answers to these, or a plan to answer them, you can begin development knowing that you are on solid ground. You need a strong foundation upon which to base future business and technical decisions, and you need to have a framework to evaluate those decisions.