Approach / Solution Discovery
Solution Discovery Phase
Starting the project in Agile way
This is the very first phase in our custom development projects. During this phase Sphere gets together with client for a period ranging from half of day to 2 weeks to help the client come up with idea of:
- what are the business goals of the future project
- what are the user stories (the first draft)
- what are the priorities of the user stories
- what user stories should be included into MVP
We also work on defining risks, Product Owner, optimal team size and main project constraints. In order to ramp up quicker we also prepare UI wireframes, outline main architectural concerns and start doing rapid prototyping. One of very important outcomes is building relationships between real people – Sphere team members and client representatives.
Project size does matter
Timeframes for this phase depend on project complexity and size. There’s no one-size-fits-all Solution Discovery template. For simple projects it’s sometimes enough to make the draft of prioritized user stories and define business goals. For complex projects it’s often needed to define the MVP, make live prototypes to get feedback of main decision makers, define architecture and make feasibility study of possible approaches.
Defining business goals is crucial for a project. It helps the whole team to understand the business context and real value of future project. Moreover, it helps all the team (including Product Owner) to stay focused on business outcome and prevent adding collateral user stories prior to really important ones. Our strategy is in adding the most important features first so that we maximize the business value. When the whole team knows the project’s business value it helps everybody speak the same language and make decisions to improve the application from business perspective.
Our approach for user stories is described here. User stories describe how customers will work with the application and what they will achieve. The list of user stories serves as input to definition of MVP.
MVP is minimum viable product. As defined here it has just those features that allow the product to be deployed, and no more. It contains only those user stories that are critical for project’s business value. Defining minimum product helps Sphere start delivering real business value to you as early as possible. All later improvements are added incrementally and increase business value. Having MVP deployed allows to collect feedback from early adopters and serves as solid basis for future project development.
Unfortunately risk management is often forgotten by some Agile adopters. It can be mostly attributed to the nature of Agile processes. In fact, they inherently address some of risks like delivering product that has no value for the client. However there can be technical and logistical risks that need to be addressed as early as possible. Sphere compiles risk list along with their probabilities and short mitigation plan. Risk list helps to set correct priorities for user stories.
During Solution Discovery Sphere creates as little as possible architecture related artifacts but not less. For complex projects there’s a still high cost of making wrong architecture solutions in the first phases. To eliminate painful architectural mistakes it’s often needed to make decisions on some of the following:
- technologies to be used
- architectural decomposition of the application
- deployment locations and scenarios
- scalability concerns
- disaster recovery
- availability and fault tolerance
- formalizing cross team contract models
- modeling of dynamic interactions
- customization points
UI wireframes is one of possible outputs of Solution Discovery. They help client and internal team to catch the whole idea and serve as starting point for future discussions. This artifact also helps building optimal interface from UX perspective without adding unnecessary screens thus eliminating waste of development time.
For complex projects Sphere often decides to make rapid prototypes. Thus we achieve several goals:
- Showing of live prototype instead of static UI wireframes. It’s better understood by clients and helps them provide important feedback on validity and usability.
- Proof the validity of architectural decisions. For example, measure performance and prove potential scalability of the web application
- Build foundation for development of real application
- Eliminate technical risks
Sphere’s approach to prototyping is described here.
Everything is iterative
As true proponent of Agile methodologies Sphere embraces changes. It means that virtually nothing is fixed in the project after Solution Discovery phase. User stories can be refined later, architecture can be changed or augmented to meet business goals. So we work in iterative fashion. Client’s feedback is major change driving force. So we reevaluate our decisions before starting each new iteration to make adjustments in system design and UI interactions. What still stays is our understanding of business processes and product development goals. Having Solution Discovery phase at the project start helps to ramp up quickly, build good communication with the client and avoid critical mistakes at the very beginning.