From lean-startup via design thinking to implementation
Part II — The agile development process
In this blog, I’ll present the hypothetical company called Blockchain Corp (BC) agile development process to build its product following from its application of lean startup and design thinking process presented in Part I.
As a reminder, BC’s product development lifecycle is shown in Figure 1.
In Part I, I ended with BC producing a rough-cut product model canvas.
Project Inception
The BC product team now starts its agile development phase incepting the project by completing the product canvas (see Figure 2).
The team completes the canvas by producing a whiteboard architecture of their Minimum Viable Product (MVP) and identify key Epics.
The purpose of the whiteboard architecture is to give the product development team a broad overview of the systems and sub-systems that make up the product. It is to bootstrap the team initial tasks in the creation of the backlog, factors for engineering decision and, the estimation of tasks and effort. The architecture is subject to change as the development team works through the product backlog. By which time the source of truth about the architecture lies in the code not as presented in this product canvas.
In this instance, the BC product development team has identified several epics but I’ll feature one here and it is the one the team has elected to prioritise as its first development effort (see Figure 3).
Note:
Technically, the Epic should have specifically reference either Fabric or Sawtooth for a higher degree of precision. However, in the interest of neutrality, I have only named the tech as “Hyperledger network”.
The Product Backlog
Having completed the product canvas, the product team then proceeds to break down the epics into user stories and adding to the product backlog.
The BC product team uses five categories to classify types of user stories:
- Epics — a class of features that are targetted specific persona types.
- Features — stories that have not yet been implemented and when implemented are subject to evaluation by sponsored users.
- Chores — a series of background tasks that have to be done and has an impact of several features or the entire product backlog (i.e. project inception).
- Bugs — are reminders of features stories that have been implemented but found to have demonstrated unintended behaviour after a feature has been released for review/use.
- Release — a reiteration of epic feature stories (a feature complete shippable item with release notes and version numbered) that have been implemented and waiting to be released as an MVP or polished up for released to the market.
Note:
This categorisation of user stories follows closely the process encapsulated in Pivotal tacker. The choice of Pivotal Tracker is a personal one. If you decided to follows the process described in this blog you can use other agile management tools.
Privotal tracker is a very opinionated tool and, in my personal opinion, very suited for the Kanban or Scrumban style of agile.
At the inception phase, the team breakdown the epic into a series of feature stories. Initially, the team will focus on features targetted for Felicia. An example of a story specific to Felicia is shown in Figure 4.
Stories related to Sophia are basically a reiteration of those that are for Felicia or very specific to Sophia. The BC team has decided to implement stories that are for Felicia, and one or two specific cases Sophia, first by allocating them to the top of the product backlog. Otherwise, stories for Sophia are kept at the lower end of the product backlog and feature stories are recorded with title only and little else.
The team has decided to de-prioritise features for Bernice by having them held in “icebox” —i.e. stories that are not considered for the current backlog but kept in view and possibly added to the product backlog when the stories for Felicia and Sophia are far in advance in implementation terms.
Note:
The team uses Kanban development process. Hence there is no sprint backlog. The product backlog is the commitment of the product development team to the project stakeholder.
The team starts work from the backlog by working on stories at the top of the backlog as the highest priority earmarked for implementation.
There is kind of backlog or holding areas for features known as icebox where the team is not commited to build but are kept in view.
Implementing story
During the implementation phase, the product development team pulls the first story as shown in Figure 4, which happens to the one at the top of the backlog.
Before the team lay down code, the team performs a huddle with relevant members and break down feature as shown in Figure 4 to one that has greater precision — i.e. into one as shown in Figure 5 and others not shown here.
Figure 4 is refined into several related stories and there is a task that had to be done and spanned across several features. The team creates a chore (see Figure 6) detailing what needs to be done, decision points and mark its relationship to features.
Sponsored User Feedback
The BC product development team also introduces the concept of a real person to stand-in as the targetted persona to help the development team gather feedback for a given feature. These real persons are known as sponsored users.
Where practicable, the team would use a real person with characteristics that closely match the targetted persona. In the absence of a sponsored user, the team relies on the Product Owner (PO) to verify the feature delivered with as much empathy of the targetted persona as he/she is able to muster. The PO would also use this event to generate debate amongst the development team members to think beyond their immediate tasks.
This occurs when each feature story is ready for delivery. If the feedback was negative, the team could decide to pivot and refine the feature stories in the backlog or create new chore. Positive feedback would lead the product team to work on the next feature story.
The team having implement stories for Felicia than determines that Epic has reached a form of MVP and ready for market feedback. On the basis of the feedback of the first MVP, the team then decides to “de-icebox” stories for Bernice and iterate the MVP to a newer version for market review.
The product team iterates the MVP to a point where the product team and stakeholder feel the product is ready to be polished — i.e. fix to non-functional requirements, etc. The team starts refining stories for Sophia, which is essentially a repeat of stories for Felicia and Bernice. These stories are now classified as released stories.
Conclusion
The BC product development lifecycle starts with the application of lean startup and design thinking to derive a product canvas. The process is described in Part I.
The BC product team then use the product canvas to apply the agile Kanban development process to iteratively produce MVP and finally a produce a full-fledged product. The process is described here.
As can be seen, through this process, at every point BC’s stakeholder and product teams are able to iterate or pivot but expanding minimum effort (only when needed) to derive the product. All the while the team remaining focus on delivering only products that are deemed viable or likely to achieve product-market fit.
Note:
Although this blog describes the process from the perspective of a hypothetical scenario. This process is based on observations of examples of real-life practices that I have elected not to name.
This is not a purely theoretical process but details, such as specific design thinking techniques, agile retrospectives, MVP testing strategies, etc., have been left out to illustrate the essence of the process.
