Top 7 Requisites for Scrum Teams

By Laszlo Szalvay

One of the Scrum method’s biggest selling points is its capacity to yield hyper-performing teams. Of course, Scrum teams aren’t just your run-of-the-mill dev teams. There are certain requisites—seven of them, actually—which teams should adhere to if they’d like to see Scrum transform their group into a well-oiled machine:

1. An ideal team includes seven members, plus or minus two. According to study, small teams work together best. Once a team grows to more than nine or shrinks to smaller than five, its ability to perform well as a team is greatly diminished.
2. Teams are comprised of cross-functional members, including software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. By creating a team composed of individuals with backgrounds in a diverse range of disciplines, a spectrum of opinions, ideas, and experiences are represented in the group. Not only does this mean that all development activities can be performed by the group, it also means that multiple perspectives will inform difficult decisions.
3. Team members should be located in the same room, called the team room. While a single location for the team won’t ensure success with Scrum, it helps a lot. When a team is able to work within the same, small vicinity, Scrum’s emphasis on communication and collaboration can be maximized.
4. If teams aren’t located in a team room, they’ll need a Scrum tooling solution. When a team is dispersed geographically, however, a Scrum tooling solution is usually required to keep a team connected. In especially fast-paced development environments, a tooling solution may be necessary for collocated teams, as well.
5. Teams negotiate work with the Product Owner. While the development team must complete the work negotiated in the sprint planning meeting, it has some say in the amount of work it takes on. The Product Owner will expect the team to take on as many story points of work as possible, within reason. (The team would reference its established velocity for previous sprints to negotiate how many story points would be reasonable.) The value of this process of negotiation is twofold. It protects the development team from becoming swamped with an unrealistic workload. It also manages the expectations of the Product Owner, who, in turn, can do the same for customers.
6. Teams self-organize. Once a team has committed to its work for the sprint, it may determine how to complete those goals autonomously. That is, provided the team’s work is satisfactorily completed by the sprint’s end, it can choose how and in what order that work is completed. This allows natural leadership to emerge from within the team and empowers teams with the freedom to confront impediments with creativity and innovation.
7. Teams’ work should meet ALL acceptance criteria. Most Scrum teams do not award partial credit. Even if 99 percent of a project is “done,” it will be rejected in the sprint review meeting if it fails to meet all the established acceptance criteria. Teams often discover the hard way that a project’s finishing touches are often the most time-consuming and labor-intensive.

Top 7 Responsibilities of a Scrum Product Owner

By Laszlo Szalvay

There are three fundamental roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team. The Product Owner is the one person responsible for a project’s success. In other words, if a project flops, it’s the Product Owner who must face the music. What follows doesn’t include every activity a Product Owner should consider or every rule he or she should follow. In fact, trying to account for every conceivable demand placed on a Product Owner would be impossible. But this list of seven do’s will help aspiring Product Owner make sure they’re covering the basics.

1. The Product Owner leads the development effort by conveying his or her vision to the team and outlining work in the Scrum backlog. The Product Owner drives a project by communicating directly with the team, while visually demonstrating prioritization decisions in the backlog.
2. The Product Owner prioritizes work based on Business Value. Scrum is unique its reliance on empirical data to inform development decisions. Thus the Product Owner prioritizes a team’s work based on the Business Value it will generate.
3. The Product Owner negotiates work with the team. At the beginning of each sprint, the team and the Product Owner meet to determine what work will be tackled for the sprint. However, this work is negotiated, rather than merely assigned. It is the team’s responsibility to update the Product Owner about any impediments obstructing progress to help ensure that prioritization is fully informed. Likewise, the Product Owner must respect the team’s established velocity—a metric used to track how much work a team can accomplish in a single sprint.
4. The Product Owner must remain available to the team to answer questions and deliver direction. Because the Product Owner best understands the vision of the project, he or she will want to remain highly accessible to the development team to clarify acceptance criteria, articulate customer desires, and so on.
5. The Product Owner must resist the temptation to micromanage. Because the Scrum framework vests the Product Owner with authority over the team, while asking that he or she remain available to the team, it is extremely common for a Product Owner to be tempted to behave like a traditional manager and micromanage the team. However, Scrum values self-organization and, as a result, the Product Owner must respect the team’s ability to create its own plan for completing sprint goals.
6. The Product Owner must resist “raiding the team’s sprint.” For Scrum to yield hyper-performing teams, teams must be given the entirety of the sprint to complete work without interruption. This means that a Product Owner is forbidden to give the team more work in the middle of the sprint, which is often referred to as “raiding the sprint.” Even if requirements change or a rival organization unveils a new product that renders the team’s work all for naught, the Scrum Product Owner cannot alter the sprint until the next sprint planning meeting.
7. The Product Owner must not be afraid to make tough decisions. Because the Product Owner is the single person responsible for whether a project sinks or swims, he or she must have the confidence to make decisions that are best for the business. These decisions may be unpopular with the development team, but the Product Owner must consider the expectations of stakeholders and customers first.

Top 7 Responsibilities of a ScrumMaster

By Laszlo Szalvay

There are three fundamental roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team. The ScrumMaster serves as a facilitator for both the Product Owner and the team. It’s an arduous role that demands a distinct personality type to be successful—in large part because the ScrumMaster has no management authority and may never commit to work on behalf of the team. What follows are seven basic considerations that should be at the forefront of any ScrumMaster’s mind.

1. Be a team player. The best ScrumMasters are real team players, who receive as much satisfaction from facilitating others’ success as their own. They must also be comfortable surrendering control to the Product Owner and team. For those two reasons, traditional project managers don’t usually make great ScrumMasters.
2. Remove impediments. First and foremost, the ScrumMaster should do everything in his or her power to remove obstacles that are preventing the team from accomplishing its sprint goals. Basically, anything that distracts or inhibits the team from making progress is considered an impediment, so the challenges a ScrumMaster might work to resolve are truly infinite. When a developer’s computer dies, it’s the ScrumMaster’s job to get it back up and running—or replace it. If developers are complaining about the high temperature in the team room, the ScrumMaster must find a way to cool it down.
3. Radiate information. One of the ScrumMaster’s primary responsibilities is to radiate information or ensure that a team’s progress and successes are highly visible to all stakeholders, including the team itself. These radiators may take the form of various Scrum artifacts, from backlogs to burndown charts.
4. Support the Product Owner. Just as the ScrumMaster removes impediments for the team, he or she also works to assist the Product Owner with various activities. These include communicating updates and impediments as well as assisting with backlog and release plan maintenance.
5. Facilitate creativity and empowerment for the development team. The flipside of the ScrumMaster’s mandate to remove impediments for the team is his or her charge to foster an environment where creativity and empowerment can flourish. If a team is to self-organize to meet sprint goals, it will perform up to its potential if its members feel they have the support and confidence of the ScrumMaster and Product Owner behind them.
6. Improve the team’s engineering practices and tools as needed. To fully facilitate productivity, the ScrumMaster must make sure teams have the tools and know-how they need to succeed. This might include a Scrum tool to bring distributed teams together for close collaboration or introducing a new engineering practice that can help developers improve processes.
7. Communicate, communicate, communicate. Yes, communication is integral to each of the above points, but it’s so essential that it’s worth mentioning again. Scrum’s success hinges on clear and frequent communication among all stakeholders. The ScrumMaster acts as a hub for all of that communication, ensuring that everyone—the Product Owner, the team, and various other stakeholders—are always up-to-speed.

The Essence of Scrum

By Tobias Mayer

Scrum began its life as one of the new Agile approaches to building software.  These days it is considered an approach that can be used to improve the world of work in a more general sense, and indeed, to change the way individuals think and interact with one another in work situations.  The full potential of Scrum has yet to be explored.

In a nutshell, Scrum is a simple approach to the management of complex problems, providing a framework to support innovation and allow self-organizing teams to deliver high quality results in short time-frames. Scrum is a state of mind; it is a way of thinking that unleashes the creative spirit while remaining firmly grounded in some solid and long-respected theoretical principles, including empiricism, emergence and self-organization.

Empiricism refers to the continuous inspect/adapt process that allows both workers and managers to make decisions in real time, based on actual data, and as a result respond quickly to ever-changing conditions in the surrounding environment, most importantly the market place in which the software is sold or distributed.

Emergence results from an empirical approach. It implies that all solutions to all problems will become clear as we work. They will not become clear if we simply talk about them. Big Up Front Design will only result in Big Wrong Design or at best Big Working But Totally Inflexible Design. When we allow solutions to emerge it is always the simplest and the most appropriate solution for the current context that rises to the surface. Emergence coupled with Empiricism will lead us to the most appropriate and the most flexible (i.e. changeable) solution.

Self-organization refers to the structure of the teams creating the product of work. Small multidisciplinary teams are empowered to make the important decisions necessary to i) create high quality product and ii) manage their own processes. The thinking here is that those doing the work know best how to do the work. These teams work in a highly interactive and generative way, emerging the product through continuous dialog, exploration and iteration. Self-organization works when there are clear goals and clear boundaries.

In addition to these principles Scrum relies on two core mechanisms: prioritization and timeboxing.

Prioritization simply means that some things are more important than others. This is obvious, yet quickly forgotten when the “we need it all now” mindset is entered. Scrum helps put the focus back on selecting the most important things to do first — and then actually doing them! Making time to prioritize, and being rigorous about it are essential to the success of Scrum.

Timeboxing is a simple mechanism for handling complexity. We can’t figure out the whole system at this time, so let’s take one small problem and in a short space of time, say one week or one month, figure out how to solve that problem. The results of that will then guide us towards a solution for the next, bigger problem and give us insight into the needs of the system as a whole.

Organizational Change

With Scrum, the management hierarchies of organizations tend to get leveled and development teams have a more immediate and direct contact with customers. The work environment becomes less command-and-control and more collaborative. Regular, open dialog is encouraged over extensive documentation, and negotiated agreement is preferred to formal and impersonal contracts of work.

The qualities of openness, honesty and courage are fostered at all levels, and individual gain becomes secondary to collective advancement. A Scrum environment is a supportive one, where people at all levels show respect and trust for one another. Decisions are made by consensus, rather than imposed from above and all knowledge is shared in a fearless and transparent way.

Scrum goes against the grain for most companies in the software industry, where a phased approach coupled with a high degree of micro-management, and an insistence on defined processes and extensive documentation have been the norm for over thirty years. Many companies rely on fear and money as the key motivators for their workers. This approach has shown short-term success but more and more companies are beginning to understand that it is not a good long term strategy. Nevertheless, the concept of changing to something as radical as Scrum strikes terror into many executive and middle-management hearts.

Scrum is still at the early-adopter stage. It will take many years for the majority of companies to recognize the benefits of creating more trustful and compassionate workplaces. Without such change many software companies will likely sink under the sheer weight of their heavy processes, and overstaffed workforces. Others – those who dare to embrace the lean, lightweight, agile approach of Scrum – stand a greater chance of surviving and prospering. For those who turn to Scrum, and fully embrace it, a reversion back to the old way of working becomes unthinkable. A paradigm shift is occurring in the workplace, and Scrum is an important part of that shift.

Problems You Could Face While Planning Sprints Using Planning Poker

Planning Poker is a process used for estimation during the Sprint planning meeting, many times with actual cards rather than software. The various team members do their estimation of the tasks using Fibonacci numbering sequence, and after a couple of rounds of discussion, a finalization of the estimates are done, and these are converted into Sprint Backlog. However, for teams that are not very comfortable with Planning Poker, there can be several problems as dealing with Planning Poker. Some of these are:

• For somebody who is not comfortable dealing with Planning Poker, the concept of providing estimates in this manner can be confusing to people. Guidance, simulation and some hand-holding during early stages is essential
• There can be ego clashes if the estimates provided by team members vary widely, with the senior team members not being very comfortable if the estimates provided by the more junior ones are accepted. This needs careful handling
• Once numbers are presented in the meeting, then non-team members (including the product owner and senior stakeholders) will accept these numbers, and any further refinements start getting compared against these numbers
• Once somebody sees a number by somebody else, they start getting doubts over their numbers and if given a chance, many of the team members are willing to modify their numbers (just by doing some modifications in their head over the estimation). This can sometimes lead to a quick firming of the estimates towards a more accurate number, but can also lead to a herd mentality behavior
• Planning Poker is hard to do when the team is distributed, and needs more careful planning in terms of logistical coordination
• In Planning Poker, the assumption is that the team member has the required level of knowledge, but this can be inaccurate, what can happen in many cases is that the team has as much knowledge as is available, but there are many blank areas that are not yet filled, whether these be requirements from the product owner, or dependencies that are not known
• In some cases, the Product Owner is not satisfied by the varying estimates, and may want to put pressure to select the lower estimate so as to get more features in the current Sprint. The ScrumMaster needs to be pretty vigilant to avoid these scenarios

Problems With Using Scrum Burndown Charts to Measure Sprint Status or Progress

Scrum is touted as one of the modern new techniques that can get rid of all the problems that people have faced with earlier techniques such as Waterfall (and if one goes by correct theory, Scrum is primarily a Project Management technique, not a broad Project Development methodology. However for those people who are passionate towards Scrum, Scrum has always seemed like a solution that can work for most projects. However, people do find that their burndown charts don’t resemble the idea, with the effort needed not trending down to 0 at the end of the Sprint cycle, instead, it happens that the overall effort required remains at the end of the cycle.

This trend can be very frustrating; if you have a team with around 4 developers, and if you find that all of them have some effort pending at the end of the cycle, it could mean that all of them are just there, but not fully. Instead, there are tasks that you need to call out in the end Sprint review, and they need to be carried over to the next Sprint. Now, this would be fine and part of the normal process if the ScrumMaster is able to do a proper diagnosis of why this happened (and there are multiple reasons for why this could have happened), but when at the end, there is no proper reason, it can get very frustrating for the ScrumMaster.
It feels equally problematic when the ScrumMaster has to depend only on the burndown charts for getting the exact status; since the burndown chart is not designed for getting into the required depth (at this point the ScrumMaster would want to get into exact status of various items and compare the current status of all the tasks with the desired level of completion), and if the ScrumMaster does this often enough, they will lose interest in the Burndown chart. A lot of ScrumMasters don’t want to get into the detailed task level status, since it can be tough to then do a root level analysis of which of the tasks were delayed because of reasons that could be prevented.

What I have found (based on some of the teams that I worked with, as well as some friends who were also doing the ScrumMaster bit), we used the Burndown chart as a good indicator for showing to the team how well they are doing (including whether they were running behind and needed to check whether their velocity was good enough); for actual task tracking, we used various scheduling tools (or even used Excel as a way of tracking); it seemed a bit more effort intensive way of tracking, but worked properly and gave us a much better way of control.

The Advantages of Agile Scrum Software Development

When you start working on a project which will be developing software, you will quickly discover that the development methodology used will have a major part to play in the speed and quality of the code developed. Since Agile Scrum methodology is so widely used it is important that you understand the advantages and disadvantages of it so that you are able to determine whether it is the best fit for your project deliverables.

• Agile scrum helps the company in saving time and money.
• Scrum methodology enables project’s where the business requirements documentation is hard to quantify to be successfully developed.
• Fast moving, cutting edge developments can be quickly coded and tested using this method, as a mistake can be easily rectified.
• It is a lightly controlled method which insists on frequent updating of the progress in work through regular meetings. Thus there is clear visibility of the project development.
• Like any other agile methodology, this is also iterative in nature. It requires continuous feedback from the user.
• Due to short sprints and constant feedback, it becomes easier to cope with the changes.
• Daily meetings make it possible to measure individual productivity. This leads to the improvement in the productivity of each of the team members.
• Issues are identified well in advance through the daily meetings and hence can be resolved in speedily
• It is easier to deliver a quality product in a scheduled time.
• Agile Scrum can work with any technology/ programming language but is particularly useful for fast moving web 2.0 or new media projects.
• The overhead cost in terms of process and management is minimal thus leading to a quicker, cheaper result.

In a nutshell this means that you can get development started fast, but with the caveat that the project scope statement is "flexible" and not fully defined. Hence this can be one of the major causes of scope creep if not managed properly.