Search

How to Use Scrum Board for Agile Development

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

How to Use Scrum Board for Agile Development

7K
How to Use Scrum Board for Agile Development

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.

How to Use Scrum Board for Agile DevelopmentImage 1: Simple Scrum Board

Why 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. 

A typical physical scrum boardImage 2: A typical physical scrum board

A typical Jira scrum boardImage 3: A typical Jira scrum board

Distributed 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. 

Typical scrum board for a software projectImage 4: Typical scrum board for a software project

The 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. 


Example of scrum board with colour-coded cards and swim lanesImage 5: Example of scrum board with colour-coded cards and swim lanes

Aspects of Kanban in Scrum Board

A 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. 

Scrum Board without WIP LimitsImage 6: Scrum Board without WIP Limits

Concepts 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.  

Scrum board with WIP limits and columns split into “In progress” and “Ready”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. 

Radhika

Radhika Subramoniam

author

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. 

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Why Do We Use Fibonacci Series for Estimation

In this article, my focus is on sharing my experience as a Trainer/Mentor/Coach to Agile teams with respect to Agile estimations; and on using the Fibonacci sequence as scale to size the Story. What will you learn in this article? Agile practitioners mostly use Story points as a measure for estimation, typically using the Fibonacci scale. In this article we are going to understand the top reasons why we use the Fibonacci series for estimation, and how it works in practice. Before we get to the details, let us try to understand some of the fundamentals. Why do we need to estimate?Estimates help the project team to: Identify the time & effort required to arrive at the project schedule Identify the right number of people required to do the work Arrive at the budget by rolling up the cost of all activities required to complete the work; and Prioritize the work in conjunction with the value that will be delivered. Some software developers fear to provide effort estimates as they are accountable to complete their work within the time.  Hence, they take so much time to get into the details to make sure they have enough information to provide the estimates. This sometimes may not be possible during the beginning of the project as the team may not have enough information on hand to provide the effort estimates for all the tasks to be performed. Hence the order of magnitude (ROM, Budget or Definitive) will be applied at various stages during the project based on the available information to predict the effort needed to complete the activities. Agile Estimation  Typically, in traditional project management, effort estimations may or may not be agreed upon by the entire team. Estimates may either be given by the Project Manager/Tech Lead to the team or the developers/testers may estimate for the piece of work that they have been assigned. This way of estimating a project does not provide an opportunity for the team to collaborate. There may be a difference of opinion with the team members in the effort that need to be spent on an activity. The way the estimations are done within an Agile team is little different. It is just not about the measure used to estimate the effort (for example Story Points), but ensures that the team collaborate among themselves, thus providing an opportunity for knowledge sharing. This helps the accuracy of the estimates when compared to doing individual vs group estimates as the team members come from different backgrounds and roles (developers, testers, quality analysts, business analysts). An Agile team effort estimate focuses on relative sizing of user stories and does not focus on the duration; hence it is faster. The team learns to size the story relatively and accurately over a period of a few iterations (sprints), thus improving the predictability (arrived through establishing consistent velocity over a period of few iterations) as well.  Planning Poker is commonly used as the planning exercise for the team to collaborate and size the stories. Planning Poker uses Fibonacci sequence to assign a value to the epic/feature/story. What is Fibonacci Series?  According to Oxford dictionary, Fibonacci Series is : “ a series of numbers in which each number ( Fibonacci number ) is the sum of the two preceding numbers. The simplest is the series 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 etc” The formula to arrive at a Fibonacci sequence is: Xn = Xn-1 + Xn-2 This sequence will be slightly modified when used in Agile estimations: typically, it will not have values beyond 100 and may have 0, ½, 1, 2, 3, 5,8, 13, 20, 40, 100. Some teams limit the highest value as 21 and use 0, 1/2, 1, 2, 3, 5, 8, 13, 21. Top 3 Reasons Why Using the Fibonacci Sequence Will Make You Better at Estimating Tasks  1. Weber–Fechner law: “The Weber–Fechner law refers to two related hypotheses in the field of psychophysics, known as Weber's law and Fechner's law. Both laws relate to human perception, more specifically the relation between the actual change in a physical stimulus and the perceived change. This includes stimuli to all senses: vision, hearing, taste, touch, and smell” Applying the law to Numerical Cognition,  “Psychological studies show that it becomes increasingly difficult to discriminate between two numbers as the difference between them decreases. This is called the distance effect. This is important in areas of magnitude estimation, such as dealing with large scales and estimating distances. It may also play a role in explaining why consumers neglect to shop around to save a small percentage on a large purchase, but will shop around to save a large percentage on a small purchase which represents a much smaller absolute dollar amount”  (source: https://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law) The Fibonacci sequence very well corresponds to Weber’s law. The values in the Fibonacci sequence are about 60% higher than the previous value, and hence applying relative sizing is much easier. It is very challenging to distinguish the size of two numbers which are adjacent to each other, by just looking at the objects. Let us take an example of a football and cricket ball. The approximate diameter of a cricket ball would be 2.8 to 2.86 inches whereas the diameter of a football would be 8.66 inches. It is easy to distinguish the relative size of these two (i.e., approximately the diameter of a football is 3 times that of a cricket ball). However, it is very challenging to distinguish between two cricket balls that vary 1 inch in diameter, unless you measure both. If you look at the Fibonacci sequence, the relative size between two adjacent numbers is more than 60% and this helps us to be able to size them accordingly.   2. Reflect Uncertainty The smaller value assigned from the Fibonacci sequence to a user story usually means that the story is well understood, and the user story follows INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) guidelines. Whereas the largest value denotes the story is not well understood or it needs to be broken down further. Smaller stories can be confidently estimated by the team in detail. A general practice from matured Agile teams is that the Fibonacci sequence is restricted up to 21 (0,1,1,2,3,5,8,13,21) and any story which is of size beyond 21 will have to be broken down further. This ensures that the team is not giving any room for greater uncertainty and good practice for the team to write better stories under the INVEST guidelines. 3. Comparison Though it is not mandatory to use Fibonacci sequence for story point estimations, the sequence is easier to understand and adoptable by the team. Individuals are better at comparison than estimation.  The easy sequence and distinguishable values of Fibonacci sequence helps to estimate by not measuring the objects but by comparison. How Does Fibonacci Agile Estimation Work in Practice?  When do you think is the right time for the Agile team to estimate user stories that are prioritized by the Product Owner in the product backlog? In my experience, I would say that the estimates (story point sizing) should happen during the Iteration/Sprint backlog grooming sessions. This gives the team the time to go through the user stories in detail, collaborate and mutually agree using the Planning Poker exercise.  Then what do we do in Sprint Planning? – This ceremony should be used to pick the stories from the product backlog (fulfils Definition of Ready), that can be completed within the iteration/sprint and then breakdown the stories into tasks and do one more level of estimation which is effort estimation denoted in hours. Let us say a team is assigned a task to estimate a reporting module to be developed: The team would agree that it is a difficult task to provide an effort estimation and it would take a longer time to complete; but how long will it take? Using Simple, Medium and Complex categorization would simply mean that the estimate falls into the Complex category; but how complex is it? Breaking down the requirement into granularized tasks, getting to the minute details and then arriving at an effort estimation would be a complex process and time consuming as well. Can the team take linear sequence (1,2,4,8,10,12,14,16….) and size them for a high-level estimation? Is it possible to size between 50 and 52? What can be defined as the highest scale? Using Fibonacci series helps the team to size the stories which have a distinguishable value and as discussed earlier, matured Agile teams use modified Fibonacci series and have highest scale of 21 to size a story. As discussed above, the Fibonacci numbers are 60% above than the previous number, and that helps in relative sizing. Summary There are various methods to estimate user stories, like T-Shirt sizing, Dot voting, Affinity Mapping etc. Story points is the widely used measurement for sizing the user stories. Fibonacci series helps the team to compare between two stories; and its very nature of distinguishable values helps them to fit the story into the right size that reflects uncertainties, which further helps the team to refine the story to remove those uncertainties. Hope this article was useful to you.
Rated 4.0/5 based on 13 customer reviews
5903
Why Do We Use Fibonacci Series for Estimation

In this article, my focus is on sharing my expe... Read More

PRINCE2®Agile vs PMI-ACP®: What’s Best for You?

Changing industrial trends and the mass adaptability of agile practices have transformed the way organizations work. Over time, a number of project management methodologies have cropped up to suit different industry needs, and today’s business leaders have a wide array of frameworks to rely upon. This has led to the inevitable need for skilled project management professionals who are well-versed in different frameworks. When it comes to the widely popular Agile methodologies, the presence of multiple certifications in agile / agile project management methods can seem overwhelming to aspiring professionals. This article will give you a comprehensive overview of PRINCE2®Agile and PMI-ACP® (Agile Certified Practitioner) certifications to help you make an informed choice. Project leadingWhat is a Project? Due to the accelerated pace of change, today’s enterprises have to cope with the complexities of emergent requirements over the course of a project. Strategic business decisions are often made after taking stock of competitors’ actions, technological advancements, regulatory changes, ongoing business developments and so on. In order to compete and thrive in the future, existing ways of working must be aligned to adapt to these evolving needs. Example: Today every bank across the globe offers innovative banking products and services like mobile banking applications, ATMs etc. These changes have been adopted to cater to the evolving expectations of customers while adapting to the latest technological advancements. Projects are the means of introducing change. A collective effort from different stakeholders needs to be pumped into the project initiatives to deliver the products and to accomplish the objectives within definitive timescales. Example: The Ministry of Health & Family Welfare of a country is planning to design, build, roll-out and implement a Health ID card system for its citizens within a year. This project will benefit the government and its citizens in various ways. Different organizations such as government, health ministry, hospitals, technology providers have to work collaboratively to implement the product within the identified timescale, cost and quality. Project Manager planningWhat is Project management? When different stakeholders come together to deliver a unique product within an estimated timescale and cost, there should be someone who needs to be accountable and responsible to manage the different aspects of the project.  Project management broadly revolves around key activities such as plan, execute, monitor and control. Management of projects is an art which includes skills like leadership, domain knowledge, interpersonal skills, people management, powerful communication, stakeholder engagement, conflict management, business acumen etc.,  Example: A central library run by a private firm is looking to launch a digitized version of its books. A Project Manager is identified to manage the scope, cost, time, quality, risks, resources, stakeholders, communications etc., from the beginning to the end of the project.  Project managers and their organizations can choose to apply the right methods, tools, techniques, standards, guidance, good or best practices to run their projects.  Why agile in project management?  As digital transformation is catching up with many organizations, business demands are also increasing, and the requirements for products and services is continually evolving as well. To meet the demands of businesses today, project-driven organizations should look for ways to increase the speed of product delivery while upholding quality. Agile project management is an iterative approach to delivering a project throughout its life cycle. The Agile framework helps project managers to stay on top of emergent requirements and adapt to change more readily, delivering products that are better aligned with customer expectations. With agile methods such as Scrum being widely accepted and used in today’s organizations for software development projects, more agility is seen in the delivery teams. Product development in Scrum teams occurs in shorter iterations/timeboxes (2 weeks to 4 weeks). This is because the goal is to deliver minimum viable products (MVP) or a feature/functionality within shorter sprints. Example: As a part of digital transformation, a school wants to launch a mobile app. In the beginning of the academic year, the first section of the app was ready and launched for use. During the launch, it only had a login and a digital diary feature. In the second month, they added a few more features such as timetable, attendance tracker. In the third month, new enhanced features such as progress card, online payment options were added. By the end of six months, the app had varied features to suit the needs of the school, teachers, students and parents and it added value to all categories of stakeholders iteratively.  The Contrast of Waterfall Vs. Agile ways of working:The Contrast of Waterfall Vs. Agile ways of working:The reason for agile’s popularity is because of its ability to address the new demands being placed on the project team.  Prince2 ProcessesWhat is PRINCE2®? PRINCE2® (PRojects IN a Controlled Environment) is widely considered the leading project management method. It is a unique, light weight, scalable, flexible, highly tailorable, principle-driven, agile enabled framework to run your projects.  PRINCE2 revolves around the concepts of principles (value statements), themes (focus areas to run the project) and processes (steps involved to accomplish project objectives).  Let’s get introduced to the PRINCE2 elements: Principles: Continued business justificationBusiness valueLearn from experienceLessons are sought, recorded and acted upon; continuous improvementDefined roles and responsibilitiesAll stakeholders representedManage by stagesProvides management control and realistic planning horizonsManage by exceptionAuthority delegation for directing, managing and delivering within tolerancesFocus on productsQuality-centric approach to planningTailor to suit the projectTailor to suit project environment, size, complexity, importance, risk, etc.Themes:Business CaseWhy?OrganizationWho?QualityWhat?PlansHow?, How much?, When?RiskWhat’s the impact?ProgressWhere are we now?Where are we going?Should we carry on?Processes:Starting Up A ProjectVerify whether the project is worthwhile and viable.Directing A ProjectDecision making, allocation of resources and estimating expenditure.Initiating A ProjectSetting up a firm foundation (controlled environment) for the project.Managing Stage BoundariesPreparation for management review including stage planning.Controlling A StageDay to day management of the work, issues and risk.Managing Product DeliveryProduct creation, delivery and acceptance.Closing A ProjectFinal delivery, acceptance and project evaluation.PRINCE2® Process Flow Diagram:PRINCE2® Process Flow Diagram:Processes are at the core of the PRINCE2 framework. Application of themes, principles and tailoring of the processes makes it easy to adopt and adapt which reduces the bureaucracy of project management. At the same time, it provides the proper governance to keep the projects justified.What is covered in PRINCE2 Agile™?Project EnvironmentIf PRINCE2® is already agile, what is PRINCE2 ® Agile? PRINCE2® Agile guidance is all about tailoring PRINCE2 to incorporate Agile methods. PRINCE2 is a neutral project management framework which can support both traditional waterfall projects as well as agile or adaptive or iterative projects.  To provide guidance on how to integrate high velocity models or practices into the existing projects for both IT and non-IT industries, PRINCE2 Agile considers Scrum, Kanban, Lean approaches. The intention is not to explain all the agile frameworks in detail; but rather is to show practitioners how to amalgamate PRINCE2 with other agile practices. PRINCE2 considers agile as a collection of behaviours, concepts, frameworks and techniques.   In a nutshell, PRINCE2® Agile is basically a marriage between PRINCE2 and Scrum practices.  PRINCE2’s core concepts of principles, themes and processes are tossed up with agile concepts, techniques, behaviours, practices which fuels more velocity into the existing framework.Certification: PRINCE2® Agile has two levels of certification (Foundation and Practitioner) Foundation Exam: Multiple choice 50 questions 1 hour to complete the paper Achieve 28 or more out of possible 50 marks (55%) to pass the exam Closed book exam Practitioner Exam: Multiple choice 50 questions based on project scenario 2 hours 30 minutes to complete the paper Achieve 30 or more out of possible 50 marks (60%) to pass the exam Open book exam. You can use the “AXELOS® PRINCE2 Agile™ guidance book”.  Certification Scheme: Prior project management experience is not required to take up the certification.  What is covered in PMI-ACP®? The Project Management Institute’s Agile Certified Practitioner is a credible certification which provides thorough knowledge to project managers using agile methodologies.  There are many agile practices other than Scrum that are widely used in the industry such as eXtreme Programming, DevOps, Test Driven Development (TDD), Behaviour Driven Development (BDD), Feature Driven Development (FDD), Crystal, Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Dynamic Systems Development Method (DSDM), Kanban, Lean Product Development etc., Most of these practices revolve around the core concept of iterations with other variations. Most of these practices are ‘IT-only’ frameworks.  Agile mindset and principles play a vital role in executing the projects in a different way as compared to the traditional ways. Right from covering the concepts of agile values, mindset, practices, terminologies, most of the above-mentioned agile models are covered in a greater detail in this program.  Concepts and techniques like agile contracting, agile risk management, earned value management (EVM), cumulative flow diagrams (CFD), estimation techniques, relative prioritization, work in progress (WIP) limits, Kano analysis, product backlog grooming, personas, user stories, story maps, wireframes, product road map, minimum marketable feature (MMF), definition of done, continuous integration, burn charts, stakeholder engagement, leadership, building agile teams, coaching, osmotic communication, timeboxing, planning poker, release planning, problem solving, lead time, cycle time, defect rate, control limits, throughput, velocity, variance and trend analysis, value stream mapping, continuous improvement, retrospectives, learning cycles etc., are imparted as a part of this certification course.Certification: 120 Multiple choice questions 3 hours to complete the exam Closed book exam Prerequisite: Secondary degree 21 contact hours of training in agile practices 12 months of general project management experience within 5 years.  8 months of agile project management experience within the last 3 years. Differences in these certifications:ParametersPRINCE2 AgilePMI-ACPTopics coveredIt is a blend of  PRINCE2® and Scrum.Spans across many approaches of agile.Governing bodyAxelosProject Management InstituteExam bodyPeoplecertPearson VUEExam modePaper-based test, computer-based test and Online proctored examOnline proctored examPrerequisiteNo prior project management experience is required. PRINCE2 Foundation or PRINCE2 Agile foundation certification is a prerequisite for taking up the practitioner exam.Secondary degree21 contact hours of training in agile practices12 months of general project management experience within 5 years.  8 months of agile project management experience within the last 3 years.Training4 days of training from an Accredited Training Organization (ATO) by Axelos3 days of training from a Registered Training Partner (REP) by PMICost of training & certificationApproximately Rs. 40,000 to 50,000Approximately Rs. 40,000 to 50,000Maintaining the certificationFoundation certification has a life time validity. Practitioners need to earn 20 continuing professional development (CPD) points every year.Earn 30 professional development units (PDU) every three years.Merits and demerits of both these certifications: Merits of PRINCE2® Agile:  PRINCE2 Agile provides a good governance model to run the project with guidance on how to incorporate any agile model.  It does not favour one agile approach over any other although Scrum is taken as a reference to explain the concept of tailoring.  It can be applied to any type of project and can easily be implemented alongside specialist, industry-specific models.  Demerits of PRINCE2® Agile:  It does not touch upon the various project management tools or techniques which are essential for project management. Merits of PMI-ACP®: It prepares the project managers to become versatile with different types of agile project management practices. Coverage of different types of tools and techniques polishes one’s ability to manage scope, cost, time, quality, risks, resources, stakeholders, communication etc. Demerits of PMI-ACP®: It does not have an exclusive body of knowledge (BOK) like PMBOK® guide. Reference to different literature and books may be essential. This means a structured way to agile project management is missing in its approach.  The best-suited certification: How to pick the right one? PRINCE2® Agile can benefit the existing PRINCE2® community, PRINCE2® Practitioners, anyone who is using agile in Project Management. Even organizations and individuals outside the PRINCE2® community, having experience with agile can benefit from this certification. It is also ideal for total novices. If you fall under any of the categories mentioned above, you can pick this certification as your first step in the project management world. This is also the right choice for professionals and enterprises that serve clients based in UK, Europe and Australia. PMI-ACP is a one-stop solution for project managers and agile teams keen on expanding their skill-set to manage various agile projects. If you are ready to dedicate at least 2 hours every day for 1 to 2 months for exam preparation and earn a globally recognized certification, go for it.  Conclusion: Every practice has its own strength and weakness. Ultimately, it is up to the organizations and practitioners to choose the right project management methodologies to suit their needs and business/career goals.  
Rated 4.0/5 based on 22 customer reviews
5934
PRINCE2®Agile vs PMI-ACP®: What’s Be...

Changing industrial trends and the mass adapta... Read More

"The Escutcheon Workshop" - PART 2 : Kanban Journey for the Infrastructure Operations Support and Service Teams

In my previous post, I had explained what is Kanban and how to view it in the context of Infrastructure Operations Support and Service .  Before we start the implementation of Kanban for a specific Operations Support and Service Team, we need to identify the team composition and work out its team structure. This will help us to implement Kanban effectively for the team. This process is known as team design and it is considered as a part of the organizational design (OD).  When we identify and form a team, we generally identify different support/service skills that the team should possess so that they can undertake the complete support/service for the customer. For e.g. if a single team is expected to provide network support services to the customer, the team should ideally have skills in L0, L1, L2, and L3 support. This ensures end-to-end support for the customer as a single ticket that can be resolved by one team instead of the customer depending on multiple teams (L2 – one team, L3 – another team and other multiple teams, where applicable) to complete his ticket and request. Each member identified at a particular level of support is skilled in their job and the skill level increases as the level move up. Each level has more experience and education. The different service levels are –  L0 – Basic resolution of issues through call resolution. Take the help of knowledge base to manage issue resolution.  L1 – Product Demo and basic troubleshooting including specific call resolution. Deal with physical connections and hardware. Basic network design - from about 30 to about 500 network point design. Basic project management skills.  L2 – Resolution of Technical problems. Focus on medium to large network design. 500 to about 2000 network point design. Intermediate project management skills.   L3 – Resolution of Major problems. Root cause analysis of problems with updations to the knowledge base. Design Experts and Data Center specialists with project management skills. Focus on 2000 to 30000+ network point design and familiar with high-end network equipment (CISCO/JUNIPER/Other Brands). The network support services could be in the form of network design, installation, support and maintenance. Additionally, the levels – L0, L1, L2, and L3 could vary in different organizations depending on the type of services being offered by the organization to the customer and the type of terminology used. We may also have additional or fewer levels depending on the focus of the organization. However, at a broad level, the above classification could be used to categorize different types of operations support and services in an organization. There are two types of team design that can be observed in an organization – teams that are exclusively made up of only one type of skill level, e.g. L2 support, L1 support. This is the component type team design.  Teams that are made up of the complete stack of support services provided – A single team having L0, L1, L2, and L3 skills. This is considered as the feature type team design where like a feature team, the operations support/service team provides complete end to end support to the customer (A feature team is a team that has all the skills needed to support the customer requirements and delivers the features to the customer). As organizations focus on agile and Kanban implementation for their teams and also emphasize imbibing the aspects of Spotify Engineering Culture (a culture that focuses on not having a hierarchical structure and which focuses on host and servant leadership), the attention is on forming teams that have end to end skills to resolve all the customer issues. Hence, the focus on full stack operations support/service teams.  Earlier, a team member used to have specific skills and built his skills in that area only, e.g. L2. This was the T type skill focus. Now, we have the PI type skill focus where a team member is expected to be an expert in at least two areas – e.g. L2, L1 and also have knowledge in other areas. It is acknowledged that there are constraints that need to be overcome to reach this level but it is expected that in the future, the demand will be for full stack skills (L0, L1, L2 and L3) from a single team member. This implies that a team member has all the skills necessary to deliver the service/support to the customer without having to depend on another member or wait to seek help from another member.  There are multiple constraints that need to be overcome in order to reach this state and organizations are facilitating this transformation that may happen over a period of time in the future. This will further strengthen the Operations support / service teams structure and delivery to the customer in the future.  After the skill matrix and the team members are identified to form a team, one of the members of the team is identified as a Kanban Master. He is responsible for facilitating the implementation of the Kanban practices and process for the team along with the help of other non-team members like an Agile Coach, Center of Excellence, Continuous Improvement team and other teams (e.g. training), where applicable.  Generally, we have an initial kick-off workshop for the newly formed team which I call as the Escutcheon workshop. An Escutcheon (as per the Oxford English Dictionary) is defined as –  An emblem or shield bearing a coat of arms or a flat metal piece that is used for protection and also ornamentation around a keyhole, door handle or light switch. The analogy with Escutcheon reminds us of the concept of the team subliminally forming a protective boundary for the team members and which helps the team members to undertake their daily work and take the help of other team members when stuck and ask for help when they are not able to resolve any issue. The team is also having a team name which gives an identity to the team, improves team bonding and which is similar to the coat of arms on a shield that bound fellow kinsmen during the olden times. The output of the workshop is also a diagram in the form of an Escutcheon. Hence, the term Escutcheon. This, of course, implies that the team members exhibit team member characteristics like trust, courage, transparency and other traits so that the concept of a team can be established and sustained in the future. Additionally, this does not mean that the team members can only ask for help from any other member within the team. They are free to also ask for help from any other member in the organization for additional ideas for issue resolution.  A typical output of an Escutcheon Workshop for a Network Operations Support / Service Team is given below -  Are you interested in learning more about Lean manufacturing? April 5th kicks off our Pull / Kanban System and Total Productive Maintenance Workshop! #TPM #PullKanban #Lean Learn more at https://t.co/I0gGUIU4UP pic.twitter.com/c6cfFI7WYx — IMEC (@IMECillinois) March 12, 2018 This network operations team is tasked to support network usage and monitor the performance of the network apart from other routine support / service activities. Hence, this becomes the important tagline or punchline of the team. The key words of the team focus on data, usage and performance (with respect to the network). The team emphasizes collaboration and creativity as key focus areas which will help them in their day to day activities related to network support and service, apart from other focus areas. The team calls themselves as “Network Tigers” and which is ready to support any network issue end to end within their scope of operation pertaining to network support and service. They adopt the logo of a Tiger Face which gives the team an identity to focus, bond and celebrate their successes and wins and support each other during lean periods.  Thus, the Escutcheon workshop helps the team to establish a facade (principal front face) to the customer as a single point of contact to help them for all their issues related to their network and help to resolve them end to end in the shortest possible time and with the highest quality. The team members keep improving their skills to meet this commitment to their customer and learn from their mistakes, adopt continuous learning and implement the lessons learnt from their projects to further strengthen their skills to match and exceed the customer expectations.  Hence, we have now established a full-fledged Operations Support / Service team having all the skill sets that are needed to address the queries, issues and tickets raised by the customer related to their network. Now the team needs to implement, establish, nurture, sustain and institutionalize Kanban values, principles and practices in their team to enable and facilitate the team to enhance customer delight and improve the quality of delivery.  In the upcoming Posts, I will focus on the next step in the Kanban journey as we learn how to implement Kanban for the Infrastructure Operations Support and Service teams – both at the team level and at the scale level (when we integrate multiple teams at scale to deliver support services to the customer).   
Rated 3.0/5 based on 1 customer reviews
"The Escutcheon Workshop" - PART 2 : Kan...

In my previous post, I had explained what is Kanba... Read More