Chapter 15/17 : — Managing Product Development
[Prev: Chapter 14 — How to prioritize Product Features]
[Next: Chapter 16 — Product Metrics — What to measure?]
[Back to — Product Management 101]
There are several methodologies to develop a Software Product.
Traditionally, Waterfall model was used as an SDLC (Software Development Life Cycle) Methodology.
Waterfall model involves a stepwise linear progression of activities.
Here, the output of one phase becomes the input of the next phase with no overlapping phases.
Though the waterfall model is an easy, well documented and predictable workflow; but, it has many shortcomings –
- Limited scope of any changes in the product
- Heavy dependency on initial requirement collection
- No working prototype until late during life cycle
- High risk and uncertainty
- Limited scope to test and alter something that doesn’t work with real customers
Agile Methodology
With the need for a more flexible SDLC methodology, Agile evolved as the preferred one.
Agile talks about Iterative & Incremental Software development, which gives it the ability to adapt to changes whenever required.
Iterative Product Development — means building a product through successive and iterative cycles of refinements. You start with the crudest implementation that manages to do the job and start refining it in each phase. You keep improving it such that you capture more value in each iteration until you get the right product.
Incremental Product Development — means building your product piece by piece. Post each cycle, you keep on adding value to present a product increment (which could be a feature or a minor change).
Agile combines both Iterative & Incremental Product Development and reaps benefits from both, thus reducing the cost of development and time to market, with the added benefit of responsive development.
According to Agile manifesto, we have to value
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to the change over following the plan
You could read more about the Agile principles here.
When to use Agile?
Scrum Framework
Scrum is one of the many agile methodologies, that is practiced by the majority of Agile practitioners.
It is defined as — “Scrum is a management and control process that cuts through complexity to focus on building products that meet business needs.”
Scrum includes all the activities as the waterfall model, but rather than implementing them as sequential phases, they are put into multiple iterations (Sprints) to create a working product. With each sprint adding and improving features and functionality created in previous sprints.
How does Scrum work
- Divide all the requirements (user stories) and arrange them into a backlog
- Divide the work into multiple sprints
- Pull in user stories from backlog for current sprint and do requirement analysis
- Design related to user stories for the current sprint
- Implementation
- Testing of user stories
- Release the features as working software
- Move to next sprint along with including feedback from the previous release into future sprint
Scrum Team
An ideal scrum team consists of 7 (+/-2). [2 pizza team as described by Jeff Bezos]
A scrum team is not a competency-based team but is a cross-functional team which consists of different members having varied skills (Design, Front End Dev, Back End Dev, DB, Testing).
It has a Collective knowledge and skill which allows the team to function as a cohesive unit that ships the product out (rather than relying on external teams).
It functions as a team to deliver features from user’s perspective (rather than a single competency or technology)
. Product Owner
The Product Owner is the bridge between the scrum team and the Business. The PO is responsible for maintaining, adding (as per feedbacks) and prioritizing the backlog of tasks; as well as ensures the team understands the purpose and value of the product and each feature.
Scrum Master
The Scrum Master keeps the Development team productive. The Scrum Master acts as a servant-leader for the development team and makes sure that their issues, concerns, and roadblocks are resolved. All in all, the scrum master is responsible for smooth functioning of the development process.
Development Team
The Development Team is responsible for delivery and quality of the product.
There isn’t any hierarchy in the team and the members have varied skills, specializations, and experience.
Scrum
Sprint
The development cycle that typically lasts from 1 to 4 week (duration fixed throughout the project). The team takes a fixed number of tasks to work upon during the sprint and develop, test and deploy a working application at the end of the sprint.
Furthermore, with each sprint, the usability and value of the product increase as features are added and refinement is done based on feedback from previous sprints.
Sprint Planning
At the start of the sprint, the Product Owner (along with the scrum team) defines a specific goal that the team needs to achieve for the current sprint.
Then based on this goal, PO and the team select stories from the product backlog, review them and commit to the task.
Scrum master then adds these tasks to the sprint backlog.
Daily scrum meetings (standups)
The team meets for 15 minutes to update each other of the tasks achieved from the previous meeting. They discuss the target for the day and any potential road blockers met by the team.
Sprint Review
At the end of the sprint, the team demonstrates the application they’ve developed in the sprint.
Hence, this is an opportunity for the team to get feedback on the product.
Sprint Retrospective
Sprint Master conducts this for the scrum team. Its primary aim is to improve the team’s process as well as learning.
Metrics
Metrics are important to gauge the team’s performance.
Two key metrics to understand how the team is performing are the burndown chart and velocity. Both the metrics are based on story points.
The burndown chart provides a graphical view suggesting how quickly the team is burning down (completing) the user stories. It is the number of stories in the backlog that have been completed against the total number remaining across sprints.
Product Velocity measures the average rate that stories are completed across sprints. We can calculate product velocity by dividing the number of story points completed by the total number in the product backlog.
Velocity measures the work that can be expected to be completed in a sprint. It ensures that the team doesn’t overcommit in a sprint.
Kanban Methodology
Kanban is an Agile methodology that focuses on continuous delivery. It makes use of ‘JIT’ (Just-In-Time) approach (used by Toyota in 1940) — the team pulls in work (WIP) as per the team capacity rather than work being pushed into the process.
Kanban is implemented with help of Kanban Board. The most basic Kanban board consist of 3 swim-lanes -
To-Do, Doing, Done
However, development team might use more columns -
Key Performance Metrics used in Kanban –
Cycle Time — amount of time required for the team to finish a task/story.
Scrum v/s Kanban
[Prev: Chapter 14 — How to prioritize Product Features]
[Next: Chapter 16 — Product Metrics — What to measure?]
[Back to content page — Product Management 101 ]
Want to learn more?
Enroll into Product Management:A-Z — The complete product management online course with 25+ chapters, 40+ live assignments and product interview tips . Built with inputs from experienced Product Managers working @ Top Tech firms like Google, Adobe, Amazon; the course has 500+ enrollments from 40+ countries.
Book Mock Interviews with product experts to practice your interview skills & get detailed feedback.
Check out PM Interview Questions — An exhaustive list of unique Product Management interview questions answered by product experts.
Click 👏 if you found this useful. SHARE to help others find this article.
It gives me 🔋 to write knowing people find value in it.
Originally published at zapupp.com
