ScrumBut: Construct the Sprint Backlog According to Individual Specialist Capacity.

By Raymond Shanley

I was recently discussing Scrum with some Scrum Teams, and one team was convinced that a certain ScrumBut was a better way to do things. This particular real life ScrumBut is to construct the Sprint Backlog so it has just the right amount of work for each specialist in the team based on how many story points each individual can deliver in a Sprint. Trying to argue that this approach is against the Scrum rules is not enough to convince people not to use it. At the time of the discussion I was unable to convincingly express why the approach is counter-productive. Afterwards I thought it must be that the problems caused by the approach are not immediately obvious. So I decided to run through an example on paper, which I will now present.

The product concerned is already a few years old and individual specialists have been responsible for parts of the product over those years. The team changed over to a Scrum approach in the past year. So due to the historical situation it is true that a specialist can finish an item in his or her component quicker than someone else. In order to change this situation, learning and knowledge creation would be necessary.

Before we continue let’s summarize the normal Scrum approach. The Team gives estimates for each item in the Product Backlog. The Product Owner then prioritizes the items according to value (and other factors can also be considered such as risk and dependencies between items). The Product Owner is responsible for generating highest value for the stakeholders in a sustainable way and generally wants to finish the highest value items first. The Team is responsible for figuring out how to deliver the items. There is a clear separation of responsibilities between Product Owner and Team. If there are specialists in the Team, the prioritization occurs independently of how much work these specialists are capable of handling in a Sprint.

Ken Schwaber gave ScrumButs a particular syntax: (ScrumBut)(Reason)(Workaround). So here is a formulation of the ScrumBut in this article using the standard syntax: "We use Scrum, but (we want individuals in the team to have just the right amount of work in his/her area of expertise) (so we construct the Sprint backlog according to individual specialist capacity)".

I will run through a concrete example for 4 Sprints first using the ScrumBut approach mentioned above and then using the normal Scrum approach. This is a simple example. It would be possible to construct a more complex example but the same basic problems would emerge so let’s keep it simple. In this example I assume that the Product Backlog prioritization does not change between sprints. If prioritization changes (like in the real world) the problems discussed here are at best only masked slightly.

Let's say we have 5 components in this particular product being developed by the Team. Each component is developed by 1 specialist and each specialist is capable of producing a slightly different amount of work per Sprint as in the following table. The team velocity is calculated as the sum of the individual velocities.

Now let's say our initial product backlog looks as follows. The letter represents the main component affected by a given story. I generated the order of the backlog by writing a list of the letters on a sheet of paper as randomly as possible. Then I wrote story points beside the letters also as randomly as possible (values between 1 and 3).

Summary of the stories on the Product Backlog so far:

ScrumBut Approach, Sprint 1:

If we now go through the Product Backlog and construct the 1st Sprint Backlog according to how much work each specialist can take on we get the following:

So the items that fit in the sprint are 1, 2, 3, 4, 5, 7, and 8, which gives a total 13 story points. Estimated velocity was 17. Item 6 did not fit in because developer C (the developer of component X) was already fully loaded. If specialists have spare time they can either do some other task outside the product scope or take on an item in their specialization lower down on the Product Backlog.

ScrumBut Approach, Sprint 2:

Summary of new items that entered the Product Backlog before the Sprint 2 Planning Meeting:

Below is the Product Backlog for Sprint 2, showing old items and the new items that were added before the Sprint 2 Planning Meeting. The last column shows whether the story made it into the Sprint Backlog or not (as usual, calculated based on individual developer capacity).

Note that item 6 is too big to be done by developer C in one Sprint. This could possibly be split into smaller stories. However, splitting it still does not alleviate the basic problem that developer C appears to have too much work, which creates a bottleneck in the system.

Note the pattern starting to appear, which is that higher priority items are being replaced by lower priority items in the Sprint.

The items that fit in this Sprint are 9, 10, 11, 12, 13, 15, 16, 17, and 20, which gives a total 14 story points.

ScrumBut Approach, Sprint 3:

Summary of new items that entered the Product Backlog before the Sprint 3 Planning Meeting:

Just as for the previous Sprint, here is the state of the Product Backlog. The final column shows whether the story made it into the Sprint Backlog (again, based on individual developer capacity).

The items which made it into the Sprint are 14, 19, 21, 23, 25, 28, 29, and 30, which gives a total of 13 story points. In this Sprint it is becoming clear that prioritization is hit-and-miss. Roughly every 2nd item needs to be replaced by a lower priority item.

Also, component X is clearly a bottleneck. At this point it might be possible to intervene and say developer C needs help and ask someone else to learn X. However, there are at least two disadvantages to this. First, it is a reactive rather than a proactive approach. It is at a late stage that developer C is getting help and he/she has so much work to do it will not be easy for him/her to take the time to show someone else the ropes. Secondly, this monitoring of potential bottlenecks requires additional administrative overhead. Someone needs to be constantly keeping an eye out for the problem occurring. With the normal Scrum approach you get this balancing automatically.

ScrumBut Approach, Sprint 4:

Summary of new items that entered the Product Backlog before the Sprint 4 Planning Meeting:

Same as for the previous Sprint here is the state of the Product Backlog. The final column shows whether the story made it into the Sprint Backlog (based on individual developer capacity).

The items which made it into the Sprint are 18, 24, 31, 33, 34, 35, and 36, which gives a total of 12 story points. In this Sprint more items were taken from the bottom half of the backlog than from the top half.

Scrum Approach, Sprint 1

Now let’s walk through the same example with the normal Scrum approach so we can compare the results.

The estimated velocity of the team is 17 but let’s just take on 14 story points to provide for cross learning. The top 7 highest priority items make it into the Sprint.

Scrum Approach, Sprint 2

This time we also take on only 14 points to allow for cross learning. The top 8 stories make it into the Sprint.

Scrum Approach, Sprint 3

This time let’s take on 16 out of an estimated 17 velocity as less cross learning is necessary as time goes on. In this Sprint the top 9 items are taken into the Sprint.

Scrum Approach, Sprint 4

For the final Sprint in this example let’s take on 16 out of an estimated 17 velocity. In this Sprint the top 9 items are taken into the Sprint.

Let's compare the items remaining in the Product Backlog at the beginning of Sprint 4 of each approach:

Conclusion

The example described in this article demonstrates that dangerous bottlenecks can develop if using the given ScrumBut approach. It also demonstrates that the ability to prioritize properly is diminished by the same approach. These are not the only problems caused. Other problems include:

• The so-called team is operating more as a collection of individuals. There may be no common sense of responsibility.
• One-piece flow may be affected. Parts of stories may be finished at the end of a Sprint and other parts missing.  
• The team has no redundancy built in, which means if someone goes on vacation or gets sick there is a problem.  
• Self-organization is effectively being killed. The team does not have a chance to decide itself the best way to deliver the functionality for a Sprint. This may also lead to motivation problems (intrinsic vs. extrinsic motivation).  
• There may be an issue with trust: Does the Product Owner trust the team to deliver on a Sprint?

My advice is to avoid this ScrumBut even if it leads to reduced productivity (perceived or not) in the short term. Keeping this ScrumBut will lead to more serious problems in the long term.

Are you ready for Agile? A Checklist of Questions to Consider Before Starting a Large-Scale Agile Adoption

By Ramesh R. Donnipadu, Bala Kishore, Pete Deemer

Abstract

The ability to deliver business value earlier and more often, increase productivity, and improve employee morale is compelling many organizations to embrace Agile approaches to software development. There is a wide array of training courses, consultants, and books available to help teams learn the basics of agile development, but these often focus on the team-level challenges, and overlook some of the larger organizational issues that may either help or hinder the transition to this new way of thinking and working. This article attempts to outline areas where many organizations encounter difficulties in their embrace of Agile, in hopes that others can be better prepared to meet these challenges.

Checklist

Depending on the size of the organization and current processes followed, different organizations may face different challenges in their Agile adoption. This section lists the most common difficulties that your organization may encounter in the early days of embracing agile development. Some of these items are not even related to Agile per se; they‟re just sound Engineering or Management principles, which any smart organization normally follows. But, these are not so obvious until you get into the thick of the things. Regardless, not attending to these issues at the outset could lead to frustration for the organizations getting into agile development.

This Checklist is expected to help you evaluate the preparedness of your organization to these new challenges.

Management

1. Do you have Management’s support?

Among the challenges a team may face in the early stages of adopting Agile, the most important one is winning the confidence and support of top management. If you do not have a genuine commitment to change from your top executives, you are not likely to be successful. Win their confidence support before you set out your journey. Be upfront with them on the roadblocks you may face and lay out your plans on how you intend to overcome them.

In some cases, the senior executives and junior technical staff may be enthusiastic to “go Agile,” but there may be a lot of skeptics in middle management. This could be due to the fear of losing control over their teams or inability to distinguish Agile development from “cowboy coding” or apprehension on the quality of the product or lack of documentation. You need to allay their fears by showing concrete examples.

What if your leadership fails to agree with you? You can still go ahead with Agile, but you are on your own in dealing with the challenges.

2. Is Proper Training Provided to the Organization?

The industry-standard training for Scrum teams is the Certified ScrumMaster (CSM) training course, conducted by a Scrum Alliance Certified Scrum Trainer, and we strongly recommend that this training be provided not only to ScrumMasters but also to team members, managers, and others in the organization that will be interacting with the Scrum teams. In addition, it's imperative that Product Owners complete Certified Scrum Product Owner training. If great results are to be achieved, everyone needs to understand how to “play the game” well.

This training in the fundamentals of Agile is just the foundation for success, though, and to be successful, there are other new skills that will have to be learned. First, Agile development quickly makes visible any deficiencies in teams‟ ability to work together closely and produce high quality functionality in the span of an iteration. Many teams require training to learn better coding and testing practices, whether in the basics of test automation, refactoring techniques, or in practices such as Test-Driven Development. In many organizations, team members have highly specialized skill sets, and often have difficulty working closely together as part of a cross-functional team; they may require coaching in how to do this successfully. Often, the most effective way to retrain the team in cross-functional behaviors is to “seed” the team with one or more members who are experienced in this way of working.

Another good way of accelerating learning is to start a study group that meets periodically to discuss various aspects of Agile development before the training takes place. During this period the team can read literature available on the Internet, starting with the Scrum Alliance website [www.scrumalliance.org]. We found these meetings are extremely helpful to come onboard quickly in terms of understanding the new practices and mindset, and adopt it to our environment.

In addition to new technical skills, teams may also require more education in their product domain. In Agile, developers are not “software robots,” blindly implementing software specifications; rather, we want them to be full partners in the development effort, helping the Product Owner achieve maximum business value. For this to occur, they need to have a working understanding of the business and technology context for the work they are doing.

Many organizations make a solid investment in training in Agile technical practices, but overlook training in the soft skills needed to really get the most from those practices. ScrumMasters, Product Owners, functional managers, and executives should receive training in facilitation skills, Agile retrospective techniques, dispute resolution, root cause analysis, and systems thinking. All of these are practical necessities for skillfully coping with the myriad dysfunctions that Agile development will quickly surface.

3. Did you train your Product Owners?

Strong product ownership is a key to the success of Agile development, since it is this group that bridges the gap between the end customers, management and IT. A very thorough understanding of the responsibilities of the Product Owner, how to work with customers, the team and stakeholders to achieve maximum ROI, and how to be effective with the essential practices are required.

When faced with large-scale development effort, it is often recommended that all teams work from a single, project-wide Product Backlog, as opposed to having multiple, team-specific Product Backlogs; this will help reduce the duplication, redundancies, and conflicting directions that can often result from the latter.

Unless your Product Owners are equipped with these skills, you are not going to see the big wins from Agile adoption.

4. Do you have enough space?

Agile principles emphasize face-to-face communication wherever possible. If the individual members of your Agile team sit at different locations, the overhead of communication reduces their effectiveness. It is mandatory to rearrange their seating so that it improves informal communication within the Scrum teams. Get the teams co-located into their individual team spaces even if you have to convince your facilities, HR, VP or CEO.

You also need to ensure that they have enough free space for informal gathering around a computer for a quick walk-through, their daily stand-up meetings etc. Also, ensure that the teams have adequate wall space, white boards, flip charts and writing material.

5. Are all your support teams on board?

Organizations make all efforts to train the teams that are adopting Scrum. But, often they ignore the need to familiarize other support teams. If the development team is going to be successful with Scrum, they need to have full support of any specialists who provide support but are not members of the team, for example, DBAs, Sys Admins, or the Configuration Management team. Unless they know the constraints and limitations of your Scrum teams, you are not likely to receive their deliverables and meet your Sprint commitments.

Get at least one representative from each of these departments enrolled in the Scrum training. Try to get these specialists included in your Scrum teams, ideally as full-time members of the team, or at least in the role of consultant.

6. How quickly to scale?

Often, large organizations attempt to roll out Scrum across several teams simultaneously; what some people call the “Big Bang” approach to change. Tempting though this may be, the risk of such an approach is that systemic or large-scale dysfunctions (which afflict many teams across the organization) will be surfaced by many teams simultaneously, and will have to be resolved quickly and for many teams at once. This is both very challenging and very chaotic. It may be easier to begin Scrum with a small number of teams, try different solutions to solving these baseline dysfunctions, and be able to provide best practices to later teams that follow in their adoption of Scrum. As the organization gains confidence and competence in Scrum, more teams can start practicing it.

7. Is an appropriate attrition strategy in place?

This may not be an important item in difficult economic times, but for organizations susceptible to high attrition, dealing with this problem could be very challenging. Unlike in traditional models, Scrum believes in tightly gelled teams of individuals with a core competency and multiple cross-functional skills. As Scrum teams are smaller, losing a single member could prove to be a significant setback for a team. Even if you find a quick, equivalent replacement, it will take some time for the new hire to get up to speed, bond with the team and start delivering.

Scrum provides the benefit of teams, but also makes more visible the disruption when teams are broken or changed.

Have a trained pool of engineers available, who could substitute an unexpected departure in your team.

8. Can your engineers appreciate the purpose behind a user story?

A competent technical team can convert a user story into database tables, Controllers, tags and Form elements fairly quickly. But some teams may have difficulties in comprehending the motivation or ROI behind a feature they are implementing. For Agile to be successful, it is critical that all members of the development team (developers, testers, etc.) “get into the Product Owner‟s head” and appreciate the rationale behind a user story. They should keep questioning the objective of major decisions and suggest alternative implementations where possible.

Otherwise, one risks ending up with brilliant technical implementations that fail to meet the business goals.

9. Module assignment to teams

If you are planning to assign different software modules to different Scrum teams and you expect them to have exclusive check in privileges on their modules, you need to be very cautious. While it is a good idea to let individual Scrum Teams master specific software components, if you implement a user story that requires multiple Scrum teams to work on it, all hell breaks loose. The interface design, hand off, and integration between multiple teams introduce a lot of waste.

Also, avoid restricting teams from touching other modules based on their ownership. You can better enforce the code ownership with good code reviews and refactoring policies.

Code

10. How tightly coupled is your system?

If your code base consists of tightly coupled modules, and you have a large number of Scrum teams, chances are that they will be stepping on each others‟ toes constantly. The problem will be more acute if the Sprint or release cadences of the teams don‟t align.

If possible, spend some time re-organizing your code base to minimize the inter-module dependencies. This exercise is well worth the effort as the code will be more modular and less tightly coupled, which in turn will create better „code‟ conditions for the Scrum Teams to do their job, and enable the teams to more quickly produce more business value.

11. Do you have good Unit/Automation test coverage?

At the heart of Scrum is the delivery of potentially shippable software at the end of each Sprint. For this to happen, test automation is a must. If you do not have a comprehensive set of automated unit tests that are tied to your build system, you are likely to spend more time in testing and debugging than necessary, and it will be difficult to end each Sprint with a fully tested (and fixed) system. In addition, automated tests give the team confidence in making changes; they know that if the change breaks other parts of the code, it will be immediately visible.

Strengthen the foundations of your code base by adding as many unit tests and automation tests as possible. Teach your developers the art of Refactoring, if they don't already know it. Tools like Emma, Jester and Cobertura will help you measure the coverage of unit tests.

Tools

12. Do you have good collaboration tools?

This item is critical for the geographically distributed teams. Agile requires a close interaction among team members, so you need to ensure your team has all it needs for effective communication. Use video conferencing, telephones, emails, instant messaging, and Skype as much as possible. VNC, WebEx, Sococo are other useful tools for the team collaboration. If you are planning to introduce a tool such a Rally, VersionOne, or ScrumWorks, make sure the teams themselves have an opportunity to evaluate them fully before making a decision.

13. Do you have a source code repository replication system?

This item is more relevant for multi-location teams. Nothing can be more frustrating for your remote teams than accessing the repository on a slower network. Due to shorter release cycles, your teams would be doing more frequent checkins, checkouts, branching, merging than they normally would if they were using traditional methodologies. Make sure you have a fast, reliable repository replication solution in place before you roll out Scrum.

14. Is your build and deployment system fully automated?

It is difficult to imagine a modern software development organization not wanting to automate their build and deployment activities. Design your build and deployment processes to be completed in a short time, say, 30 minutes. This should include executing the test cases and certifying the build. It is even more preferred to have a continuous integration (CI) policy before you move to Scrum. The CI will highlight the build/integration issues and help the teams identify and fix the issues quickly. When the teams are working in short time-boxed iterations, any time gained in their iterations will be valuable.

Alternately, if you require a lot of manual intervention in the build and deployment, your teams‟ velocity is going to be affected.

Others

15. Do you have adequate Dev and Test environments?

If you would like to have dedicated Dev and QA environments for individual (or groups of) Scrum Teams, you need to plan them in advance. You also need to ensure you have enough hardware, software licenses, and IT support staff to build or maintain those environments. Since budgeting, getting approvals, ordering, hiring, and training take a while, you need to plan this well in advance.

16. Do you have enough monitoring/health-check systems in place?

If you are working with a large number of environments and each of these environments has multiple servers, databases, networks and other third party components, you need to have a robust monitoring system in place. Zabbix and Hobbit are a couple of good tools you could consider for monitoring the health of your systems.

Conclusion

Due to the wide philosophical differences between traditional and Agile methodologies, a few organizations are facing challenges and getting frustrated with their results while adopting Agile. A lot of these challenges can be met effectively with decent preparation. This article presented a checklist of items to be considered along with a mind map for the benefit of teams getting into Agile.

References

1. Scaling Lean & Agile Development, Thinking and Organizational tools for Large-scale Scrum,Craig Larman, Bas Vodde, Addison Wessley 2009
2. Scrum & XP from Trenches, Henrik Kniberg
3. 10 ways to screw up despite Agile and XP, Henrick Kniberg at Agile 2008, Toronto
4. Art of Agile Development, James Shore, Shane Warden, O‟Reilly Media 2008
5. Agile Testing: A practical guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory

How Effective is your Agile Team?

By Rowan McCann

Introduction

Back in the '90s, self-managed teams were gaining popularity, but they had a high rate of failure mainly because team members lacked people skills. These ideas of self-managed teams were borrowed by the Agile movement when, in 2001, they formulated a ‘new’ way of working, based on Agile principles. These principles value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

For these ideas to work in practice, Agile team members must know something about teamwork, and this means understanding a lot about human behavior and why people do the things they do!

Agile team members are usually composed of highly skilled and knowledgeable workers who strongly value their independence. Some are worth more to an organization than the people who manage them! Many software developers are quite introverted, preferring to interact with their computers rather than people. In my experience, organizations hardly spend any time on people skills and spend no time on the even more difficult concept of what people need to do to ‘self-manage’ into a high-performing team. I’ve had to learn this in the world of experience. I wonder how many readers find themselves in a similar position.

If you look at the Agile website, you’ll find that the emphasis is on ‘engineering best practice’ and tasks rather than team processes. Similarly, many project managers are used to old-school leadership where they are more comfortable with control and the power that goes with it. For Agile IT teams to become high-performing they should immediately spend time helping the team to initiate the process of adaptive learning. This requires a focus on behavioral skills.

The Nature of Work

A starting point for all teams is to understand the nature of their work. One of the best models describing this is the Types of Work Wheel developed by Team Management Systems. Through their research they were able to identify eight distinct ‘Types of Work’ that need to be undertaken by all teams, regardless of their industry. There are important lessons here for our industry of Agile Project Management. The eight work functions are listed below, with the approval of Team Management Systems.

The Advising function is associated with the gathering of information from all stakeholders and responding quickly to changing requirements. It involves keeping up-to-date with developments inside and outside the organization and sharing advice with others to help them in their work. It requires a transparent flow of knowledge of 'what' is going on and 'where,' and a focus on 'consulting skills' so information can be gathered quickly, accurately and effectively.

The Innovating function involves generating new ideas and new ways of doing things. This requires the development of creative problem-solving skills so the team remains one step ahead of its competitors. To do this well requires original thought, imagination and innovative thinking.

The Promoting function is concerned with the identification of opportunities and the 'selling' of these opportunities to others, both inside and outside the organization. It often involves the application of influencing skills and the making of presentations to others. It can also involve communicating the team or organizational 'vision.' High visibility throughout the organization may also be required.

The Developing function is associated with the turning of concepts into 'reality.' Ideas are worked on to produce practical products and services. In many cases it may also involve developing workable and practical solutions when problems arise. Agile teams need good analytical skills so that requirements can be quickly prioritized, enabling accurate estimates of iterations and burn down charts.

The Organizing function involves organizing people and resources efficiently by setting clear goals and objectives and making team members accountable for their actions. It is also associated with the implementation of quick, effective action when problems occur, so the planned outputs are always capable of being achieved. Essentially, that the organizing function ensures that the work of the team is structured and focused towards common objectives.

The Producing function focuses on outputs, ensuring that iterations are completed to high standards of effectiveness and efficiency. It is the function associated with the regular delivery of releases and other services. It requires a systematic approach to work and an emphasis on the delivery of products on time.

The Inspecting function requires an attention to detail and an emphasis on the monitoring of systems, contracts and outputs. It is also associated with a focus on accuracy, ensuring that work outputs are always delivered to the right quality. This function is the classic control function where procedures are regularly monitored for their efficiency. It’s often a core feature of the sprint review process.

The Maintaining function is a support function which ensures that proper standards of conduct and ethics are upheld and that quality is maintained. It is also associated with supporting others in the team so team processes follow agreed ground rules. Personal conviction and loyalty are often important to this function as is an interest in helping others.

Work Preferences

For teams to be high-performing it’s essential that these eight Types of Work are done well. But Team Management Systems has discovered that rarely does anyone actually enjoy doing all of these functions. People show distinct ‘work preferences’ for maybe just two or three of these activities.

Work Preferences are dimensions of individual differences in tendencies to show consistent patterns of relationships, thoughts, feelings and actions in the work environment. Work Preferences determine the conditions we all set up to allow our mental and psychic processes to flow freely. Preferences are usually transparent and are often the first thing we notice in others – ‘He’s rather quiet, isn’t he?’ or ‘She never stops talking.’ Some people prefer to think things through on their own whereas others need to talk out loud to clarify their ideas. Preferences are readily visible to others and are usually the basis of first impressions.

When we are working to our preferences we set up conditions where our psychic energy can flow freely. If we are more extroverted we like work where there are lots of interactions with others, both inside and outside the organization. If we are more introverted, then we like conditions where we can work on our own with few interruptions and meetings. Under these conditions our energy can flow freely with minimal resistance. Just as electrical energy generates heat when it meets resistance, our psychic energy generates tension and stress when it has to flow through areas that are not our preference.

My preference is to work in the Advising and Innovating areas on the Types of Work Wheel and I don’t really enjoy Promoting or Organizing activities, so wherever possible I’ll spend time thinking about new ideas or finding out as much as I can about the project.

What happens in an Agile team is that there’s likely to be an imbalance when you look at the work preferences of all the team members. If everyone is like me, then there’ll be a tendency to give priority to making changes and incorporating the latest ideas. Teams like this may have the weakness of never tracking their burn-down charts!

Other weaknesses occur if everyone enjoys just Organizing and Producing. Your team may be well organized and on-target, but is it really delivering what the stakeholders want or indeed need?

So, if your Agile Team is to be truly effective you must understand the work preferences of all team members and look at the preferences balance. It will give you an immediate picture of strengths and weaknesses, as far as teamwork is concerned. Information like this helps ensure that everyone’s work preferences are matched to the critical demand of the job they have to do. Where the match is high, our energy flows freely, we are more likely to enjoy our job, stress is lower and we feel happier at work. But all eight work functions must receive the priority they need and never be relegated to lower importance.

Linking

The center of the Wheel describes Linking. It’s an activity responsible for integrating and co-coordinating the work of the team. It’s not a preference but a set of important skills that applies individually to team members and collectively to the team. Ideal Agile teams have a low level of leadership control and a high level of autonomy. In these situations team effectiveness largely depends on six key skills of People Linking, Active Listening, Communication, Problem-solving and Counseling, Team Relationships, Participative Decision-Making and Interface Management.

For People Linking to be effective it’s important for all Agile Teams to establish a set of ground rules. These are an agreed set of acceptable, individual behaviors that define how team members will interact. Usually they comprise 10-20 statements that are posted in the team meeting room or on the Agile Project Management Platform, agreed on at the start of the project and reviewed after each iteration. If a team member is unhappy with a particular team process then it’s easy to begin a discussion just by referring to the relevant ground rule that everyone has already agreed to. Conflict is often avoided by this simple process.

Global Delivery Model - Agile Practices in Defect Fix Phase

By Vetrivel Shanmugasundaram

Integration Testing Phase

I am sure most of us have gone through a rough development phase during which we would have considered implementing agile methodology. It is very disheartening to see our favorite project being trapped in the testing phase with a never ending loop of defect fixes and disrupting the whole idea of an agile delivery model.

The defects fix phase starts as the development team completes the coding and unit testing, and moves the code to the integration testing and/or system integration testing phase (Please refer to the figure below)

This phase is very crucial because the software is not yet stable and the test scenarios covered during integration / system integration are wider than the scope of unit testing. Once the defects are logged in large volume, the development team may point to a “lack of design time,” refer to an e-mail chain, or worst case, compromise on their software engineering practices to do a “quick-fix.” Traditionally, software development vendors may trim the size of the development team during the development support phase, which does not help either.

If that is the problem, then what is the solution? Frankly, there is no “one” solution to the problem. I have tried to present a set of best practices based on my experience that will help us address this issue. I’ve included a few example problems; each is paired with a best practice that can help address the problem. I have also included additional information to help you decide on the best course of action.

Note: If you are just entering the defect fix phase, you may want to adopt any / all of the below practices, but if you are already in the defect fix phase, I would recommend you start with the Defect Retrospective (practice no. 5) to better understand the trend and choose the right practice.

1. Defects (Fix) Showcase

Problem: Too many re-opened defects

Solution: This practice would enable the development team to demonstrate the defect fixes to an internal tester (can be another developer) using the developer test cases. The internal tester also runs through the developer test cases and validates the results. Therefore, the concern actually repeats the tests in the development environment independently.

1. Developer sends an e-mail to the development lead to review the code changes.

                          a. Development lead provides feedback (if any)

                          b. Development lead sends an approval e-mail on the code

         2. Development sends an e-mail to internal tester (another developer) for a defect fix demo.

         3. Internal tester reviews the defect fix and approves it.

         4. Developer checks in the code on continuous build server.

This practice initially appears to consume more time, but a defect re-opening could be due to an oversight in unit testing and a functional (mis)understanding. It will be worth the time and effort, and the development team will soon be accustomed to the practice.

Suggestion: Choose the best person with domain knowledge for the internal tester role.

2. Defects Stand-ups

Problem: Lack of prioritization on defects and defects fixes span across multiple vendors.

Solution: This is similar to the daily Scrum, with a specific focus on defects. The questions asked in the meeting could be:

• What defects have you fixed from yesterday to today? (defect – id and description)
• What defects are you planning to fix today? (validate the priority)
• Are there any issues that prevent you from fixing these defects?

During these discussions/meetings we could discover that more than one person is working on the same defect or that someone is working on a defect that is considered closed.

Suggestion: Update your defect- tracking tool after the stand-up.

3. Defect (Daily) Iteration

Problem: Too many defects to manage, and the development team is not making any progress. Team is not being very productive.

Solution: A worst case scenario involves a very busy testing team and a not-so-busy development team. It is absolutely important to work very closely with the development team if you are expecting a considerable amount (100, 200 or say 1000) of defects.

You may need to :

• Organize your development team in shifts (to enable 24-hour fixing)
• Have a daily progress review (preferably mid-day)
• Use a defect closure plan as defined below

• Date column: The latest date will be recorded as the first entry (insert a new row at the top)
• The ‘During the day’ section tracks the defects fix velocity as defects fixed per day. It can be used to measure the testing velocity as well
• The ‘Close of the Day’ section tracks the development team’s ability to maintain the velocity by tracking themselves towards planned and actual closure

It may look complex, but once implemented you can experience good and productive results.

Suggestion: Leverage the test manager to update and circulate the template

4. Defect Scrum

Problem: Too many design Issues or requirement gaps.

Solution: This is relevant while you deal with critical or “showstopper” defects, which are marked as ‘Design Issue’ or ‘Requirement Gap.’ You need to pay special attention and monitor the situation very closely (a Defect Retrospective can help here).

This scenario would require the development and design team to arrange a 30 minute meeting to understand the critical defects and agree on the implementation. The defects Scrum needs to include the Product/Business Owner to close the "Requirement Gap."

Suggestion: You need to establish a standard time for a regular Defects Scrum.

5. Defects (Fix) Retrospective

Problem: Unwanted closure codes.

Solution: Often, the defect root cause does not yield valid details due to the various invalid closure code, and sometimes the list of closure code exceeds the count of defects. This practice deals with consolidating defects of all kinds and generating a weekly report to review the spread of defects by closure code.

This will help you to ensure the following:

• All defects are closed with a valid closure code
• Logical grouping of closure codes – e.g. Invalid data, corrupt data, wrong data can be classified as invalid data
• Take corrective actions to avoid recurring defects – e.g. Identify the reasons why we have invalid data

Suggestion: See if this report can be automated.

Scrum and SVO-P

By Dan Mezick

Scrum is unique in that the management method is consistently direct. All communication in authentic Scrum is concise, direct and clear. Scrum encourages responsibility. The daily stand-up meeting actively encourages personal responsibility to execute on specific work, and to be accountable to the Team. The three questions of Scrum are questions related to accountability for specific commitments.

Each of Scrum's three roles clearly defines responsibility for a set of specific tasks. For example, the Product Owner is required to gather requirements, place them on the Backlog, and prioritize them. The Team is required to pull the topmost N items from the Backlog to load a Sprint, to attend the daily Scrum, and so on. Each role in Scrum takes responsibility for a specific set of tasks. Scrum roles and ceremonies actively encourage responsibility.

Language directly influences thinking and perception. Syntax that is consistently direct encourages responsibility and clear thinking. Indirect forms of syntax can often obscure the subject and encourage the dodging of direct responsibility. Avoiding responsibility is in direct conflict with the Scrum values of Commitment and Focus. Indirect forms of verbal communication are therefore not in alignment with Scrum values. Indirect verbal forms do not support Scrum.

I believe that SVO-p can be very profitably incorporated into the Scrum framework. SVO-p stands for Subject-Verb-Object, Present Tense.

SVO-p is a syntax. It is a style of communication in which you always know who is responsible for an action. SVO-p is an active form that encourages clear thinking and candid, direct communication. SVO-p can help clarify your thinking.

Communicating in SVO-p requires definition of who is acting, what they are doing and to whom. It requires placing the thought in the present; that is, "in the now." Speakers and writers who actively dodge responsibility often choose the past tense and the future tense for expressing thoughts. Politicians, for example, often assign blame to past events, while making promises about the future.

SVO-p brings clarity to communication, and directly affects thinking through the constraint of language syntax.

Examples:

Non SVO-p

"The people who write articles for free are to be congratulated."
This sentence puts the congratulations out in the non-existing future and also hides the identity of the congratulator.

SVO-p

"I congratulate the writers who write articles for free."
This sentence in SVO-p identifies the user and places the action in the now.

Non SVO-p

"I've yet to meet anyone who has given me a straight answer."
This sentence places the action in the future and obscures the object of the sentence. It also places the giving of 'straight answers' in the past.

SVO-p

"People don't give me straight answers."In this SVO-p sentence, 'People' are acting on 'me' in the now, by not giving straight answers.

You may find that speaking in SVO-p is difficult at first. You may also find that the use of the SVO-p syntax can be contagious. When you use it, others often tend to naturally speak back to you in SVO-p.

SVO-p is particularly well suited for use during Scrum communications, because SVO-p is consistent and supports the Scrum values: Commitment, Focus, Openness, Respect, and Courage.

SVO-p discourages "passive voice." Passive forms tend to conceal the subject and avoid responsibility. This is a problem because of a much higher likelihood that the receiver of the message may misunderstand the statement. The use of active voice in the present tense supports immediate action in the present moment. The subject-verb-object form tends to support direct and clearly articulated responsibility.

Responsible action in the present moment is consistent with Scrum values. For example, in daily Scrums it is the responsibility of the ScrumMaster to make immediate decisions in the present rather than deferring decision-making into the non-existent future. Likewise, in Scrum there is an emphasis on learning empirically, in the present, while avoiding making any specific predictions about the future. In this sense, Scrum and SVO-p are a perfect match.

The use of SVO-p by Scrum practitioners actively supports the success of Scrum in the present.

I notice that Ken Schwaber and Mike Beedle, co-authors of the book Agile Software Development with Scrum, write in nearly 100% SVO-p. The entire book except for a small part is written in SVO-p. This makes total sense, because the SVO-p form is consistent with the beliefs, values and behaviors of authentic Scrum. It is therefore no surprise that the original and most experienced practitioners of the art of Scrum use SVO-p as the preferred syntax for communicating the essentials of it. SVO-p is a very natural, nearly automatic fit with Scrum.

When you start experimenting with SVO-p in verbal communications, you find that it is necessary to speak in simple and direct (SVO) terms. You find that speaking in the present tense keeps you in the now, and tends to clarify your thinking. SVO-p strongly supports an empirical approach to work and problem-solving by focusing attention in the present moment, and making perfectly clear who is acting, and upon what.

The use of SVO-p strongly supports the reception of interactive loops of Scrum feedback in the present. This property of SVO-p tends to support the reception of feedback over the development and acceptance of "predictions" regarding the non-existent future. The use of present tense focuses attention "in the now." The simple Subject-Verb-Object syntax is clear and direct. If you are speaking in a future tense, you find it easy to make predictions about the future. If you are speaking in the present tense, you find it easier to pay attention to what is happening now. This supports the essence of Scrum: empiricism, or "learning by observation."

SVO-p maximizes focus on the present, at the expense of the past and future. Scrum methods identify, acknowledge, and directly confront the reality of complex software development. The use of SVO-p in Scrum, therefore, might not be optional. SVO-p is the best syntax available for communicating very directly in English. I wonder if one of the foul "Scrum Smells" is the avoidance of SVO-p syntax when communicating about current Scrum projects.

It is my belief that if you are really a candidate for a role in an authentic Scrum project, then you are ready for implementing your communications in SVO-p. Give it a try. If it feels uncomfortable, the discomfort may be about the difficulty of making fuzzy, indirect statements in SVO-p. You cannot easily make such statements in the SVO-p syntax. SVO-p identifies the subject, makes the action clear, and assigns responsibility for the action in the present moment. The directness of SVO-p is the greatest strength of the form. SVO-p supports the Scrum value of Openness by strongly encouraging clarity in each and every sentence.

Scrum and SVO-p confront reality, identify the subject, and assign responsibility. Scrum depends on interactive feedback in the present, and SVO-p supports that interactive feedback by focusing attention on the present moment.

I welcome your feedback about the use of SVO-p in actual Scrum practice. I am eager to learn about your experiences implementing SVO-p in Scrum. Please give it a try, and be sure to email me your feedback on SVO-p.

Iterative vs. Agile

By Manoj Vadakkan

Recently, I happened to overhear and eventually involve myself in a conversation between two Project managers. They were discussing why Project managers have to define what "yes" and "no" means to the team – after all, people have understood these words since kindergarten. The story is very familiar to Project managers. Every week, team members report that their activities are on track; the project status is green, and everything is going as planned. Everyone is happy until the project is about three quarters complete, and suddenly one team member reports that he is not on track anymore. Suddenly, dates need to be changed and the schedule needs to be updated. The Project manager inevitably asks the important questions, "Why have you been telling me all along that you were on track?" "Have you been hiding something?" "Don't you know, 'yes' means 'yes?'" Obviously, the Project manager cannot go to the sponsor with the bad news, and the team has to work overtime to get the project back on schedule.

This reminded me of a story that Alistair Cockburn once told about a student trying to do his reading assignment. The student had to read a dozen stories and answer a few questions afterward. He had a week to finish this assignment. If I were the student, I would have spent every day just thinking about reading those books, and would have postponed reading each day until Sunday afternoon when I would cancel everything and start reading the first book. But this student was different; he was a good planner. Upon getting the assignment, he considered the size and difficulty level of each book and figured out he had to read a couple of books every day to have enough time to go through the questions and answer them. He spent three quarters of the week just reading those books. He was on track until he started looking at the questions. He then realized there were things he didn't pick up on or pay close attention to when he was reading them for the first time. This meant he would have to re-read many of those books. This also meant he would have to spend a lot more of his weekend on his homework than he had planned. Good thing he had some contingency built in to his schedule!

Could he have done better by scheduling the work in a different way? What if he had quickly read one book, and then immediately looked at the questions? Then re-read, but this time paid closer attention to where the answers were coming from. What if he had changed his approach a little further? What if he had not read the books first but considered the goal – answering those questions. Why not read the questions first and specifically look for the answers in the books? Does this sound like test driven development (TDD)?

Let’s think about how the student measured his progress. In the original plan, he was checking off activities as done (reading each book) each time he finished a book. He was on schedule during the reading phase. But the real goal wasn’t reading books. He wouldn’t get any credit from his teacher for just completing the reading. His success was measured against how many questions were answered and how well he answered them. So measuring progress against reading wasn’t realistic. On the other hand, if he had reviewed the questions first, then read those books to answer the questions, and measured his progress against answering questions, that would have been a better measure of progress. If you think about this in the software development world, this is similar to an iterative process. You complete (read) a set of stories and go through the tests for just those stories. But is this approach good enough? Is this agile?

Let’s take this a step further. I realize this may not work well with the homework example, but bear with me. Imagine that the student has the option of taking a set of answers from one book at a time to the teacher and getting feedback. The teacher might have said that a one-word answer was not good enough, and that she was expecting a paragraph, or that she was expecting correct spelling. In this case, the student could have made some changes to the way he produced these deliverables (answers) and could have scored better on each subsequent book.

One could argue that the teacher should have defined all the success criteria (minimum number of words in the answer, no spelling mistakes, etc) at the beginning of the week so everyone would know what they were measured against. I agree; the teacher should have. Translating this to software development, one could argue for collecting all the requirements upfront and getting a sign-off from the user. Then again, we have seen so many times that requirements are a moving target. We can get sign offs and freeze those requirements, only to find that we have to make changes later. Sure, we can keep complaining about how changing requirements interferes with our plan. However, at the end of the project, we can call it a success only if we deliver what the customer really needs, not what we signed off to do in the beginning. We can do that only if we are open to change and if we are getting frequent feedback. Getting frequent feedback from the user and making changes accordingly is the heart of agile. It is not enough to iterate through user stories or components.

As for the developer in my first example who kept saying he was on track; he may not have been hiding anything or lying at all. He may have been just following the plan like the student reading the book and checking off activities on his schedule. Or he might have meant something that we hadn’t been paying attention to such as: "Yes, we are on track but I haven't tested this with the other components."

Sometimes the organizational structure and/or process do not lend itself to getting frequent feedback from the user. What do you do in that situation? Tell me a story about your project.

Challenging inertia through Scrum

By Rahul Sawhney

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

Role of Product Owner

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

Customer reviews and frequent releases

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