Challenging inertia through Scrum

This article was published on Scrum Alliance in Oct 2009.

Challenging inertia through Scrum

Inertia is defined as a state of being lazy, sluggish or indifferent. Challenging inertia is about challenging status quo in an organization. It is about how things should be done differently compared to how they are done now. Organizations sometimes become susceptible to failure as they are unable to challenge the status quo due to various reasons. This is as relevant to software development as it is to any other aspect of an organization’s functioning. In this article, we will examine the following reasons for organization inertia, the consequences for software development, and see how Scrum can help with the following:

• Size of the organization


• Inefficient structure


• Too much or too little process


• Poor performance management

 

Size of the organization

How does it cause inertia

Slow decision making

As organizations grow in size, managing scale becomes an issue. Bigger organization means management decisions have a bigger impact. Wrong decisions can put the organizations at risk and therefore it becomes necessary to consult a variety of stakeholders within and outside the organization. This implies that the time taken for arriving at key decisions becomes longer. The increased timeframe for making decisions is understandable for issues that impact core functioning of the organization. However, it is definitely not suitable when the organization needs to adapt its products in a dynamic and tough market.

Consequence

Many organizations do not understand this problem and fall into the trap of slow decision making, even for product development. When innovative ideas fail to reach the customers on time, competition gets an undue advantage. Slow pace of decision making can result in missed opportunities, lost revenue and increased customer attrition. Thus, regardless of their size, organizations need to deliver the right functionality at the right time to their customers.

How Scrum helps

• Ownership of the product backlog and prioritization encourages faster decision making and responsiveness to customer needs even in large organizations. Controlled, yet responsive management of changing requirements helps managing scope with improved turnaround time. The product owner makes sure that the team does not lose sight of what is most important for the customer.


• Reviews and product demos at the end of each sprint gives the customer representative more clarity on how the end product should work and look. This helps in reducing wastage of effort and money into development of low priority features, when high priority features need more functionality that has yet to be developed.


• Early feedback from these demos ensures the team makes necessary changes related to the most important functionality of the product in the early stages instead of struggling with issues later when it is too late.


• For large organizations the cumulative impact of late identification of issues can be very costly and difficult to ascertain. However, as multiple units within the organization implement Scrum, the positive effect is amplified and inertia is reduced immensely.

Inefficient structure

How does it cause inertia

Communication

Inefficient organizational structures lead to wasted time, effort and money. The wastage mostly results from poor communication channels between people regardless of their team, unit or department. They are also a reflection of an organization’s lack of sensitivity towards customer needs. Traditionally, team members are forced to work as analysts, designers, user interface developers, middle tier developers, database developers, and testers. Work is divided depending on specialization, and it moves from one person to the other in a sequential manner. Such structures create artificial boundaries between people that are difficult to cross. They create a decision vacuum, wherein the buck passes from one person to the other forever, and the issues are resolved at such a slow pace that they would lose their relevance by then.

Power Politics

Inefficient structures promote power politics. They create an environment where people are made to compete with each other endlessly. This often results in situations where they cross each other and spoil relationships in order to get ahead of each other. In such situations, collective ownership is not given its due importance. Often work assignments are driven by authority and processes rather than teamwork and collaboration. Reduced innovation
Inefficient structures make innovation difficult. Since everyone is focused on their own activities rather than delivering complete functionality, few in the team can see the bigger picture of how what they are doing impacts the end-user. Therefore, sources of new ideas to create innovative products are few. Lack of collective ownership We have seen this with step-wise approaches to software development. Business analysts and business owners are responsible for requirements, Architects are responsible for high level design, Designers are responsible for low level design, Developers for coding, Testers for testing, Integrators for integration, and Project Managers for planning, tracking and coordinating their activities. In such a situation, it is the project manager who is blamed, not the team, when a project is delayed. Usually, one way or the other, team members can easily find excuses for not delivering on time by pointing in another direction. Although this works well for everyone other than the project manager, it is the customer who ends up paying for all the inefficiencies. And no one likes paying more than the real value of the product.

Consequence

The problems with inefficient structure are too many and too difficult to resolve. Due to inefficient structure, customer interests take a back seat as everyone involved views his/her interests as top priority. There is often mistrust of the “other” groups and team members as the blame game can start anytime if anything goes wrong. Due to this people play safe. They only do what they are "supposed" to do, or as per the “defined” compartment to which they belong. The dysfunction is easier to observe at the team level. Some examples are: “Coding can only start when the design is over,” “No changes can be entertained in the requirements since design is already over.” However, the issue extends beyond the team level. When the team size is large or when multiple teams, units, departments and organizations are involved in creating a product, it becomes even more difficult to acknowledge and resolve. It is also possible that there are vested interests in ensuring that the conflicts remain and politics and emotions prevail over common sense. Ultimately, if these issues are not addressed, the customer pays an extra price or gets a delayed product.

How Scrum helps

While there is no easy answer to solving these structural issues, an advantage of Scrum is that it helps in making the dysfunction visible and allows the organizations to take corrective actions. Other than that the following points are worth mentioning. Keeping the team cross functional

• This reduces bureaucracy and time lag from making decisions at the team level. A cross functional team does not have artificial walls and naturally communicates better internally and with external stakeholders. Teams change focus towards delivering the functionality as a whole instead of delivering one part of the work (e.g. Design, User Interface, Middle Tier, Test etc.). This not only helps team members learn multiple skills, but also aids in immensely de-risking the projects through collective ownership.

Daily Scrums and Scrum of Scrums

• Focus on resolving impediments quickly improves collaboration and avoids getting into blame games. Scrum meetings keep the entire team engaged in the discussions and provide a clear list of impediments towards progress. These meetings also help team members in supporting each other to meet their joint commitment to the product owner. They enhance teamwork and collective ownership, thereby improving communication. When Scrum meetings are conducted well, structural separations between the team members, which slow down the process, tend to fade away.

Sprint planning workshops

• Prioritization of requirements in the product backlog provides better visibility to the team about what needs to be developed and improves transparency in decision making.


• Since the overall scope can be changed at the beginning of every Sprint, business concerns for new requirements are met. Likewise, the IT team's concern about giving upfront commitment on a plan is also addressed, since with Scrum, it is understood that plan needs to be revisited in every Sprint.


• Sprint planning workshops improve collaboration between the business, development, testing, user experience and other groups. These workshops align the entire team towards customer needs and make them give a joint commitment to plan.


• Since all concerned stakeholders are involved in the exercise of scoping and planning, there is a substantial reduction in power politics and improvement in communication, collective ownership and innovation. This eventually benefits the end customers and the organization.

The role of ScrumMaster

• ScrumMaster plays an important role by serving the team and protecting it from outside interference. By helping the team in following Scrum practices, the ScrumMaster ensures that issues are resolved as fast as possible. The role of ScrumMaster helps in improving communication and collective ownership of the team.

Too much or too little process

How does it cause inertia

Artificial Lags

Lack of appropriate levels of process introduces lags that have an undesirable impact on team performance. For example, too much or heavy process leads to an excessive waiting period due to unnecessary checks at every step in delivering the system.

Chaos

While lag is introduced by heavy processes, chaos is introduced by too little process. When there is chaos, team members do not know where to go and whom to communicate about what. Without processes, it becomes a free for all. It is easy to understand why typical software projects need a process wherein communication is well managed and roles are well defined.

Consequence

Heavy processes promote bureaucracy and reduce productivity because, due to the lags they add, things move slowly. As a result, the team is unable to deliver results with low turnaround time and eventually it results in customer dissatisfaction.

How Scrum helps

Just enough documentation and continuous collaboration

• Documenting the needs of users in a concise, yet informative manner and supplementing it with planning workshops, gives the development team a good perspective on end user needs. This eliminates the need for documents to float around within the team for multiple review/rework cycles and reduces a lot of waste.


• Collaboration during planning workshops ensures that all stakeholders have a better understanding of the requirements. This helps in designing better test cases and better code. Eventually it reduces the amount of rework required during later stages due to poorly understood requirements.

Short feedback cycles

• We may encounter several situations where the functionality developed in a Sprint needs to be revisited. For example, we may find that user needs have not been implemented to satisfy the business goals due to bad design/coding, or the requirement was poorly communicated to the team. We may also find that the customer representative changes his view on how the requirement should "actually" be delivered by the time Sprint ends.


• Scrum makes dysfunction visible and encourages bottom-up feedback. Short feedback cycles of Scrum allow corrective action to be taken almost immediately and satisfy the needs of higher priority functionality in the product backlog.

Team Retrospectives

• Just as short feedback cycles help us in revisiting the contents of product backlog regularly, retrospectives allow team members to periodically inspect their ways of working and adapt their processes locally.

Poor performance management

How does it cause inertia

Ineffective goal setting

Sometimes individual goals are set with a view to encourage competition within the team. In software development, this could be counter productive if the parameters selected do not encourage team work and team performance.

Improper status tracking
Monitoring status is an important activity from the perspective of team performance. If the team does not track progress or only tracks activities that have been completed, it could be in for a surprise when the project nears completion. Moreover, if tracking progress is more of a centralized activity instead of team activity, there is a high likelihood of status not being reported regularly or correctly as team members may stop seeing the true value derived from status tracking.

Infrequent reviews
Tracking performance after large intervals makes it difficult to assess performance accurately. Due to this the feedback can be incorrect and/or ill-received.

Consequence

Ineffective goal setting could lead to unnecessary conflicts in the team. It might not perform to its fullest capability in normal situations and could even fall apart in critical situations. Late surprises due to improper and infrequent status and performance tracking could cause the team and its members to slip from their goals. They might deliver later than committed, deliver with lesser scope or deliver by cutting quality.

How Scrum helps

Metrics focused on team needs

• Working software is the true measure of progress for an agile team. Measuring and setting goals against working software provides the largest benefit. In addition, metrics that focus on day to day activities help the team in assessing its performance against its way of working. For example, the team could track number of build failures and number of acceptance test failures in the integration environment. It could also track how well it follows Scrum and other agile practices it might be using.


• By measuring metrics that are related to team performance and setting goals with respect to those metrics, the team can continuously improve its way of working and give better output.

Burndown charts

• Burndown charts provide visual progress of team’s activities and make status tracking a de-centralized and fun activity. They not only track what is completed, but they also track what is pending on a daily basis. This improves the team’s chances to deliver on time, thereby enabling them to fulfill customer needs on time.

Frequent reviews

• Frequent delivery of working software with Scrum allows the team to review its performance frequently and make course corrections as needed. Frequent reviews of the team’s performance reduce the room for lethargy and provide an incentive to deliver better regularly.

Conclusion

Scrum focuses on results, quick turn around time, short feedback cycles, and collaboration and relevant metrics. This helps an agile team in influencing issues related to size and structure of the organization, software delivery process and performance management. When the use of Scrum spreads at the organizational level, it helps in challenging organizational inertia and making the organization more agile.