Posts Tagged ‘basics’

Back to Basics (The Scrum Team vs. The Team)

2009-10-27

Recently I’ve taken the new Scrum self-assessment available at scrum.org.

I have seen many people missing some basic answers and that got me concerned about the knowledge on the basics of Scrum in general. At this moment, the average score of the assessment is at 78 with a standard deviation of 6.5.

With this in mind, and having scored on the 95 percentile myself, to me, a surprise, I decided to step back from the “Team Series” I was writing and start a series addressing some of the basic concepts, and maybe help people that are starting and eager to learn.

Also, I advise the reading of the scrum.org Scrum Guide for very valueable information.

The Scrum Team is the set that has all the basic roles necessary to use Scrum in a project. The Scrum Team is composed of the Product Owner, the Scrum Master and the Team.

There is no formal management role in Scrum. The Scrum Team shares responsibilities for the project. The traditional management position has it’s responsibilities split among the Team, The PO (Product Owner) and the SM (Scrum Master).

The Team in a Scrum Team is composed of the guys that will actually build the product. This should be a heterogeneous group of people with all the skills necessary to deliver the goal of the project.

The Scrum Team should be composed of 7 people plus or minus 2. The Team in turn should be composed of 5 people plus or minus 2.

The Team is responsible for planning how to meet the goal of each Sprint, monitoring and optimizing the work to meet the Sprint goal daily, monitoring and increasing productivity, resolving its internal conflicts.

The Team works on backlog items until there are done, accordingly to what they told the Product Owner they would do.

The Team is required to participate in all of the Scrum ceremonies. They need to be in both parts of the Sprint Planning, in the Daily Scrums, in the Sprint Reviews and in the Sprint Retrospective.

Only the Team in a Scrum Team can determine how to deliver the product. They are the ones with the skills to deliver and they are responsible for the how. The Team itself is responsible for its own destiny. As they self-manage to deliver the Sprint items, they are responsible for their success or doom.

The Sprint Backlog is owned by the Team. They decide what are the tasks in it, and they update its status.

The Team communicates directly with the Product Owner and other people needed to build the product. There is no need for anyone to act as a go-between for Team members.

The Team should act with diligence and sense of urgency. As an example, whenever a change is needed on the plan for the Sprint, represented by the Sprint Backlog, the change should be done and tasks added or removed as soon as the need is identified, immediately.

The Team decides when it is appropriate to change to update the Sprint Backlog during a Sprint. The Team is the owner of the Sprint Backlog. The SM and the PO do not own the Sprint Backlog.

The Team is responsible for estimating tasks together. The PO and SM have no say in the estimations. The Poker Planning is one of the ways of getting all of the Team members to participate in the estimation process.

The Team should not develop a full plan for the whole project nor should nail down the whole architecture and infrastructure upfront. The Team should leverage Scrum’s Empirical way to its advantage.

The Team should adjust its use of engineering practices whenever needed.

The Team in a Scrum Team is very different than the teams in a command-and-control structure. In Scrum, The Team is empowered to do its job.

Advertisements

What does it really mean to be self-organizing and self-managed in a Scrum Team and why is that important?

2009-06-17

Strictly speaking, a self-organizing system is one where the complexity of the system increases without being guided or managed by an outside source. Usually emergent properties can be observed.
The emergent property is a pattern that arises out of simple interactions within the system.
Self-organization spawns into several different concepts for different areas of knowledge. You can talk about it in Math, Chemistry, Linguistics or in Human Society.
Scrum is inserted in a subset of the self-organization principle within the Human context. The idea of not influencing the Team and allowing it to self-organize is based on the notion that emergent properties for the Team can improve the probability of success in a project.
In Scrum, avoiding external influences creates room for creativity and synergistic behavior. At the same time, periodic feedback influences the Team in the direction of the Product Owner’s vision, and both are the basis for a more flexible response to the difficulties presented in a project.

Increased chance of success by the use of Scrum

Increased chance of success by the use of Scrum

The concept of self-management in Scrum comes directly from the social context in work related matters. Worker councils, worker co-operatives, participatory economics and many other human work situations where the presence of a boss is lessened or dismissed entirely relates strongly to the origin of the concept in Scrum.

It seems to me that the founders of the Agile movement and of Scrum were much more capable and knowledgeable than their managers in the many projects they were involved in. This frustration led to studies on many aspects of group dynamics, and many of those principles were incorporated to the basis of these frameworks.

In software, it is not uncommon that the manager knows less about building software than the team members. Almost always the manager knows less about it than the collectiveness of the group.
The Team knows how to build software, and the manager does not. So, when establishing a command and control process within these conditions, the manager will undoubtly get in the way of the success of the project.
Under this line of thought, self-management becomes an obvious choice because you allow people who know how to do the job go on and do it. There is also the bonus that you might get synergy and emergent behavior.

Scrum does not propose a strict sense of self-organization or self-management. The Team is governed by rules that serve an external purpose. They have to follow the Scrum rules, they have to generate value to the client and they have regular feedback.
The Scrum team has a manager. The ScrumMaster is a manager with authority to enforce policy. The ScrumMaster enforces the continuous feedback process and the proper use of Scrum. The ScrumMaster enforces adherent behavior to the “company’s culture” and is a constant checker of the accomplishment of the DoD.
The ScrumMaster should not impose, however, on the “software building” part of the management because he is not the one with the knowledge on how to do it.
The team is self-managed to build the software, not to do whatever they want.

Also, it must be clear that self-management in Scrum does not imply democracy, or voting, or any other particular form of collaboration within a team. The whole of the group dynamics area of studies should be explored to the advantage of the project.
In my ScrumMaster Certification, Ken Schwaber illustrated how the time ticking and the Sprint deadline were strong factors for deciding conflict, and there was no suggestion on voting or a specific form of conflict resolution. In that particular exercise, the decision was made by the one who said it first (like children calling it first).
What was emphasized was the importance of transparency and broadband communication at all times.

Anakin Skywalker: “Doing what the Jedi Council says, that’s one thing. How we go about doing it, that’s another. That’s what I’m trying to teach you, my young Padawan.” – “Star Wars: The Clone Wars” (2008)

I’m a team member, what must I absolutely know about Scrum ?

2009-06-04

I’m a team member, what must I absolutely know about Scrum ?

If you are a team member and know little about Scrum don’t despair. Here is a small set of recommendations I have for you:

1. You need a ScrumMaster in the team. The ScrumMaster should know about Scrum and will help with your doubts. Don’t think that you have to know all about Scrum, that is his job. There is no need to worry if you don’t become an expert in Scrum. That is not your job.

2. Learning the basic roles, artifacts and activities of Scrum is very easy, and some minutes reading should make you understand them. You should read about it and know the very basics. That’s the easy part and everyone should have it by heart. Give yourself time to learn from experience.

3. Understand that the proper use of Scrum requires good communication. While knowing the basic rules for Scrum is easy, learning how properly use Scrum to your advantage is difficult. Trust your ScrumMaster, talk to him, talk to the other team members. Keep communication channels open. Your ScrumMaster will be able to help you.

4. You have a set of skills and a job to do. If something or someone does not allow you to do your job, something is wrong. Talk to people about it. Let the ScrumMaster know about it. Ask for help. One of the key concepts of Scrum is letting people that know how to do the job do it.

Whether you know about Scrum or not, here is a rule to everyone:

5. No project can succeed if you don’t know your craft no matter how much Scrum you know. Dig into your architecture studies, read about design patterns, read about UML, dive into learning about tests or configuration management. Learn about TDD and continuous integration. All those things are essential to making software. If you are working in a business you know nothing about, take time to understand a little about it. If you can learn about tools that leverage your knowledge, do it.

Get to know YOUR trade first.

A good programmer with a process will outperform a good programmer without it, but all that a bad programmer can do with a process is to report very well how bad things are going.