Search

Trending blog posts

Filter

How To Be A Scrum Master On A High-Performing Team?

This might sound unfavorable for the Scrum Masters! If a team, more precisely, an Agile team is already performing well, what is the need for a Scrum Master at all? Such teams and their managers might dismiss the idea of a Scrum Master altogether. Therefore, to establish yourself as a Scrum Master in teams which were running fine without you can be more than just a challenge.  However, all you need is a few strong strides. A proper understanding of the Scrum Master necessities will help you create the place, your very own space, in successful Scrum teams. The main factors of a Scrum Master in a high-performing team should be clear to you, alongside the unique characteristics of Agile teams. Else, it might be difficult for you to convince the team members as to why they actually need a Scrum Master.    How to be a Scrum Master on a High-Performing Team https://t.co/2pGL0IUxL8 @LinkedIn #agile #scrum #teams — The Working Report (@WorkingReport) 2 November 2017   Characteristics of high-performing teams: The high-performing team should be able to define a team purpose. The high-performing team takes an individual and mutual accountability of the result obtained by the team as a whole. The high-performing team produces a project output collectively. The high-performing team does open-ended discussions and has excellent decision-making capacity. The high-performing team moves with the points discussed in the daily Scrum. Team members should be constructive at every decision produced by other team members. This will eliminate conflicts among the team members.   They should see you as an enabler who can spearhead functional Agile teams.  Here is a whole new slew of hacks to explore new ways to make the best out of such teams- 1.Providing a fresh perspective every time: Being an entrant as a Scrum Master in the high performing team, you need to catch up with the details of the organization’s working processes for the sake of you and of course, the team. For acquiring the details from the team (and also about the team), the new Scrum Master should ask some questions to the teammates.This would help him/her learn what the team is following to accomplish a task. Consider one example of a simple question this Scrum Master can ask the team- Why do we work on several user stories and progressing bugs at the same moment?  Very simply, the team members responded that once they finish one task they start the next.  This works, but at times, results in a testing bottleneck. It can be successful if we limit the number of progressing tasks. You have to ensure that the ratio between the tasks in development and testing stages can be managed at all times. This will give you an enhanced productivity.  While gathering the project requirements from the client, a designer can work with the Product Owner and transform the project requirements into visual designs. The Scrum Master can provide a fresh perspective every time on the graphics and workflows to ensure a better performance.    2. Checking daily status: At an entry level, the Scrum Master feels himself/herself as a secondary option in the team especially when he/she is not aware of the team and their working approach. In this case, a Scrum Master has to play a trick to get into the game. But how? Firstly, Scrum Master can keep a record of the daily status of the team members in following ways: How is each team member doing? Stress levels Whether they are individually fit or not Whether team is following Scrum framework properly This will help you understand the team members and their current status.   3. Get ready to help the team personally:   Simply checking on the daily status is not enough, being a Scrum Master. Also, calling out orders at the team without keeping any idea of. the present position won’t work. In order to become supportive, the Scrum Masters need to get involved in the high-performing team. They can support QA (Quality Analysis) team in testing the applications in order to build an even higher performing team.  Scrum Master can act as a third eye in finding out flaws in developer’s attention,  Specifying Scrum team roles    Covering the areas which the team may have missed Giving (the team) an opportunity to convey useful ideas to the Scrum Master 4. Manage the backlog: One of the Scrum Master’s roles and responsibilities involves discussing with the Product Owner and the project stakeholders regarding their requirements. Once the designs are created, the Scrum Master can create a list of high-level user stories and add them to the Product Backlog items for use during Product Backlog Refinement sessions.  The Product Backlog should be split into the sections, well-organized and easy to implement. This will furnish the team with a proper visibility towards their work without jumbling up the requirements. 5. Tracking action items during Retrospectives: Retrospectives provide the best way for the Scrum Master to ask questions and unearth the needful. The Scrum Master in the high-performing team can introduce new retrospective techniques after every alternate sprint, which can keep the processes running smoothly. Most importantly, these techniques will help the Scrum teams to- Inspect the team and the processes Discuss healthily Raise the new ideas Pull out action items during discussion This will allow a Scrum Master to remind the team about their incomplete tasks, and also the accomplished tasks weekly.     6. Rejoice in the team success: Scrum is simple, but hard to execute. So it is always recommended to celebrate the success whenever it comes. This will help the team to stay focussed on their target and connect the points between work and target. If the team is high-performing, then being a Scrum Master it is your duty to shout their successes to keep the team more engaged.     Last Words- It is not more important that the team should consist of the ‘high-profile individual’ rather than their actual working. Culture plays a vital role in team performance. If there is a defined culture, it will be easy for the team members to follow suit. In case you are using the Scrum framework, firstly ensure that your team knows Scrum. Secondly, the team should follow a proper working culture under the guidance of the Scrum Master. Yes, definitely, an efficient one!   
Rated 4.0/5 based on 9 customer reviews

How To Be A Scrum Master On A High-Performing Team?

1200
How To Be A Scrum Master On A High-Performing Team?

This might sound unfavorable for the Scrum Masters! If a team, more precisely, an Agile team is already performing well, what is the need for a Scrum Master at all? Such teams and their managers might dismiss the idea of a Scrum Master altogether. Therefore, to establish yourself as a Scrum Master in teams which were running fine without you can be more than just a challenge. 

However, all you need is a few strong strides. A proper understanding of the Scrum Master necessities will help you create the place, your very own space, in successful Scrum teams. The main factors of a Scrum Master in a high-performing team should be clear to you, alongside the unique characteristics of Agile teams. Else, it might be difficult for you to convince the team members as to why they actually need a Scrum Master. 
 


 

Characteristics of high-performing teams:

  • The high-performing team should be able to define a team purpose.
  • The high-performing team takes an individual and mutual accountability of the result obtained by the team as a whole.
  • The high-performing team produces a project output collectively.
  • The high-performing team does open-ended discussions and has excellent decision-making capacity.
  • The high-performing team moves with the points discussed in the daily Scrum. Team members should be constructive at every decision produced by other team members. This will eliminate conflicts among the team members.

 

They should see you as an enabler who can spearhead functional Agile teams. 

Here is a whole new slew of hacks to explore new ways to make the best out of such teams-

1.Providing a fresh perspective every time:

Being an entrant as a Scrum Master in the high performing team, you need to catch up with the details of the organization’s working processes for the sake of you and of course, the team. For acquiring the details from the team (and also about the team), the new Scrum Master should ask some questions to the teammates.This would help him/her learn what the team is following to accomplish a task. Consider one example of a simple question this Scrum Master can ask the team-


Why do we work on several user stories and progressing bugs at the same moment? 

Very simply, the team members responded that once they finish one task they start the next. 

This works, but at times, results in a testing bottleneck. It can be successful if we limit the number of progressing tasks. You have to ensure that the ratio between the tasks in development and testing stages can be managed at all times. This will give you an enhanced productivity. 

While gathering the project requirements from the client, a designer can work with the Product Owner and transform the project requirements into visual designs. The Scrum Master can provide a fresh perspective every time on the graphics and workflows to ensure a better performance. 
 

2. Checking daily status:

At an entry level, the Scrum Master feels himself/herself as a secondary option in the team especially when he/she is not aware of the team and their working approach. In this case, a Scrum Master has to play a trick to get into the game. But how?

Firstly, Scrum Master can keep a record of the daily status of the team members in following ways:

  • How is each team member doing?
  • Stress levels
  • Whether they are individually fit or not
  • Whether team is following Scrum framework properly

This will help you understand the team members and their current status.  


3. Get ready to help the team personally:



 

Simply checking on the daily status is not enough, being a Scrum Master. Also, calling out orders at the team without keeping any idea of. the present position won’t work. In order to become supportive, the Scrum Masters need to get involved in the high-performing team. They can support QA (Quality Analysis) team in testing the applications in order to build an even higher performing team. 

  • Scrum Master can act as a third eye in finding out flaws in developer’s attention, 
  • Specifying Scrum team roles   
  • Covering the areas which the team may have missed
  • Giving (the team) an opportunity to convey useful ideas to the Scrum Master


4. Manage the backlog:

One of the Scrum Master’s roles and responsibilities involves discussing with the Product Owner and the project stakeholders regarding their requirements. Once the designs are created, the Scrum Master can create a list of high-level user stories and add them to the Product Backlog items for use during Product Backlog Refinement sessions. 

The Product Backlog should be split into the sections, well-organized and easy to implement. This will furnish the team with a proper visibility towards their work without jumbling up the requirements.


5. Tracking action items during Retrospectives:



Retrospectives provide the best way for the Scrum Master to ask questions and unearth the needful. The Scrum Master in the high-performing team can introduce new retrospective techniques after every alternate sprint, which can keep the processes running smoothly. Most importantly, these techniques will help the Scrum teams to-

  • Inspect the team and the processes
  • Discuss healthily
  • Raise the new ideas
  • Pull out action items during discussion

This will allow a Scrum Master to remind the team about their incomplete tasks, and also the accomplished tasks weekly.  

 

6. Rejoice in the team success:



Scrum is simple, but hard to execute. So it is always recommended to celebrate the success whenever it comes. This will help the team to stay focussed on their target and connect the points between work and target. If the team is high-performing, then being a Scrum Master it is your duty to shout their successes to keep the team more engaged.

 


 

Last Words-

It is not more important that the team should consist of the ‘high-profile individual’ rather than their actual working. Culture plays a vital role in team performance. If there is a defined culture, it will be easy for the team members to follow suit. In case you are using the Scrum framework, firstly ensure that your team knows Scrum. Secondly, the team should follow a proper working culture under the guidance of the Scrum Master. Yes, definitely, an efficient one! 

 

KnowledgeHut

KnowledgeHut

Author

KnowledgeHut is an outcome-focused global ed-tech company. We help organizations and professionals unlock excellence through skills development. We offer training solutions under the people and process, data science, full-stack development, cybersecurity, future technologies and digital transformation verticals.
Website : https://www.knowledgehut.com

Join the Discussion

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

Suggested Blogs

The Ultimate Guide to Sprint Planning

The Scrum framework has been popular lately and several studies have provedthat the global share of Scrum is more than 50%. One of the reasons for the phenomenal success of Scrum lies in its ceremonies, one of its key pillars.  Scrum has three critical components that create the structure or a skeleton and provides a way of working to the teams and individual, namely, roles, artifacts, and ceremonies. crum roles, artifacts and ceremoniesScrum has four different ceremonies to support Agile software delivery where the Sprint starts with planning and ends with the retrospective. Let us quickly talk about the four ceremonies and then we will start with our topic of the day and deep dive more into Sprint planning. Daily Scrum The event is intended to bring together everyone in the scrum team and talk about what the accomplished last, what is the plan for today and is there any impediment. This event can be categorized under daily planning and collaborative team effort to attain the scrum goal. Sprint planning This event occurs at the start of the Sprint where the team together decides on the Sprint backlog and gains consensus on the sprint goal. They also talk about the estimation, capacity, risk, dependencies, and the timeline. This event is facilitated by the scrum master and occurs once in every Sprint. Sprint review This is the second last event in the print where the team showcases the entire deliverable they have been working throughout this print. This is the time when the stakeholders look at the finished product and provide their feedback. The event provides an effective platform for a collaborative approach with the client towards software delivery. Sprint retrospective This is one of my favorite events in Scrum, though the ceremony looks simple, if done correctly, it can yield tremendous results. It provides the team with a chance to pause and check which things are working, what is not, and how can they improve moving forward. Scrum ceremoniesEach of the ceremonies can be elaborated more as they are deep and dense. This article serves as an in-depthguide on Sprint planning for Scrum practitioners. The Sprint Planning meeting The What Sprint planning can be thought of as a ‘green flag’ that gives a go-ahead to the train called “Sprint”. The purpose of this meeting is to provide the sprint goal and ‘how’ that can be delivered. This is the first meeting that takes place in a Sprint where the scrum team comes together to create the Sprint backlog within a “time-box”, this time-box depends on the iteration length, if the iteration is of two weeks, the time-box can be up to four hours for a team of seven to nine people.  During the Sprint planning meeting, the product owner describes the objective of the sprint and what product backlog items can be utilized to reach that objective. Consequently, the scrum team decides how to work on ‘how’ to get the goal achieved. The How The sprint planning meeting is divided into two parts, first part, constitutes discussion on the sprint backlog creation and the second part revolves around the capacity and estimation. The product owner must keep the product backlog stays in a healthy state, it is prioritized and has the right requirements for the team to work on. The team should also be aware of their capacity and velocity to make appropriate Sprint commitment. Spring Planning meeting agendaThe Who The spring planning meeting is attended by the product owner, the development team, and the scrum master. All three roles are mandatory to run this meeting.  The product owner defines the objective of the sprint and supports the development team with the product backlog. In turn, the development team talks about ‘how’ to deliver and the approach they could take. They can also inform the product owner if the requirement is not doable (at times, the requirements might not be technologically feasible, in such cases the team can discuss the same with the product owner). The Scrum Master takes up the facilitation of the event, they make sure the team sits with an effective ‘input’ and comes out with an efficient ‘output’. The Inputs The Product Backlog serves as the ‘Input’ for the Sprint Planning meeting. It provides the development team with the starting point as it contains the list of requirements for delivery. The Product Backlog is owned by the product owner and hence the responsibility of keeping it up-to-date falls within their purview. The team starts with the highest priority item in the list, clear doubts (if any) and add it up to the Sprint Backlog. To make proper sprint commitment, the team should know their capacity and velocity. The Outputs The sprint planning meeting intends to generate a sprint goal and backlog. The output also defines the ’how’ approach, which the team will take to reach its goal. The team must understand the value of this event, as this draws a path for sprint success. The Scrum Master can help the team and the product owner to come up with an effective plan through their facilitation skills.Input and output of the Sprint Planning MeetingHow do we prepare for the sprint planning meeting? As with other events, the sprint planning meeting has a set agenda and timebox which the team must follow diligently. A healthy backlog is a key to efficacious sprint planning, which means, the Product Owner always must maintain and keep the backlog updated. The team needs to be aware of the available capacity and the targeted velocity this helps in coming up with the correct commitment during the Sprint planning session. What is a backlog? A backlog is a list of requirements from the client to create the desired product. It contains new features, enhancements, bugs, Infrastructure changes, or any architectural requirement. Any work that is related to a product should be in the backlog.  Backlog items are placed in a prioritized list manner Every item in the backlog has an estimate it can either be a high-level estimate or the exact/close estimate, depending on where it falls in the list. Usually, the top few items in the bucket have more clarity, details, and close estimates as compared to the items down in the list. Determining velocity Velocity is unique for every team; no two teams can have the same velocity. Every organization has a different approach towards velocity, ideally, the teams should take an average of the last five sprints. The average formula works for the teams who have been in the system for long or they have spent at least eight to ten sprints as a team.  Usually, velocity-based planning is done with mature teams who are aware of the product and they are good at process. With new teams, the ideal approach relies on the completed stories vs accepted stories ratio. Determining capacity Capacity is determined by available working hours in the sprint timeline which also takes into consideration, the leaves, any holidays, and contingency hours (if required). Capacity directly impacts the output as a team and helps them during Sprint commitment.  Sprint Planning checklist While Agile development is more of a mindset than a methodology, checklists can help guidetheproduct owner, the development team, and the scrum master as they plan and execute sprints. Sprint planning preparation A few days out from the actual sprint planning meeting: Review product roadmap and vision.  Ask team members to update boards and focus on moving tickets to done.  Run sprint review and retrospective.  Groom product backlog: Make sure every user story has a clear priority, is fully formed, and up to date with context and estimates.  Choose sprint goal.  Create a sprint backlog of enough user stories to fill two sprints. Sprint planning meeting Ensure your entire team is present for the meeting.  Start video call for remote team members.  If needed, clean up old board(s) with team by checking status of open tickets.  Discuss spillovers: Should these be continued or dropped? Move any spill-over tasks into the right buckets.  Set the stage with product and market updates.  Define the sprint goal.  Create a “new sprint”. Discuss the goal and team’s capacity:  Is this realistic? If not, can the team lower the scope?  Worst case scenario the product owner needs to come up with a new sprint goal. A few days out from the actual sprint planning meeting: Discuss proposed sprint backlog: Let the team pick user stories and tasks that match the sprint goal and capacity.  Discuss the definition of “done”.  Break down each user story into individual tasks: Make sure each task has as much information as possible.  Ask whether the scope of work leaves time for unexpected issues.  Ask if the scope of work leaves space to tackle bugs and technical debt.  Move sprint backlog of decided-upon user stories and associated tasks into the sprint board.  Get verbal confirmation from the team that they know what to do.  Set up due dates and times for future scrum meetings.Here is a quick checklist to help you plan the Sprint Plan. You can modify and adapt as necessary.The outcome of the Sprint Planning meeting The planning meeting intends to come up with Sprint goal and sprint commitment which is in the form of Sprint backlog. This backlog contains a list of stories, bugs, enhancements, etc. as required by the product owner. The output of the Sprint planning meeting is also to define the approach, the task, and other activities required to achieve the Sprint goal.  Everything that needs to be done is part of the Sprint backlog, by the end of Sprint planning meeting the team should have a solid plan with the ownership This output is further shared with the stakeholders, management and within the team which not only helps in being transparent but it also supports the team to stay focused. How to get Sprint Planning right Scrum focuses on time boxing and hence Sprint planning also requires control over the time limit for the event. As per the industry standards, a sprint of two weeks should be time-boxed for a maximum of 4 hours. The scrum master is responsible for making sure the team sticks to the timing and helps them in coming up with the plan. Spend planning can be an exhaustive ceremony where the team brainstorms, discusses the requirements and ownership.  With great facilitation skills, the scrum master can ask the team to start with an item they know well and subsequently move forward. The team can utilize various estimation techniques to define a number or a story point for each requirement. They can use T-shirt sizing, poker planning, or any other technique they are comfortable with. For effective estimation, the team needs an environment that is transparent, trustworthy, and open to new ideas. This reminds us of the Scrum values and principles that form the foundation of the framework. Common reasons why Sprint Planning fails Multiple reasons can contribute to scrum planning failure. Let us look at some of the frequent cases: Uncooked backlog Most of the time the product backlog is not up to date and lacks prioritization. In such cases the team struggles in defining the Sprint goal, they face difficulties in defining the Sprint commitment due to lack of clarity and details. Unrealistic expectations Oftentimes teams are required to work on requirements that are not feasible, or the team faces some technological challenge. Over-commitment When the teams do not realize the capacity and their velocity and tend to over-commit, this leads to hurdles in delivery. Beyond Time-box Spending too much time in Sprint planning can also jeopardize the event, the team must follow the time-box, going over minute details is not required. Scrum is an empirical process, which means You do not have to plan everything upfront.   Quick tips for success Set a Goal The Product Owner should come up with a sprint goal and share it with the development team. The goal helps the team and staying focused throughout the sprint, they can also use baby scrum meeting to check if they are on track with the goal. Healthy product backlog If the product backlog is in the Good shape, and has stories in order of priority, the team can start pulling from the top. they can even plan a pre-planning meeting, which is also known as backlog grooming who defines the upcoming sprint backlog. Valuable meeting measures Everyone in the team should have the sprint planning meeting invite and if required it should contain the link to video conferencing in-case of a distributed team. The team should have the data on capacity and velocity, and they understand estimations and prioritization. They can use different colored stickies to represent backlog items for example stories can be represented with green and bugs can be presented with red. As per the discipline, the team should follow timeboxing strictly, they can finish early but to go beyond the time is not recommended.  Best practices in Sprint Planning To course a positive sprint, you need to be very prepared and have a solid understanding of what is practicable to shape with the team you have within the timebox. This is the reason why a sprint planning session is so vital for placing the foundation for an agile development project. Let us touch base on some best practices that the teams can adopt for the smooth running of the scrum event. Strategy for uncertainties During the sprint planning meeting, the team talks about capacity, velocity, and shapes their Sprint commitment around the confident items. Planning for uncertainties not only helps in contingency but it also reduces the upcoming risk that can pose an impediment for the team. Sprint skeleton Laying out the stories or Sprint items in the form of a map helps the team in getting a tentative idea around each deliverable. this also helps in defining the internal dependencies and the teams can better plan by moving them up and down. Building consensus It is important to get the team onboarded together as a single group for the sprint goal. They should understand the importance and the urgency of the deliverable and they are ready to take the ownership, this also requires supporting the teammates. Benefits of Sprint Planning A successful Sprint planning creates a smooth runway for the team to start their work. It provides clarity in terms of commitment, goals, timelines, and ownership. The output of the Sprint planning meeting sets an expectation with both the parties - the scrum team and the stakeholders - on what to expect by the end of the Sprint. It can be visualized as the team pulling a bucket of work from a big pile and focus on delivering that bucket with expected quality. Ready, set, sprint! “A goal without a plan is just a wish.” - French writer and pioneering aviator, Antoine de Saint-Exupéry Done in the right spirit, Sprint planning can do wonders in sprint delivery. All it requires is a focused approach, discipline, few best practices, and a collaborative approach towards a solution.  If you have followed this guide, at the end of your sprint planning session you and your entire team should walk away with: An agreed-upon Sprint Goal and a clear definition of “done” Commitment to a realistic sprint backlog Understanding of the bug fixes and support work included in the backlog Detailed tasks for each user story with an estimation and acceptance criteria Due dates and scheduled scrum meetings Now, all you have to do is the work.Ready to start or grow your Agile career?  Check out our latest courses, learn the skills and get the personalized guidance you need. 
Rated 4.0/5 based on 13 customer reviews
The Ultimate Guide to Sprint Planning
Blogs
6722
The Ultimate Guide to Sprint Planning

The Scrum framework has been popular lately and se... Read More

Key Insights from the 2020 State of Agile Report

How are agile businesses changing in 2020?  Digital.ai, the creator of the industry’s first intelligent Value Stream, recently published its 14th Annual State of Agile Report, along with a survey addendum to reflect the current 2020 landscape. The report took a look into the enterprise, what Agile techniques companies are implementing, their benefits, and what’s trending. The report provides the most comprehensive data in the world to benchmark your Agile practice and plan your next wave of expansion. The survey documents the experiences of more than 1,100 business and IT professionals across a range of industries and roles worldwide.  About 40,000 Agile practitioners, consultants, and executives have shared their insights to make this the longest-running and largest report of its kind. For the first time, it revealed insights beyond the general results by filtering the results along the demographic lines. The analysis indicates a correlation between the time practicing Agile, the ability to manage the changing priorities, and improved time to market.  In this article, we give you the complete lowdown on the state of Agile in 2020 including the COVID-19 impact and what’s next in Agile. Agile in numbers Let us explore the top responsesto the survey in numbers. Respondents answered their top reasons for implementing Agile techniques, which techniquesand methodologies they employ the most, what tools they recommend most, and the top benefits of using Agile. Top five reasons for adopting AgileTop five benefits of adopting agileRespondents were asked why their teams adopted Agile methodologies and techniques. These were the most responded benefits: Accelerate software delivery (71 percent) Enhance the ability to manage changing priorities (63 percent) Increased productivity (51 percent) Improve business/IT alignment (47 percent) Enhance software quality (42 percent)  This year, the reasons for implementing Agile were more about reducing project risks as opposed to reducing project costs.Top five Agile techniques employedThese are the five most used tactics that help teams adhere to the twelve principles of Agile.Top five Agile techniques employedThe Daily Standup was the most common Agile technique used in organizations. The most notable changes from last year was a decrease in Release Planning (51 percent this year as opposed to 57 percent last year) and an increase in Product Road Mapping (49 percent this year as opposed to 45 percent last year). Top five benefits of adopting AgileTop five benefits of adopting AgileWe see that the top five benefits of adopting Agile are built around speed and adaptability. Project Cost Reduction was last on the list with only 26 percent of the respondents considering it to be the benefit of Agile implementation. Top five Agile methodologies Top five Agile methodologiesThe survey shows that Scrum and its variants are the most common methodologies used for Agile implementation. 3 percent of the respondents didn’t have any idea of the methodology used by their organization.  Top five Agile project management toolsTop recommended project management toolsRespondents were asked if they would recommend the tools on the basis of their experience. Atlassian JIRA and VersionOne were the most recommended tools. Five critical takeaways from the 2020 State of Agile Report Many organizations still learning to adopt AgilePercentage of teams using AgileThe survey showed that only 18 percent of the organizations implemented Agile for all the teams. 77 percent of the organizations had still not implemented Agile in all the company’s teams. With 5 percent of the organizations yet to adopt Agile, there is clearly plenty of area for growth. Agile maturityWhile 95 percent of organizations have some form of agile process in place, practice maturity and adoption remain a work in progress. Around 50 percent of respondents report that less than half of their teams are using agile, and 84 percent acknowledge that their organizations are below a high level of competencies.  Areas other than software development yet to take advantage of AgileAreas of organization practicing AgileAgile practices are not limited to software organizations. The survey data showed that while Software Development continues to be the major area for Agile adoption, other areas like IT and Operations have also started adopting the methodology. Other areas in the organization are yet to take advantage of everything the Agile approach has to offer. More business outcome KPIs, fewer metrics As per the respondents, accelerated delivery speed is the most critical measure of the success of Agile initiatives. Next is improved quality, followed by reduced risk and increased customer satisfaction. Reduced IT costs is low on the spectrum with just 39 percent considering it as important for measuring success.  How success is measured in Agile transformationsAgile success and metricsWhen asked how organizations measure success of Agile transformations, the top measures of success were consistent with those reported over the last few years. Outcomes, customer satisfaction and business value, ranked higher than outputs like on-time delivery and productivity. The survey results for this section remain consistent over the past few years. There might be some ups and downs. But overall, Customer Satisfaction and Business Value are at a higher rank than productivity and on-time delivery. How success is measured in individual Agile projectsAgile success and metricsAs with Agile transformations, business value delivered, and customer or user satisfaction remained the top two cited measures of success within for individual projects.  Scaling Agile faces culture challengesMethods and approaches of scaling AgileAbout one-third of respondents are applying the Scaled Agile Framework, roughly another third are using other scaling frameworks, and another third stated they didn't know/other. There appear to be several common challenges scaling agile as over 40 percent of respondents cited six different challenges/barriers with adopting and scaling agile practices. These included: resistance to change, lack of leadership participation, inconsistent processes, misaligned organization versus agile values, inadequate management support, and insufficient training.    Challenges experienced when adopting and scaling AgileEnterprises are adopting the framework at a remarkable rate that shows that companies want to get the benefits of a structured framework included in the Lean/Agile BoK of SAFe.  The lack of qualified professionals also remains one of the common challenges with insufficient leadership participation (46 percent) at number 2 and lack of experience or skills with Agile methods (41 percent) at number 6.  The report also shows that culture is at the primary target of change as it affects the thinking and working of the organization. Agile organizations slowly adopting DevOps DevOps practices are a strong partner to agile methodologies, and 69 percent of survey respondents stated that DevOps transformation was either important or very important to their organization. But adoption of DevOps practices lags its important with only 55 percent employing continuous integrations and 41 percent continuous delivery. Only 36 percent practice continuous deployment. The top two benefits targeted are accelerated delivery speed (70 percent) and improved quality (62 percent). But respondents are tackling quality first with 67 percent implementing unit testing and 58 percent coding standards, even higher engineering practices over the 55 percent on continuous integration.  More than half of the respondents reported that their organization was already implementing Value Stream Management (VSM) or have plans to do so. VSM is a combination of people, technology, and processes that maps, measures, optimized, visualized, and governs the business value flow using a heterogeneous enterprise delivery pipeline.  Each level of automation requires investment and additional work to prove its robustness. There are seven prerequisites before improving release frequencies, and that requires investment in aspects of these seven DevOps practices. Even so, there are questions DevOps teams should answer before increasing deployment frequency. Summary of key insights Currently, the Agile approach is predominantly implemented in the software or information technology sector. The benefits an organization can reap once Agile is implemented in other areas as well would be tremendous. Here is a quick summary of key insights from the report: Cost reduction is not anymore one of the primary reasons to adopt the Agile approach. Identifying technical risk before deployment is considered very valuable by 34 percent of the respondents, which was 22 percent last year. Greater Agile maturity is correlated to the time of practicing Agile. The length of time since Agile adoption is also related to the increased ability to manage the changing priorities and improved time market. Organizations that have practiced Agile for more than 5 years have a greater percentage of DevOps initiatives and interest in Value Stream Management.  Companies with 20,000 or more people are more likely to have been using Agile for 5 or more years. Companies with less than 1,000 people correlated to a higher percentage of all their teams implementing the Agile approach.  More than half of the respondents stated their companies are either implementing VSM or have plans to do so.  Risk and compliance increased by 54 percent to be the top value to identify and measure technical risk before the deployment begins. SAFe is the most popular scaling method, increasing 5 percent over the last year. There was a shift in Agile techniques as release planning decreased by 11 percent while product road-mapping increased by 9 percent. This change can be attributed to the increase in CI/CD and better program increment planning. Currently, Agile is mainly confined to software development, operations, and the IT sector. However, it is expected that by next year, the organization will expand agility into areas beyond developing, deploying, and maintaining software solutions. The COVID-19 impact and what’s next in Agile The COVID-19 pandemic has triggered a health emergency worldwide. Leaders across industries are moving promptly to protect employees and build resilience, as the impact of the crisis continues to mount. In mid-May 2020, Digital.ai conducted a brief supplemental survey of respondents to learn more about how the COVID-19 pandemic has affected their Agile adoption. Supplemental findings reveal that: 55 percent say their company plans to increase the use of Agile in the next 12-14 months. This is an increase of 13 percent over the original survey completed just five months ago. 43 percent of organizations say their momentum for Agile adoption has increased over the past 90 days, with 15 percent saying it has increased significantly. 33 percent say they increased or expanded Agile adoption in the last 90 days to help manage distributed teams. In summary, forecasters continue to predict how long the COVID-19 crisis will last, but it seems inevitable that many organizations will be working remotely for the foreseeable future.Implemented correctly, an agile approach can help remote teams function effectively and build resilience for the future.  Following the pandemic, working from home more frequently (perhaps 2-3 days per week) may become an accepted norm for many companies, as this could realize cost efficiencies and prove that an agile, remote working model is productive.
Rated 4.0/5 based on 16 customer reviews
Key Insights from the 2020 State of Agile Report
Blogs
7046
Key Insights from the 2020 State of Agile Report

How are agile businesses changing in 2020?  Digit... Read More

Agile Project Management: Best Practices and Methodologies

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 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.  Agile 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
Agile Project Management: Best Practices and Methodologies
Blogs
6535
Agile Project Management: Best Practices and Metho...

Agile is an iterative and incremental solution dev... Read More

Series