Communities of Practice in Scrum

If you have Scrum on a larger scale in place, you will end up with several cross functional (multi-skilled) teams:

Eg. you will have developers, business analysts, and QA resources in one Scrum team. After a while you’ll need to think about know-how sharing and skill enhancements. I propose to implement communities of practice (CoP, for each skill.

A representative for each skill (horizontal community) is sent to the Scrum of Scrum.


Communities of Practice in Scrum

Summary of the Agile Manifesto

The agile manifesto is about presence over past:

  1. Interactions/individuals are now – processes/tools originate from past decisions.
  2. Working software works now – comprehensive documentation is (mostly) out of date
  3. In customer collaboration you know his current requirement – a contract manifests past decisions
  4. A change is happening now – a plan is (mostly) out of date.
Summary of the Agile Manifesto

How the Agile Manifesto translates into Scrum

„Agile“ has evolved into a best practice for software development and has been described by the values described by the Agile manifesto( ):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

In the following Blog I’ll describe how these values translate into the Scrum artifacts. Scrum artifacts are underlined.

Individuals and interactions over processes and tools

In Scrum the team size and sprint length is limited, such that the team can manage their tasks on their own. From a project management point of view the teams works as a whole.

All necessary organization and rules originate from the interactions within the team. The team decides about responsibilities and will manage (external) disturbances collaboratively. The Scrum master helps the team to resolve impediments and assures the (self given) rules are obeyed.

Interactions are amplified by reducing the usage of tools. That’s why Scrum teams prefer Scrum boards with paper cards for task planning and tracking over than (electronic) tools.

Working software over comprehensive documentation

The second value reminds you that the first goal is to create working software that brings value to the customer. Since the subject of the documentation often changes faster than comprehensive documentation can be created too much documentation is just a waste of resources. Agile teams favor delivering software early and often (ideally using continuous integration) to ensure requirements can be validated.

However, documentation is important for further development and maintenance – the challenge is to find the right balance between the necessary documentation and the creation of paper that is never read again. The retrospective after each sprint helps to consider also long term consequences.

Customer collaboration over contract negotiation

The customer is represented by the Product Owner, a role define in Scrum. The product owner understands the customer and has profound business expertise. He is available to the team at any time such that interaction is the main source for alignments.

To avoid any kind of negotiation, the backlog (= open task list) is sorted by the product owner according to the customer priorities, so the customer gets always first what he needs most.

However, this requires a thoughtful and reliable product owner.

Responding to change over following a plan

In Scrum the development is done in sprints, i.e. time boxed. Each sprint is a kind of a small project with a planning, implementation, and review phase. After each sprint the team is re-aligned to the customer needs when they take the topmost items from the backlog.

As most of the project plans are outdated as soon as they are published, it’s just consistent to abolish traditional project plans – only the time of the next sprint is considered. This is counter to traditional project management goals of controlling change and keeping to a plan.

The burn down chart visualizes development speed and progress. In doing so unnecessary work is avoided and the risk of failure is controlled.

How the Agile Manifesto translates into Scrum

My personal introduction to Scrum

When you are completely new in Scrum, it’s a good idea to read an introductory book or browse through Wikipedia. When you’ve learned about the Scrum roles and artifacts, it’s also a good idea just to start with what you’ve just learned. My experience was that the really interesting questions only arise when you actually do Scrum. I’ve done the same and like to share my three Scrum lessons with you:

Implement a process for continuous improvements. Scrum does this trick by strictly “time boxing”: Define some fixed repeating time frame and call it “sprint”. If you run into delay or failure, do not expand the sprint length. After the fixed time period, ask yourself what you’ve achieved and think about how to become better next time. Think about how you can measure your progress. The Scrum artifact for measurement is the burn down chart. If you’re a manager, do not look on it as a new fancy tool to control your team. It’s rather tool for the team to measure their progress and become transparent in what they’re achieving every day. Derive a target what you want to achieve in the next sprint. Find a person who’s responsible that the Scrum rules are obeyed, and call him Scrum master. He/she should do his/her job once a day in the daily Scrum, and you’ve done your first Scrum lesson.

Second lesson is to achieve a team’s commitment. In classical project management there is some project manager who’s going to plan the project. This requires making assumptions about uncertain information and forecasting the team activities. Who is the most able to do this? It’s the team who’s most able to do the detailed planning. Again “time boxing” will do the trick: The sprint length should be small enough that the forecast becomes more certain and the team becomes confident in their plan. If the team becomes committed to the sprint target, you’ve done your second Scrum lesson.

The third lesson is to introduce a Product backlog. The product backlog is an ordered list of all requirements – both functional and technical. Call these entries “stories”. Find the Product owner who owns the product backlog, i.e. has the authority to decide on the stories. At every sprint start, the team selects the top stories from the backlog, plans activities and chooses which part they can commit. This is called “pull principle”. The team should do the decisions late, such that the product owner can decide to rearrange the product backlog as long as possible. This makes the Scrum agile and completes the final lesson.

My personal introduction to Scrum