Posts Tagged ‘team’

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

Java and Tapioca

2009-09-22

Past Saturday (2009-09-19), I was fortunate to speak at the Café com Tapioca.
This year, the event was celebrating 7 years of the CEJUG, Java User Group from Ceará. One of the most active tech groups in Brasil. Those guys did a great job organizing the event.
It was a sunny day, but instead of going to the beach, many people attended the many lectures of the day. In this post I’ll comment on each of them.
Roughly translated to English (all lectures were done in Portuguese), the lectures were:

“The path of productivity for web developers” by Bruno Pereira – Concrete Solutions.

Bruno knows what he is talking about in this presentation. The path for web development is far from clear at this moment and developers need to open their minds now, and explore different possibilities and technologies.
Firebug is definitely a divisor of waters in web development.
The format of the presentation was not very interactive, but I think it would be very hard to show code and be more interactive with so many technologies being addressed. The topic is plenty for a full day on itself just to get you started.

“How to build a JEE/JME application for the 4 corners of the world.” by Régis Melo – Sagarana.

Régis presented his company and main product to the audience. I thought it was interesting to see that the travelling salesman problem can still be sold as a product, and that ILOG has not completely dominated this market.
He also spoke about some of the challenges of exporting software he faced, some similar to what we see here at the company. Brasil’s potential for software is really underestimated.
If we were to set our minds to it, I think India would be in a bad position to compete with us. The similar timezone to the US certainly helps.

“The myth of the agile teams” by Victor Oliveira – Concrete Solutions.

My presentation, below, would perhaps be best enjoyed by managers, and I think maybe not the best presentation for the public present. The local crowd at FA7 was younger, and mostly team members.
The goal was to create knowledge that supporting teamwork needs hard work too. Organizations have to think seriously on what is necessary to nurture teams and make them better and real teams.

“10 bad habits of JSF developers” by Tarso Bessa and Rafael Pontes – Triad Works

This presentation was very technical and really for people that know, and like JSF. Of course, as Bruno’s presentation pointed out, JSF itself is kind of a disappointment. I remember when Microsoft released .NET that JSF was going to be a huge blow in favor of Java technologies for web development. That was around 9 or 8 years ago.
Many years later, the path is unclear with many independent frameworks fighting for space. (Ruby, Rails, Grails, Django, etc) What is certain is that JSF is a good productivity framework, but has a very limited space for its application. After Oracle’s purchase of Sun, JSF’s future looks gray.

“Improving your application with Lucene: get to know Solr and Hibernate Search” by Paulo Jeveaux – Giran

Jeveaux’s presentation was of one of my favorite open source tools in the market. Back in 2004 when I first worked with it I was already impressed, and the evolution with Solr and Hibernate Search only adds to the package.
If you know nothing about Lucene, it is worth your time.

“What killed RUP can kill Agile” by Rodrigo Yoshima – Aspercom

Having worked with RUP for around 7 years, I know how RUP was misinterpreted, especially during the 90’s in Brasil.
The topic presented is important, very important for any software maker that is interested in being better at it. The possible fall of the Agile movement due to it’s misuse or misinterpretation is a clear and present danger. Something I also addressed in my own presentation considering the team aspect of it.
I do think, however, that the separation between just being pragmatic or conservative does not address the change of view that happened once the Takeuchi and Nonaka’s article was in place. In my view, the “theoretical view” from a process control perspective changed the way we viewed what happened before.
Of course, 50 minutes needs a pragmatic approach:-), and the presentation had a good sweet spot.

“Desmystifying TDD in Practice” by Paulo Silveira – Caelum

Silveira’s nervous style of presenting is very engaging and was my favorite presentation. Using a simple TDD example with very simple business rules (stock market) got people eager to participate. It was certainly interactive and fun.
I love TDD ever since I used it for the very first time a couple of years ago. People who have not tried it, really tried it, don’t know what they are missing.

The Myth of the Team

2009-08-18

The concept of teams is one that is widespread viewed as good and taught by parents and in the schools from the very early days of almost every child.

There are many reasons for this culture that have nothing to do with how much better teams work when compared to individual efforts. It is all about getting the young to learn the concept of the other, how to live with the differences, and how to deal with dysfunction and conflict.

A single person can be productive, and also, can have many problems. Putting a group of people together also mean that the possibility for problems is multiplied.

In general, teams will find a stable situation, they naturally seek equilibrium in the relationship of its members in a way they can manage to live together. This means avoiding conflict at almost all costs. People will try to find a comfort zone, even without thinking about it.

The big problem here is that the continuous generation of conflict and resolution is what makes a team more productive than individuals.

Also, conflict is dangerous because it can break the bonds that keep the teams together. Too much conflict destroys the team, too little and the team will produce nothing good.

The team dynamics reminds me of a history book by renowned Helio Jaguaribe (Um estudo critico da História). In this book, he demonstrates by looking at the many different failed and successful societies in history that one of the major factors of success is the good challenge. If the challenge is too great, society is destroyed. If the challenge is too little, society will fall into a comfort zone that stops it in time and will render it unprepared to deal with future difficulties.

The teams are a micro cosmos of society, and like societies, a team needs a good challenge and good conflict to thrive.

The goods of teamwork are not given. It is not by simply putting people together that they will be better together than they are in the sum of their individual efforts.

To find good teams, one will see that there is always a factor that “rocks the boat” when conformance rises, and something to bring a gentle breeze when people are about to kill each other.

To purposely build a successful team is even harder than “finding them in nature”. It is not a task to be underestimated.

Continued here…

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.