Agile Thoughts

Scrum is a popular agile method based on its flexibility, adaptability, and effectiveness in delivering value quickly and continuously on a project. The Scrum framework excels in comparison to traditional project management methods in the way risks are intrinsically minimized throughout the entire lifecycle. All projects are impacted by some form of risk, whether it be negative (threats) or positive (opportunities). The goal is to maximize the impact and probability of positive risks and to reduce or eliminate negative risks. This article focuses mainly on negative risks. Most projects begin with high levels of risk because of a large number of uncertainties. The Scrum framework has built-in benefits that help to keep the impact of risks at very low levels. Scrum practices inherently mitigate risk based on the following characteristics of the framework:

1. Adaptability – Risks are minimized through Scrum based on the principle of adaptability.  This means that requirements can be changed and/or added at any time in the project. This flexibility results in the ability of an organization to adequately respond to threats and opportunities when priorities change. It is a fair assumption that priorities will change on projects. The cost of addressing these changes is very low and the process is faster when compared to traditional project management. To be clear, changes and additions to requirements are not added: “just because”. This adaptability to change is implemented only in cases when the additional value can be provided to the customer.
2. Transparency –Information radiators such as burndown charts and Scrum boards provide needed transparency when compared to traditional methods where only the project manager has access to the project schedule.  The consistent status of the project is available and all team members and stakeholder are kept “in the know”. The Scrum principle of transparency ensures that risks are identified and communicated continuously. This results in effective risk mitigation. The Impediments Log or Risk Register (managed by the Scrum Master) tracks all risks on the project and is available to the Scrum team and stakeholders.
3. Continuous Feedback – Due to the iterative nature of Scrum, the framework provides opportunities to get feedback throughout the project. During the Daily Standup meeting, impediments and risks are addressed on a consistent basis. The entire Scrum team is made aware of all potential risks that could impact the project on a continuous basis. This results in effective risk mitigation and surprises are effectively kept to a minimum. The Sprint review and Demo meeting is another opportunity to get feedback on the product. During this ceremony, the Scrum Master, Scrum Team, Product Owner and stakeholders review the product increment by means of a demonstration of all user stories in the Sprint Backlog. The Product Owner accepts or rejects user stories based on whether the acceptance criteria have been met. A user story may also be rejected if it needs a modification based on new information realized during the product demo.
4. Continuous Improvement –Another benefit of implementing Scrum are the retrospectives that take place at the end of every Sprint and at the end of the project. The purpose of the “retro” is to examine the team’s processes and determine what worked; what did not work; and what needs to be included going forward for the team’s processes. The Scrum team then decides together as to which processes or actions need to be addressed by the next Sprint. This is where improvements are made on a continuous basis through retrospectives.
5. Iterative Delivery – Business-value on the Scrum project is continuously delivered as opposed to “at the end” as with traditional project management methods. This results in risk reduction for the customer’s investments. The project deliverables are progressively improved during each (iteration) Sprint. This reduces risk to the product increment if changes need to be reversed. The development team will easily know which Sprint increment needs to be addressed.
6. Scrum Team Ownership - The Scrum Team is responsible for estimating the Sprint Backlog. This leads to more precise estimation and timely delivery of the product’s increments. There is no one better than the Scrum team to estimate the work. This results in the reduction of estimation risk.
7. Risk-Adjusted Backlogs - The concept behind this type of Product Backlog is the focus on delivering the highest value features and high-risk items that have been identified to be top priority work. This helps the team to deliver and mitigate the large impact risks to the project as early as possible. We know that risk represents anti-value and to deliver value, we must minimize risk.
8. Risk-Based Spike – This type of spike is experimental and is used to identify the types of risks and their impact on a project. A risk-based spike is implemented before the project commences and can be used by the team to get accustomed to new technologies or tools needed for develop the product. Estimation uncertainties are also investigated during this time or in cases where a user story is unclear. This event is typically time-boxed for two to three days.
9. Risk Burndown Charts – Identified risks can be identified and managed by means of a risk burndown chart. This type of chart depicts the status of risks over a period (weekly, monthly, etc.) and shows impact levels that should be decreasing. Risks are identified and tracked during the Sprint Planning meeting and monitored throughout the Sprints. The graph for the chart is created from the risk register (Figure 1). The risk burndown chart visualizes and tracks how long risks take to be mitigated. Total project risk levels can also be tracked. If risk mitigation is successful, the graph should be showing a downward slope as illustrated in Figure 2 below. The chart reflects an interpretation of the expected duration of how long a risk should be present on the project.

Figure 1: Risk Register (Agile Michael, 2016)

Figure 2: Risk Burndown Chart (Agile Michael, 2016)

Key Words: Scrum, Agile, Risks

References: 

SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOK^TM Guide.), 3^rd Edition

Michael, Agile (2016). Risk Burndown Charts. Retrieved from https://agilemichaeldougherty.wordpress.com/2016/02/04/risk-burn-down-chart/

Agile Planning involves quantifying the pace that a team can develop user stories into working software. The team’s velocity is the measurement of its throughput which is used to establish expectations regarding future delivery dates. To establish delivery dates, we examine the total amount of work for the project and divide it by the established team velocity. We then gauge how many iterations are needed to deliver the entire project. For example, if we have 100 story points to complete the project and the team’s velocity is estimated at 15 points per iteration, we calculate the number of iterations needed as follows:

• Total Effort/Estimated Team Velocity = Number of Iterations
• 100/15 = 6.66 = 7 iterations

As the team begins the Sprints, there are two things that can occur.

1. The team will deliver faster than projected
2. The team will deliver slower than expected

Release Planning

Release Planning involves a commitment to plan the delivery of a product increment of value. The Scrum team is responsible for planning the releases. Table 1 describes the responsibility of the team during this ceremony.

Table 1. Release Planning Roles and Responsibilities

What Happens Before the Release Meeting?

Prior to the start of the Release Planning meeting, the Product Owner needs to ensure that the Product Backlog has been prioritized. The Scrum Team should provide input about capabilities, velocity and any technical impacts. The vision statement, market and business objectives should be established. The Product Owner, if applicable, needs to announce whether new product backlog items will be needed.

Release Planning Data and Output

In terms of needed data for the Release Planning meeting, data from previous Sprints and releases would be beneficial. Stakeholders typically, but not always, provide feedback about the product, market conditions and proposed deadlines. Also useful are Action Plans and goals from previous releases and retrospectives. There may be additional items and unresolved defects that should be revisited. The team should be on hand to discuss the relevant development and architectural information. In addition, the team’s estimated velocity based on previous iterations should be considered as well as input from other technical team and subject matter experts to properly manage dependencies. The output from Release Planning includes but is not limited to the following:

• Release Plan
• Team Commitment to the Plan
• Suggestions for improvement regarding future Release Planning meetings
• New user stories for the Release Backlog

The Sprint Planning

Every Sprint starts with a Sprint Planning meeting. All team members should be present because this is the chance to determine how much work can be completed in the upcoming Sprint. The Guide to the Scrum Body of Knowledge (SBOK Guide) suggests that a one-month Sprint Planning Meeting has two parts and is time-boxed to eight hours:

1. Objective Definition – This event occurs during the first half of the meeting where the Product Owner discusses the highest priority User Stories in the Prioritized Product Backlog to the team. The Scrum Team then defines the Sprint Goal.
2. Task Estimation – This event occurs during the second half of the meeting where the Scrum Team determines how to finish the work in the Sprint Backlog to meeting the Sprint Goal.

The User Stories are estimated, approved and committed. Each Scrum Team members participate in an estimation of the tasks using common techniques such as Planning Poker. In the case of where the estimating is lengthy, it would mean that the team was not totally prepared to start the Sprint. Effort Estimation is used to select the tasks that are needed to complete the work. The Sprint Backlog is created as well as the establishment of the Burndown Chart and the team commitment is made verbally.

There are two events that should not occur during a Sprint Planning meeting:

1. Grooming – The refinement of the User Stories that should be done prior to the Sprint Planning Meeting.
2. Updates or Revisions – The User Stories should be clearly defined and ready to be broken down into tasks and then estimated. Updates to the User Stories should not occur during Sprint Planning.

Iterations Length

According to the rules of Scrum, the length of an iteration should not be longer than four weeks. The length of the Sprint is the determining reason as to how fast the Scrum team can inspect and adapt to fluctuating situations and continuing to learn. By having a maximum length for the Sprint, the Scrum Team is practically guaranteed a minimum benefit.  If a Sprint is longer than four weeks, the benefits of Scrum are lessened. Risks have the potential to be increased because of short-term planning, adapting to change, the development of the team, detection of errors and the timing of business opportunities.

Task Estimates to Story Points

Story Points represent a high-level estimation of complexity that is used prior to Sprint Planning. Story Points and velocity are relative measures that provide agreed upon guidelines about the user stories that will be committed in the iterations. On the other hand, task estimates based on hours are very low-level estimates that are used to represent the specific effort in hours that will be required to complete the User Stories during a Sprint. Tasks estimates should be as accurate as possible whereas Story Points are never expected to be exact. Since story points and task hours are used for very different purposes for different situations, the attempt to make a correlation between the two is not recommended. Figure 1 outlines when to use Story Points and Task Hours.

Figure 1. Story Points and Task Hours

References:

Agile Advice by Berteig. (2013). The Rules of Scrum: Every Sprint is Four Weeks or Less in Duration. Retrieved from http://www.agileadvice.com/2013/05/16/scrumxplean/the-rules-of-scrum-every-sprint-is-four-weeks-or-less-in-duration/

Agile in a Nutshell. (2016). (n.d.). Planning. The Fine Art of Expectation Setting. Retrieved from http://www.agilenutshell.com/planning

CA Technologies. (2017). Release Planning. Retrieved from https://help.rallydev.com/release-planning

Scrum Alliance. (2012). Story Points Versus Task Hours. Retrieved from https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours

SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOK^TM Guide.), 3^rd Edition

SCRUMstudy. (2017). What Happens at a Sprint Planning Meeting? Retrieved from https://www.scrumstudy.com/blog/what-happens-at-a-sprint-planning-meeting/

With Agile Methods, leadership styles are diverse and based on organizational specific environments, goals and the human resources on the Scrum project. While many of us are fully aware of the term Servant Leadership, there are other leadership styles that are also relevant. A discussion follows on the variations of common agile leadership styles that are used with Agile Methods.

Servant Leadership

To no surprise, the preferred leadership style for Agile projects is Servant Leadership. With this style of leadership, serving others comes first and foremost. The expectation is that one needs to instinctively have a sentiment of wanting to serve first. The next mindful choice is the desire to lead others. The servant-leader is very different from the person that is a leader-first because that specific need is based on the attainment of power. The leader-first and the servant-first are two very different types where one is strictly focused on ensuring that other people’s needs are being served, first before their own. The servant-leader is an organizer that realizes results by focusing on the needs of the Scrum Team. This is the preferred style of leadership for a Scrum team.

Unbeknown to many, the concept of servant-leadership started years go by Robert K. Greenleaf in the year 1970. Greenleaf published an essay entitled “The Servant as Leader”. He described the servant-leader as having a strong desire to help others. This person identifies ways to meet the needs of customers, communities and teammates. This type of leader encourages ethical reasoning among those that are followers. The servant-leader typically develops long-term relationships with followers and they encourage their personal development so that they can obtain their full potential. The concerns of the servant-leader are the achievements of all stakeholders; not just a select few.

A Servant-Leader uses their abilities of listening, compassion, dedication and perception when working as a Scrum Master or Product Owner for the Scrum Team. This role shares their authority and influence with the team. The Scrum framework identifies the Product Owner and the Scrum Master as the servant-leaders of the Scrum team. To be successful, the servant-leader should possess the following skills:

Table 1: Servant-Leader Desired Skills

There are additional agile leadership styles that may be not so familiar as the servant-leadership style of agile management. They include but are not limited to the following:

Table 2: Leadership Styles

Keywords: leadership, styles, agile

References:

SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOK^TM Guide.), 3^rd Edition

Keith, Kent M. (2017). To Serve First. The Servant Leadership Journey. Retrieved from http://toservefirst.com/definition-of-servant-leadership.html