Understand the Importance of Having the Product Vision in a Scrum Team
By Radhika Subramoniam
Stories abound of products launched with much fanfare and failing miserably in the market. What does it take to build a software product that sells? Would the best technology, the best architecture and the best brains guarantee a product that will sell?A lot of energy is spent by the Engineering teams on building the product right – bug-free, scalable, reliable and secure. Throughout this journey the teams also need to be confident that they are building the right product – usable (fit for use), serves the purpose (fit for purpose), solves the customer’s problem and delivers value.A popular representation of this relationship is given belowA Product Vision is a well thought through “future state” of the product that serves the customer’s needs as well as furthers the organization’s product strategy. The product vision serves as the “guiding light” that the teams constantly refers, consults and steers towards.This article is about how a good product vision paves the way for scrum teams to build a good product. It is not the only step but definitely one of the first steps to build a product that will sell.Components of a Product Vision A well thought through and finely articulated Product Vision includes the following components Purpose and Intent – Why are we building the product and what value it brings to the Customer? What problems is the product going to solve for the Customer? Target Market – Who is the Customer(s) / Market Segment that the product is meant for Business Goals – By building this product how are we aligning with the organization’s strategy and goals in the market. Every product offered by an organization should align with the larger goals and strategy so that it fits well with the organization’s product portfolio. Differentiating Factors – How and what features are we offering that is a differentiator in the market and which sets the organization apart from its competitors. Many a product fails to see the light of the day or serve the purpose of the customer if it has failed to justify on any one or more of the above components. Creating the Product Vision Anyone who is connected to the Product can contribute to the Product Vision. Organizations usually have idea boards and forums to welcome innovative ideas from all employees. But the ownership of defining, communicating and nourishing the product vision lies with the Business Group or Product Management Group. Usually the vision is created through a Workshop involving the right stakeholders who have the expertise to contribute. The stakeholders represent Business, Engineering, Marketing, Sales, Support, Training etc. Various techniques such as Brainstorming, Affinity grouping, Dot Voting can be employed in the workshop to come up with the final Product Vision. Prior to the workshop findings from Market research on target customers, competitors, information on Personas are made available to the participants so that they are well informed and bring the best to the table. Product Vision Formats The Product Vision board as recommended by Roman Pichler, leading Product Management Expert. The Product Vision Board A Simple template first introduced in the book Crossing the Chasm by Management Consultant and author Geoffery More.Communicating the Product Vision A great Product Vision will not get realized into the final product unless it is communicated well, not just once but multiple times, to all the important stakeholders – the Senior Leadership, the Engineering teams, Sales, Marketing, Documentation, Training and Support. It is the responsibility of the Head of the Business (e.g Director of Product Management) to introduce and explain the Product Vision to the rest of the organization before the product development is started. A Kickstart All-Hands meeting usually happens when a new Product Vision is ready. The road map and strategy for the immediate future (every Quarter/Release) to realize the vision is also shared in this meeting. It is important that all stakeholders who are participating in building the product gets to hear the same information at the same time from the Head of Business. This All-Hands happens at a defined cadence (every Quarter /Release) where the changes to the product vision, strategy and road map for the next quarter /release is communicated. The Heads of Engineering would also present their plans for the Quarter /Release to further the product vision. Heads guiding the team It should not be an open and shut communication for a day, but the Product Managers and Owners need to constantly refer and draw from the vision when interacting with the Scrum Teams. When requirements are refined into Epics and User Stories and prioritized the Scrum Teams need to be able to relate them to the Vision. Changes in the Product Vision So is a Product Vision written on stone never to change? No, because that would defy Agile Principles of continuously seeking feedback, embracing and adapting change. A learning organization has a pulse on the market and actively seeks feedback. It adapts the product vision according to the changing market, competition and customer feedback. It has a constant sense of Urgency to Fail Fast, has the Courage to Pivot when required and Persevere on the right track as part of the Organization culture. There are stories of many organizations that have imbibed and practiced this culture and succeeded. Significance of Production Vision within the Scrum Teams A journey without a destination sounds exciting but not practical and not always fruitful. R&D engineers would not have any dearth of imagination to build products that are beautiful and perfect. But would these products serve the customer’s needs? Understand the Larger Purpose: Scrum teams need to understand the big picture and the larger purpose of their everyday work – for whom are they building, for what and most importantly why. During Backlog Grooming sessions, the Product owners can act as ambassadors for the Product Vision helping the teams to refine user stories with end goal in mind. The questions to be constantly asked and validated include “Are we solving the customer problem?” , “Are we adding value?”, “Are we building the right product?” Product Strategy and Vision to Plan your roadmap Contribute in Product Strategy and Roadmap: Scrum teams can contribute effectively to the product strategy and roadmap if they know and understand the product vision. Understanding the Priorities: Understanding the Product vision helps the team to identify with the priority put forth by the Product Owner. The Product Owner and the teams can make use of the product vision in the Sprint Planning and Backlog refinement meetings to streamline user stories. Influence in Sprint Execution: Having the product vision in the back of their minds plays an important role in the story writing, refinement, acceptance criteria, coding and testing. Knowing the customer problems and target market helps teams to build “just enough” and stop from over engineering and manufacturing unwanted imaginary requirements. Unwanted code is a waste that can cause unwanted testing, bugs and needs to be avoided. Knowing the target Customer / market, purpose and the problems that need to be resolved, helps the teams to Refine and write better Epics and User Stories . Helps to identify the ‘Must Have’ and ‘Good to Have’ Acceptance Criteria. Helps to architect and design better knowing the immediate priority and the upcoming roadmap. Helps to code incorporating enough customization for reuse and extensions in future. Define and formulate the appropriate test scenarios and data Collaboration: Multiple teams come together to build a product. Having a common Product Vision to refer to improves their collaboration and serves as a good point of reference to manage conflicts and dependencies. Alignment with the Organization’s Goals: There is also another very important piece of information within the Product Vision - How the Product Vision aligns to their organization’s overall strategy. This is definitely of interest to every employee of the organization. An engaged employee always is curious about how the product he is helping to build today fits and aligns with the organization’s goals. The fact that he/she is contributing towards furthering the Organization’s goals does instil a sense of pride and confidence. Adapting to Changes in the Product Vision: The changes to the vision has to be constantly communicated to all the stake holders especially the Scrum teams who are building it. The teams need to also be told why there has been a change in the Product Vision. Only then would they appreciate and embrace the changes. Tips for your Product Vision: Ideas can come in from unlikeliest of places. Inputs should be encouraged and accepted from all stakeholders and funnelled into the Product Vision creation workshop. Prior to the workshop, sufficient Market research has to be conducted to get information on target customer, personas and the competitor landscape. A vision not shared well remains only that and does not become a reality. Communicate at every opportunity – kickoff meetings, through posters and through dedicated ambassadors -Product Owners , Product Managers , Line Managers. Seek feedback and gauge the market continuously to adapt Do not fear to pivot if needed and change course. Failing early and fast is better. Do not try to address all the “How” and “When” in product vision, but the “What” and “Why”. In conclusion, a Product Vision plays a very important role in the working of a Scrum Team providing the larger purpose of what is being built by them everyday. Only through constant communication about the vision and about the changes to it can the Scrum Teams keep relating to the vision and make the vision a reality - a good product that sells.
Rated 4.0/5
based on 13 customer reviews
Radhika Subramoniam
The author is an Agile Consultant working in the areas of process consultation and Agile coaching and transformation. She has been part of the software product development industry spanning field service, fleet management, telecom billing and network management.
Posts by Radhika Subramoniam
Understand the Importance of Having the Product Vision in a Scrum Team
By Radhika Subramoniam
Stories abound of products launched with much fanfare and failing miserably in the market. What does it take to build a software product that sells? Would the best technology, the best architecture and the best brains guarantee a product that will sell?A lot of energy is spent by the Engineering teams on building the product right – bug-free, scalable, reliable and secure. Throughout this journey the teams also need to be confident that they are building the right product – usable (fit for use), serves the purpose (fit for purpose), solves the customer’s problem and delivers value.A popular representation of this relationship is given belowA Product Vision is a well thought through “future state” of the product that serves the customer’s needs as well as furthers the organization’s product strategy. The product vision serves as the “guiding light” that the teams constantly refers, consults and steers towards.This article is about how a good product vision paves the way for scrum teams to build a good product. It is not the only step but definitely one of the first steps to build a product that will sell.Components of a Product Vision A well thought through and finely articulated Product Vision includes the following components Purpose and Intent – Why are we building the product and what value it brings to the Customer? What problems is the product going to solve for the Customer? Target Market – Who is the Customer(s) / Market Segment that the product is meant for Business Goals – By building this product how are we aligning with the organization’s strategy and goals in the market. Every product offered by an organization should align with the larger goals and strategy so that it fits well with the organization’s product portfolio. Differentiating Factors – How and what features are we offering that is a differentiator in the market and which sets the organization apart from its competitors. Many a product fails to see the light of the day or serve the purpose of the customer if it has failed to justify on any one or more of the above components. Creating the Product Vision Anyone who is connected to the Product can contribute to the Product Vision. Organizations usually have idea boards and forums to welcome innovative ideas from all employees. But the ownership of defining, communicating and nourishing the product vision lies with the Business Group or Product Management Group. Usually the vision is created through a Workshop involving the right stakeholders who have the expertise to contribute. The stakeholders represent Business, Engineering, Marketing, Sales, Support, Training etc. Various techniques such as Brainstorming, Affinity grouping, Dot Voting can be employed in the workshop to come up with the final Product Vision. Prior to the workshop findings from Market research on target customers, competitors, information on Personas are made available to the participants so that they are well informed and bring the best to the table. Product Vision Formats The Product Vision board as recommended by Roman Pichler, leading Product Management Expert. The Product Vision Board A Simple template first introduced in the book Crossing the Chasm by Management Consultant and author Geoffery More.Communicating the Product Vision A great Product Vision will not get realized into the final product unless it is communicated well, not just once but multiple times, to all the important stakeholders – the Senior Leadership, the Engineering teams, Sales, Marketing, Documentation, Training and Support. It is the responsibility of the Head of the Business (e.g Director of Product Management) to introduce and explain the Product Vision to the rest of the organization before the product development is started. A Kickstart All-Hands meeting usually happens when a new Product Vision is ready. The road map and strategy for the immediate future (every Quarter/Release) to realize the vision is also shared in this meeting. It is important that all stakeholders who are participating in building the product gets to hear the same information at the same time from the Head of Business. This All-Hands happens at a defined cadence (every Quarter /Release) where the changes to the product vision, strategy and road map for the next quarter /release is communicated. The Heads of Engineering would also present their plans for the Quarter /Release to further the product vision. Heads guiding the team It should not be an open and shut communication for a day, but the Product Managers and Owners need to constantly refer and draw from the vision when interacting with the Scrum Teams. When requirements are refined into Epics and User Stories and prioritized the Scrum Teams need to be able to relate them to the Vision. Changes in the Product Vision So is a Product Vision written on stone never to change? No, because that would defy Agile Principles of continuously seeking feedback, embracing and adapting change. A learning organization has a pulse on the market and actively seeks feedback. It adapts the product vision according to the changing market, competition and customer feedback. It has a constant sense of Urgency to Fail Fast, has the Courage to Pivot when required and Persevere on the right track as part of the Organization culture. There are stories of many organizations that have imbibed and practiced this culture and succeeded. Significance of Production Vision within the Scrum Teams A journey without a destination sounds exciting but not practical and not always fruitful. R&D engineers would not have any dearth of imagination to build products that are beautiful and perfect. But would these products serve the customer’s needs? Understand the Larger Purpose: Scrum teams need to understand the big picture and the larger purpose of their everyday work – for whom are they building, for what and most importantly why. During Backlog Grooming sessions, the Product owners can act as ambassadors for the Product Vision helping the teams to refine user stories with end goal in mind. The questions to be constantly asked and validated include “Are we solving the customer problem?” , “Are we adding value?”, “Are we building the right product?” Product Strategy and Vision to Plan your roadmap Contribute in Product Strategy and Roadmap: Scrum teams can contribute effectively to the product strategy and roadmap if they know and understand the product vision. Understanding the Priorities: Understanding the Product vision helps the team to identify with the priority put forth by the Product Owner. The Product Owner and the teams can make use of the product vision in the Sprint Planning and Backlog refinement meetings to streamline user stories. Influence in Sprint Execution: Having the product vision in the back of their minds plays an important role in the story writing, refinement, acceptance criteria, coding and testing. Knowing the customer problems and target market helps teams to build “just enough” and stop from over engineering and manufacturing unwanted imaginary requirements. Unwanted code is a waste that can cause unwanted testing, bugs and needs to be avoided. Knowing the target Customer / market, purpose and the problems that need to be resolved, helps the teams to Refine and write better Epics and User Stories . Helps to identify the ‘Must Have’ and ‘Good to Have’ Acceptance Criteria. Helps to architect and design better knowing the immediate priority and the upcoming roadmap. Helps to code incorporating enough customization for reuse and extensions in future. Define and formulate the appropriate test scenarios and data Collaboration: Multiple teams come together to build a product. Having a common Product Vision to refer to improves their collaboration and serves as a good point of reference to manage conflicts and dependencies. Alignment with the Organization’s Goals: There is also another very important piece of information within the Product Vision - How the Product Vision aligns to their organization’s overall strategy. This is definitely of interest to every employee of the organization. An engaged employee always is curious about how the product he is helping to build today fits and aligns with the organization’s goals. The fact that he/she is contributing towards furthering the Organization’s goals does instil a sense of pride and confidence. Adapting to Changes in the Product Vision: The changes to the vision has to be constantly communicated to all the stake holders especially the Scrum teams who are building it. The teams need to also be told why there has been a change in the Product Vision. Only then would they appreciate and embrace the changes. Tips for your Product Vision: Ideas can come in from unlikeliest of places. Inputs should be encouraged and accepted from all stakeholders and funnelled into the Product Vision creation workshop. Prior to the workshop, sufficient Market research has to be conducted to get information on target customer, personas and the competitor landscape. A vision not shared well remains only that and does not become a reality. Communicate at every opportunity – kickoff meetings, through posters and through dedicated ambassadors -Product Owners , Product Managers , Line Managers. Seek feedback and gauge the market continuously to adapt Do not fear to pivot if needed and change course. Failing early and fast is better. Do not try to address all the “How” and “When” in product vision, but the “What” and “Why”. In conclusion, a Product Vision plays a very important role in the working of a Scrum Team providing the larger purpose of what is being built by them everyday. Only through constant communication about the vision and about the changes to it can the Scrum Teams keep relating to the vision and make the vision a reality - a good product that sells.
Rated 4.0/5
based on 13 customer reviews
7059
- by Radhika Subramoniam
- 28 Aug 2020
- 8 mins read
Stories abound of products launched with much fanf... Read More
Agile Project Management: Best Practices and Methodologies
By Radhika Subramoniam
Agile is an iterative and incremental solution development methodology that focusses on delivering value to the customer by seeking customer feedback, embracing and adapting to change and striving for improvement continuously. The Agile Manifesto along with the Agile Principles are at the heart and in the spirit of the various Agile Frameworks which are being adopted increasingly by Enterprises as their Project Management Framework. Agile Project Management Agile Project Frameworks Scrum, Kanban, XP, SAFe are some of the Agile Frameworks that are have replaced traditional waterfall and predictive approaches of Software Project Management. Long standing philosophies such as Lean and practices like TDD, BDD, Pair Programming etc are leveraged into these frameworks. Scrum and Kanban are the most popular Agile Frameworks used today with Scrum being used in almost 58% of Agile Projects as per the Annual State of Agile Report 2020. Scrum uses a time-boxed iterative approach to develop incremental products and solutions with each iteration spanning 2 /3/ 4 weeks. Kanban does not have time-boxed iterations and focusses on establishing flow of work by controlling WIP (Work In Progress) and is well suited for maintenance, support or Helpdesk projects. In this article we will discuss about Agile Project Management using Scrum. Before looking at the Scrum framework briefly, we need to understand two very important aspects in which Agile Project Management is different from traditional Waterfall – Scope and Estimation. The Iron Triangle Unlike traditional projects, in Agile the schedule and the cost involved for a project is largely fixed. The scope is the variable entity and is adjusted as per the latest information and feedback from customers. The focus is on delivering value rather than following a rigid and detailed plan laid out at the beginning of the project. In Scrum for example, every Sprint runs for a fixed time-box and changes to agile team composition is not recommended. Iron TriangleEstimation – Relative Sizing Agile recommends “relative sizing“of work items that enables predictability rather than complex estimation techniques striving for accuracyAgile EstimationIn the Image 2 above people on the road looking at the buildings would most likely converge on the fact that Building A is the smallest of the three, Building B is twice that of A , Building C is the tallest – almost 3 times that of Building A. This can be done quickly at the first glance. In contrast if they must estimate the actual height of the building in metres it is prone to error and there are going to be a lot of differences. The power of relative sizing lies in the fact that we do not strive for accuracy (in the example the height of the building in metre) but focus on sizing the work and achieving predictability over the course of time. Instead of complex effort estimation in man days/hours, High level Epics /Features are usually estimated by the T-shirt sizes (Small, Medium, Large, X-Large) and Stories are estimated and given “Story Points” that follow the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) Brief overview of Scrum Framework The Scrum framework comprises of the roles, events and artifacts and describe how these entities interconnect with each other in order to implement the framework. Scrum follows an iterative approach where development cycles are 2 /3/4 weeks long. At the end of every iteration an incremental version of the product/solution is ready to be shipped. Each event /artifact/role in the scrum framework serves a purpose and furthers the goal of Agile project development. Let us go over each of them in detail. Scrum FrameworkRelease Planning Although Agile does not recommend detailed rigid plans laid out well in advance, it does not altogether forego planning. There is a high-level Release Planning at the beginning of the release and shorter detailed Sprint planning events at the beginning of every Sprint. Having short planning phases throughout the project implementation helps to adapt to changes and course correct at responsible milestones. For large organizations where multiple scrum teams work towards developing a solution, planning and timing a release is very important. The organization might choose to time the release as per Customer(s) demand or at an established cadence (e.g every quarter) or in alignment with certain events (e.g tradeshow/ compliance deadline etc). The release planning is a look ahead planning with an objective of arriving at the scope of the release considering the schedule and budget as fixed components of the iron triangle. The two important inputs required for this event is a prioritized product backlog and the velocity of the teams participating in the release (historic data for teams running on agile and an informed guesstimate for the new teams.) The teams will roughly plan out their upcoming sprints (if a release spans 12 weeks there can be 5 sprints of 2 weeks each followed by a 2 week “hardening sprint”). At the end of this planning event there is a list of prioritized features that can be accommodated in the release and a high-level plan for each sprint. Scrum Roles The Scrum Master, Product Owner and the development team form the “3 Amigos”. There is a good amount of trust and a healthy relationship amongst the people playing these three roles. Healthy conflicts and disagreements between these three entities is expected and bound to occur. At these times the teams are guided by the Scrum Values of Respect, Courage and Openness. At all times the scrum team practices commitment and focus to achieve the Sprint Goals and further the Agile Values and Principles. The Three AmigosResponsibilites of Each RoleResponsibilites of Each RoleScrum Artifacts Product Backlog: A Product Backlog consists of all the new features, changes to the existing features, technical requirements such as infrastructure upgrades or architectural requirements that might become a part of the product. This is continuously refined by the product manager, product owners and the scrum teams. The purpose of the refinement is to prioritize, split and detail the contents of the backlog so that the first set of items in the backlog are ready to be picked by the teams during their Sprint Planning. Sprint Backlog: The items picked from the Product Backlog and committed by the team for a Sprint constitutes the Sprint Backlog. It is unlikely to change during the course of the Sprint/iteration. A product owner could introduce changes in consensus with the team. Multiple changes to the sprint backlog within the Sprint timeframe should be discouraged and root cause analysis has to be performed during retrospective meeting if this happens often. Product Increment: The work items ready to be delivered at the end of a Sprint is a Product Increment. It has to be in a potentially shippable condition and meet the definition of done as defined by the team and has to be accepted by the Product Owner as complete and ready for release. Scrum Ceremonies / Events EventFrequency of OccurrenceDescriptionBacklog RefinementContinuousEpics and features are estimated and broken down to Stories. Stories are broken down and acceptance criteria are added. The Backlog is prioritized and ordered.Sprint PlanningOnce at the beginning of a Sprint lasting up to 4 hours for a 2-week SprintThe top priority stories that are refined and ready for the team is picked. The teams estimate the stories and load the sprint up to their Capacity. The historic Velocity and the current capacity (leaves and holidays adjusted) are taken into account for loading the Sprint.SprintCan be 2 /3/4 weeks longNot recommended to change the Sprint duration often. The cadence once set has to run for at least 3 to 4 Sprints to collect data for becoming predictable.Daily Stand upEvery day for 10-15 minutesThe Scrum Master facilitates the event and the team shares the happenings of previous day, strategize and plan for current day. Impediments /concerns are raised.Sprint ReviewOnce at the end of the SprintThe working software is demonstrated to stakeholders. Based on Sprint Review and outcomes, inputs and changes are done to the Product BacklogSprint RetrospectiveOnce at the end of the SprintThis is the "sacred time of learning" for the entire team. Issues and problems faced during the Sprint are discussed, root cause analysis performed and team arrives at solutions to resolve and prevent in future. The team identifies areas of improvement.Scrum ceremonies or eventsScrum Values Courage - Every team member feels safe to fail and learn, to seek help, to say ‘no’ and question something that is going wrong. Commitment – Commits to the Sprint goals as a team. Does not overcommit. Focus - Aims to complete what is started and steer away from distractions and unprioritized / "shoulder tap" work. Limits Work in Progress. Openness - Seeks and values feedback and opportunities to learn. Makes impediments, failures and learnings visible. Respect - Team collaborates and acknowledges the work and achievements of every member. Builds trust. Quantitative Metrics Organizations can collect and measure various metrices. The below metrics are most likely to be captured by most of the projects and add value. Burn Down Chart: The Burn down chart is a run chart of the rate at which the scrum team completes work within a sprint in terms of number of Story points completed per day. Velocity: Velocity is the number of story points completed and accepted by the Product owner within a Sprint. Collecting data on velocity enables teams, releases and projects become more predictable. Other than the absolute velocity, another important perspective of velocity data is % of story points delivered against total story points committed by the team. Velocity cannot be used to compare the efficiency of teams since 3 story points for one team is different for another team. Quality related Metrics: Quality related metrics like number of defects reported in production after release, number of defects in Integration testing are captured to understand the level of Quality. Armed with quantitative data the teams can come up with ways to improve Quality. Quality related MetricsAgile Projects at Scale While the scrum framework prescribes the guidelines to run an Agile team, the same can be extrapolated and mechanisms can be put in place to scale it to multiple teams. SAFe and Nexus offer frameworks to scale Agile in large Enterprises. Large projects in Enterprises involve multiple teams and dependencies with other functions, divisions and with third party partners, suppliers and vendors. The complexities of large solutions and programs require Governance, Compliance, Stakeholder Management, Streamlined Communication, Conflict and Risk management. The Agile Program Management Office takes care of establishing Agile at scale with the help of Senior Leadership, Agile Coaches and Change Agents (who could be the Agile Project Managers and Scrum Masters). Role of the Agile Project Manager The Agile PM plays an important role when doing Agile at scale in large enterprises. While working towards a seamless project release by interfacing with the multiple scrum teams and various stakeholders, the Agile PM also plays a key role in the Agile transformation journey of the Enterprise. Agile at ScaleAgile Project ManagerScrum Master and Agile PM Roles Agile Projects at scale requires the role of a Scrum Master for the internal functioning of the team and the Agile PM for aligning multiple teams and orchestrating the activities of a Release. Agile PMScrum MasterTakes care of the facilitation, risk management, conflict management, handling of impediments that span multiple teams and external stakeholders. Engages closely with Senior Leadership, Product Managers, Product Owners, Scrum Masters to ensure smooth implementation of the current release, forward plans for the subsequent release and co-ordinates the Post production activities of the previous release. Facilitates the Scrum of Scrums synch meetings at a regular cadence (every week). The Agile PM guides the scrum masters to resolve risks and impediments within the team if and when escalated. Takes care of these activities within the scrum team. The Scrum Master focuses on the current sprint and current release. Facilitates Scrum Ceremonies. Participates in the Scrum of Scrums and updates if the team is on track to meet the Sprint Objectives and if there is any change/ risk foreseen. During this meeting the Scrum Masters raise any impediments /risks/concerns they are unable to resolve and need help with. Release Management Continuous Integration and Deployment: With incremental versions of the product after every iteration from multiple teams early continuous integration is the need of the hour. Investing in an automated Continuous deployment into the Staging or Production environment is encouraged so that the latest version of the product is release ready. Enterprises are increasingly using toggle configurations to switch on/off a set of features so that the release can be done for a particular market segment or can be timed with an important milestone like a tradeshow. By separating the deployment and actual release, there is a lot of risk avoided. The actual product release can be announced at the right time – as per Market demand/ after a robust Beta has been done and feedback incorporated/timed with a compliance deadline or important milestone like tradeshows. Post-production Support: Releasing working software at regular intervals is not the end of the road. Customer Support, training and customer documentation where required is necessary and these activities should also come under the purview of an Agile Working environment. Beta and Canary Release: Large Enterprises engage with Beta customers to get focussed feedback on the product before a wider market release. Solutions and products can also be released to a particular market segment or a subset of users alone. This is called a “Canary Release”. This phased approach rather than a big bang approach will ensure the risk level is reduced and the quality of the product and credibility of the Enterprise is maintained. How is an Agile PM different from the Conventional PM The roles and responsibilities of a conventional Project Manager is now distributed amongst the Scrum Teams, Scrum Master, Product Owner and the Agile Project Manager. But the most important but subtle difference between the Conventional PM and Agile PM is the mindset. The Agile PM is a Servant Leader who wants to create a self-empowered self-organized team. He/she creates an agile environment where everyone is accountable, there is no fear of failure but the willingness to learn and continuously improve. The Agile PM avoids the traditional Command and Control approach where decisions are taken for the teams. . There is also a conscious effort to decentralize decision making so that decisions are taken closer to where work is done. There is always an emphasis for visualization of work and transparency. Go-to Traits for a Successful Agile Project Self-Organized Teams: Self-organized teams that are empowered and largely self-sufficient is an important facet of Agile. Teams are used to conventional ways of working where they look up to their superiors for decision making. Decentralized decision making will help largely to create empowered teams Responsive to Change: creating empowered teams enable them to respond to change responsibly with minimum red tape. Quick Feedback Loops: Agile thrives when there are quick feedback loops established so that teams can adapt to change based on informed decisions. Continuous Improvement: Learning from the past and resolving not to repeat mistakes is an important facet of Agile teams. Retrospection at end of every iteration and release is highly recommended. Business Agility: It would not be enough if engineering teams are agile and churn out software seamlessly. “Building the product right “is not sufficient and the teams should “Build the right product”. Solutions and products have to meet the customer needs and solve Customer Problems. All functions such as product management, marketing, sales HR have to come into the purview of Agile Principles and Values to achieve the kind of Business Agility that is required to be Customer Centric and deliver value. In conclusion, Agile is a paradigm shift from the phased traditional waterfall methods which run on detailed plans laid well ahead. Agile Project Management is the need of the hour considering the rapidly changing market scenario, disruptive technologies and the ever- growing competition. Before embarking on Agile projects organizations have to invest the time and effort to create a conducive Agile Work environment. The bare basics of Agile training and creation of small Agile teams (5 to 9 members recommended) with the vision to make the teams self-organized need to be in place. Agile Coaches and Change agents have to be identified to ensure the Agile transformation starts and keeps pace with small strides and does not die a natural death with teams, business and leadership falling back to traditional waterfall methods in the name of agile.
Rated 4.0/5
based on 13 customer reviews
6653
- by Radhika Subramoniam
- 01 Aug 2020
- 9 mins read
Agile is an iterative and incremental solution dev... Read More
How to Use Scrum Board for Agile Development
By Radhika Subramoniam
What is a Scrum Board?A Scrum Board or an Agile Board is a visual representation of the work planned, progressed, and completed by a scrum team in a sprint or iteration at any given point of time. The board is comprised of columns that represent various successive states of the workflow progressing from left to right. The work items appear in the column as per their current state in the development workflow and then move across the board from one column to the next till they reach completion or last stage.The “To Do / Ready” and “Done” states appear in almost every Scrum Board, the “In Progress” items can be further categorized into various states e.g. – Analyse, Design, Code, Test etc. These states are solely created as per the needs of the Scrum Team and Project.Image 1: Simple Scrum BoardWhy is a Scrum Board needed? The Scrum Board visually represents the amount of work along with their current states in a Sprint. The Board speaks to the team everyday about the holistic progress made by the entire team towards their Sprint Goals and provides a sense of accomplishment and achievement when work items are completed. It avoids creation and progress of “Hidden Work” or “Shoulder Tap” injected work that may not be prioritized. In the event of an interruption (like production issue, any new or changed requirements, changed priorities), it helps Business to reprioritize the work items quickly looking at the current state of the planned items in the Sprint. It also keeps reinforcing road blocks and impediments faced by the team to all the major stakeholders. Any number of written and verbal communication may not be able to visually represent the state of the entire sprintas a whole as effectively as this visual radiator.Scrum board allows teams to manage the flow of work across the sprint as it helps in avoiding multi-tasking, overloading one person because everything is visible and traceable. How to organize a Scrum Board Physical and Virtual Scrum Boards Teams that are entirely collocated can benefit from physical boards that caneven just be a whiteboard placed near their work cubicles. A physical board could also be on a wall having coloured tape for columns and sticky notes for cards. Team members typically swarm around the board /agile wall/task wallduring their daily stand up or whenever there is a need. Image 2: A typical physical scrum boardImage 3: A typical Jira scrum boardDistributed teams on the other hand find virtual boards easy to use. There are many tools available in the market to set up Scrum Boardssuch asJira , Rally , Monday.com etc. In some companies, the Scrum boards are displayed on giant monitors placed near the teams work cubicles. Cards and Columns are the two basic entities on the scrum board.Card is the entity on the board that represents a “Work Item”. A Card can be a User story /Production Bug/Technical Task. During the course of the Sprint these cards travel through the board from left ,“To-Do” to right “Done”. A Simple Scrum Board for Beginner Teams The Scrum Board below is an example of a typical team board in a software project. Image 4: Typical scrum board for a software projectThe items on the Product Backlog are discussed and as per priority and their readiness, pulled into the “To Do” or “Ready” column during Sprint Planning. At the beginning of a Sprint all items in the “To Do” or “Ready” column comprises the Sprint Backlog of the team. As the Sprint progresses, the items move into the downstream columns until “Done” is reached. A clear “Definition of Done” helps to conclude if the story / task is completed. Usually beginner teams build the board translating the current workflow of their work items into columns on the board. As the teams evolve, they adjust the board accordingly. Effective Visual Representation of data Information on the Cards Physical Cards usually are post-it notes or sticky notes that carry the User Story/Description, Acceptance Criteria and the Story Points as a minimum. Using post-it notes is a deliberate attempt to keep the story small and avoid loading a lot of work into one story. In a Virtual board, cards can have exclusive fields to carry information like Project Name/Assignee/Reporter/Created Date etc. These might serve multiple purposes like metrics/reports. Colour-Coded Cards Colour coding is an excellent technique used to convey important information to the audience at the first quick glance.Cards can be colour coded based on their work type like User Story/ Technical Task/Production Bugs. Cards could also be flagged (in the case of a Virtual board) or overlaid with a (preferably) Red coloured card to convey a risk/dependency that needs attention. Swim lanes Defining Swim lanes is a very useful mechanism to categorize the work items on a Scrum Board. They are horizontal rows on the board that carry a specific type of work that is different from the normal/ work categorized by a certain parameter. For e.g. a team that has to resolve emerging high priority production bugs would prefer to use a “Fast Track” swim lane to progress the bug and then continue with their original Sprint work. A team that works on hardware, firmware and software components in a sprint might want to use different swim lanes for each component. Swim lanes are for the teams. Creating a swim lane for each team member may not be a good idea since the basic guideline for scrum is to work as a team and this representation might affect a team’s mindset. In the board below blue cards are User Stories and green Cards are tasks. Red cards are Production bugs. Some cards are flagged red indicating risks or impediments. Image 5: Example of scrum board with colour-coded cards and swim lanesAspects of Kanban in Scrum BoardA common challenge encountered in projects is when tasks accumulate or pile up in a phase or stage of the workflow. There could be several reasons why that happens. But identifying them is the key to solving that challenge and the Scrum Board effectively helps in this. Assume that Cards D, E, F, G have completed development and ready for testing. Cards B, C are being tested. It is day 6 of a 10-day Sprint. Developers might now bring in H, I from the Ready Column to start development work, creating a bottleneck at Testing. Image 6: Scrum Board without WIP LimitsConcepts of Kanban can be borrowed into a typical Scrum board to address this. One of the techniques that can be used is to split the column into “In Progress” and “Ready”. This will set the stage for a “Pull” mechanism at every stage in the workflow of a story. Introducing “WIP Limit” or “Work in Progress” Limit at the columns ensures multiple work items do not pile up at one stage of the process, do not get “pushed” downstream but rather gets “pulled” by downstream process and there is a steady flow created in the system. Considering the team is at day 6 of the iteration, it is recommended the team “stops starting and starts finishing”. If the team swarms and completes the testing of D, E,F,G there could be more business value delivered rather than starting development of H and I and having only few of the Development complete cards partially tested. In this scenario, a WIP Limit of 4 at development prevents the team from bringing in more work items into the development phase. The team can now swarm to complete the testing of the developed items taking them to completion. Image 7: Scrum board with WIP limits and columns split into “In progress” and “Ready”Effective use ofthe Scrum Board Updating and maintaining the Scrum Board Scrum board is owned by the team and it is the team’s responsibility to update the board to reflect the reality.The team also has the responsibility to evolve the board to suit the need of the project by experimenting on concepts of WIP Limit. How best to use the information on the Board Scrum Board can be used to identify bottlenecks in the flow of work. If bottlenecks are identified in one stage of the workflow, the team can resort to Swarming or enforcing WIP Limits. Seeing the work items move through the Scrum board and reach “Done” during the Sprint provides the team a sense of accomplishment. Challenges and ways to overcome them Easier said than done, updating the board is one of the biggest challenges faced especially in beginner teams. Not every team member will be prompt in updating the board. To overcome this challenge, updating the board could be one of the team ground rules with non-compliance attracting fun consequences decided by the team, such as the defaulter treating the team with chocolates/coffee or updating everyone’s scrum board the next day. The Scrum Master can immensely help the team realize the power of the board by using it during agile ceremonies like planning, stand up and retrospectives. Facilitating the scrum by traversing the board from right to left (i.e.“Done” to “To-Do”) is another tactic to keep reinforcing the value of the board and motivating the teams.Having conversations in stand-ups by traversing the board from right to left will first bring up cards that are done or almost done and helps see what has been accomplished in the sprint. What a Scrum Board is not A Scrum Board cannot replace the conversations and interactions that are always encouraged in Agile projects. Flagging a card on the scrum board / posing queries on a card should not solely replace the conversations around these. A Scrum Board is not for executives to monitor the team’s progress and efficiency, but it is for the team to monitor their sprint items as a whole. Key takeaway A Scrum Board is an excellent tool for the team to visualize their work, look at everyday progress, identify bottlenecks, make immediate course corrections, so that they can meet their Sprint goals. Used rightly, it will serve the team and benefit them. However, if it is used by management to monitor the team or if the team members consider it as a tool to update management then it loses its purpose and becomes just another overhead.
Rated 4.0/5
based on 13 customer reviews
6687
- by Radhika Subramoniam
- 03 Jul 2020
- 8 mins read
What is a Scrum Board?A Scrum Board or an Agile Bo... Read More