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.

The Scrum Team Composition

By Steve Miller

Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark. While Agile has different "flavors", Scrum is one process for implementing Agile. This newsletter is one in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases.

Team Composition

Managing Scrum development requires a major change in how teams work together. In traditional Waterfall development, teams normally have a project sponsor, a project manager, analysts, designers, programmers, testers, and documentation specialists. Each team member has specific duties which normally do not normally overlap and they have a specific reporting structure (most team members report to the project manager).

With Scrum, you have just 3 team roles and is normally limited to 7 or less individuals (however, you can have multiple Scrum teams in sets of 7 or less):

• Product Owner - This is the person that identifies and prioritizes the features that will appear in a 30 day sprint. This is normally the Product Manager, CTO, in some cases the CEO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product. Before a sprint begins, the Product Owner communicates the goal of the sprint to the team and what features should be analyzed for the release. This does not mean that all the desired features will make it into the sprint, the team estimates and prioritizes items for the sprint (during the Sprint Planning sessions), and only the items that can fit in the sprint are done.
• ScrumMaster - The ScrumMaster is akin to the Project Manager in Waterfall environments, but does not manage the team deliverables at a micro level. Instead, this person is responsible for ensuring that the 30 day sprint stays on course, no new features are added to the sprint, code inspections happen, and ensuring everyone plays by the rules. The ScrumMaster coordinates and runs the daily sprint meetings. The ScrumMaster is not a task master, they are a leader that empowers the team members to deliver the assigned tasks and to help eliminate roadblocks that slow them down.
• The Team - With Waterfall, a team consists of analysts, designers, testers and documentation specialists. With Scrum, each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature. This includes analysis, design, coding, testing and documentation. The Team is responsible for staying focused on assigned tasks, soliciting help as they encounter road blocks, fully testing their code, refactoring code, logging their time daily (including estimated time remaining on each task), and for checking their code daily or more often if possible.

Our Experiences with Team Composition

In our experience, it is unrealistic to assume that The Team can handle quality assurance and documentation well. We have improved the team composition to include 2 additional roles:

• Software Quality Engineer - This individual is responsible for the quality of the sprint. In our experience, programmers do not test code with the same mentality as a Software Quality Engineer (SQE). Once specific requirements are defined, the SQE develops a set of test cases (manual or automated) to test each requirement fully. Before coding begins, the test cases are made available to the programmers on the team. The programmers are expected to run each test case before marking coding as being complete. Once a requirement is marked as being complete, the SQE is responsible for running the test cases again to ensure they all pass. The SQE also runs a weekly regression to ensure that legacy features are not compromised by the release. If the SQE has developed automated test cases for regression, those are run daily or more frequently, if needed. The SQE does not wait until the end of the sprint to begin testing, they test once a requirement is completed. By the end of the sprint, all testing has been done and regression has been run frequently.
• Documentation Specialist - The Documentation Specialist (DS) is responsible for creating User Guides, Administrator Guides and other training materials. In our experience, programmers do not always have the written communication skills to write documentation in a way that a laymen can interpret it, that is why it is important to have a separate resource for this function. Once a requirement has been fully tested by the SQE, the DS begins the documentation of that requirement. The DS does not wait until the end of the sprint to begin this, the end of the sprint includes all completed documentation.

6 Tips for Good Scrum

by Martin Harris

I went along to the London Scrum User Group yesterday evening.  For a change it was a quiet night.  Christmas is around the corner so we had less attendees.  Nigel Baker of AgileBear kicked off and suggested putting together 15 tips for good scrum.  After some discussion, we came up with 6 good ones, and in true Agile style, we decided that if you did these 6 well, you would be in front of the pack.  So we stopped there and got on with eating the snacks and drinking the beer.  So here is what the group came up with, look at your team and ask yourself if your doing these, if not, perhaps its time for a scrum experiment?

The London Scrum Groups 6 Good Scrum Tips

• Love your product owner. The group agreed that the product owner should be part of the team. Include them in the meetings and get them involved. Its possibly the most important thing you can do for success in scrum. A fully integrated product owner will spot early on if the stories do not match their expectations. They negotiate the definition of done for a story. They are on hand to answer questions during the iteration removing waste and improving understanding of the stories. The product owner decides if the team has finished stories at the demo. Working closely with the product owner can avoid going adrift and missing your goals, saves a lot of stress when things hit a rough patch as they get to see the problems first hand. We agreed that this point can not be understated, if you do nothing else do this.
• Run Retrospectives. Its very important to take actions away from a retrospective.  Be realistic though, your never going to solve them all, so ask the team to priorities them.  If your doing the retrospective right your product owner will be there to help with prioritization.  If you find something very big lands at the top, split it down into stories.  Otherwise pick one or two that the team feel strongly about and turn them into stories.  Make sure these stories are included in the next game planning sessions and make it into the iterations.  If you have adjustments to the process you can implement these straight away, but experiment with it, and try to measure the impact of changes, you might not get the process right first time.  Commit to doing them and then deliver.
• Ask your team to Pair Code. The XP technique of two programmers working on the same task.  It was agreed that there are different kinds of pair coding and that they all have a place, but the one we are talking about here is where two equal programmers work together to improve quality and throughput.  Don’t be dogmatic, let the team decide how much work should be pair coded.
• Setup Self Directed teams. Self directed teams have been proven to be more efficient.  We discussed the role of a scrum master in a self directed team.  Its very important that the scrum master does not tell the team how to work, or how to go about completing the tasks.  The scrum master does not plan or allocate tasks.  The empowered team needs to work out what the tasks are and find out how to finish the stories.  The scrum master should spend his efforts removing blocks for the team, checking quality.  Its important for the team and scrum master to spot if someone is not completing their work for whatever reason, but a strong team will sort out those kinds of issues if truly self directed.  We also decided that to be empowered you need to make the team multi discipline.  Include testers, user interface designers etc to remove hand off waste and increase team knowledge.  With role diversity comes better decision making.
• Deliver what you commit to. Another gem, it sounds obvious but is so often ignored.  Delivering builds trust in the team and the process.  Classic ways to miss delivery include: Failing to produce a strong definition of done.  The definition should include the programming, integration, testing and setup tasks.  In fact everything required to get that task ready for delivery.  Another way to miss delivers is to fail to demonstrate at the end of the iteration.  You may think your done, but when the product owner sees the work for the first time they may request refinement.  If you have kept your product owner close then the demo is likely to be painless.  No power-point slides please, only real working software in the demo!  So commit and then deliver what you commit to.
• Co-locate your team. The group defined co-location quite tightly.  Co-location is not putting everyone in the same office.  Its putting the team members next to each other in the same space.  Intra team communication does not happen with the team scattered around an office.  You should be able to turn around and join the stand up meeting.  This closeness, speeds up the myriad of tiny important messages that pass around the team.  Some of which is non verbal.

After this rich discussion we gave up on the 15 tips idea.  If your doing these, then your doing very well indeed, and are likely to get better over time.

So another excellent meeting, a few more beers and I headed home enlightened, well fed and slightly merry.  Why not come along to the next one, we could use your input.

7 Tips for Improving Daily Scrum

by Artem Marchenko

Daily Scrum also known as daily standup meeting is an important element of the Scrum process. The structure of the meeting is quite rigid and fixed. Everybody has to stand up, meeting should take no longer, than 15 minutes and everybody should answer three questions: "What did you do since the last meeting?", "What are you going to do until the next meeting?", "What impedes you from being more productive?". The purpose of this rigidness is for making sure that daily Scrum is to help team members synchronize between themselves, not to solve problems.

Things to watch during the daily standups are:

1. Standup means stand up, no sitting, really.
Standing up on the daily Scrum draws attention to the brevity of the meeting. The purpose of the meeting is synchronization and no lengthy problem solving. Standing helps to remember that problem solving except the smallest one has to be taken offline - nobody likes to stand for an hour while two guys are arguing about the protocol implementation details.

2. Keep it short. 15 minutes max.
Everybody can spend 15 minutes a day on synchronizing with the others. Especially if it happens to be immediately before or right after the lunch time. Spending half an hour is a very different story. In my experience most of the time the 5-6 person teams are usually done in just 7-10 minutes.

3. Stand in front of the visual progress artifact.
Ideally in front of the task board together with the product and sprint backlog. Visuality and tangibility help discussing things. If task board is used, developers often like waving hands towards the card being currently discussed or even move the cards during this meeting.

4. Everybody should be present.
One of the main reasons for meeting live is to utilize as wide communication bandwidth as possible - people are known to communicate more effectively, when meeting live. If particular team member is unable to participate, another person should report on behalf of his/her. If it is impossible for some reason, catch up later.

5. No typing.
Holding a laptop and making notes is power. The one who types immediately starts looking as a manager and often subconsciously starts writing what he thinks was meant, not what team members actually said. If you need notes, take micro-notes by hand.

6. Concentrate on the second and third question, not on the first one.
What's done is more of a context for the second and third questions. The real point is to figure out what's blocking the efficient work and who could help it.

7. If team talks too much to ScM, tell him not too look at the team.
Daily standup is for synchronizing between the team members, not between Scrum Master and the team. If team members start behaving as they are reporting to Scrum Master, he can start literally looking at another person or even walk away a little. Such small tricks are often able to confirm that daily Scrum is for the team members and not for the Scrum Master.

Daily Scrum is a powerful tool, but as any other tool it is good, when you know what it's useful for and have some experience in using it. The above seven simple tips can be good starting points or reminders. However, every team knows best how to adjust its standups to serve them better. The important part is the goal, not the method.