Tag: Agile

What does collocation mean? The concept is very simple. It means bringing together the people who work on a software product in a physical environment. This seems to be natural. But in highly distributed work environments that we have today it is not anymore.

I’ve been working on agile projects for many years and I always hear that collocation is difficult. Especially in larger enterprises it seems that the hurdles are high. There are many reasons stated by different people.

Here are some examples:

• There are no adequate rooms available (managers).
• The buisiness guys don’t understand IT. We can’t work in the same office (developers).
• The IT guys don’t understand our business. We can’t work close to them (business).
• Our outsourcing partners are from country xyz. It is impossible to work with them in one office (managers).
• The business people have their work to do. They simply don’t have the time to work closely with IT (business).
• I have to concentrate. Working close to others would always disrupt my work (developers).
• We don’t like travelling. (all of them)

All of those are valid arguments, but to me it seems that they are sometimes artificial. In this case reluctancy to change is stronger than the will to increase efficiency.

From my experience collocation is an underestimated factor that can greatly improve effectiveness of teams. The study Collocation Impact on Team Effectiveness goes in the same direction.

Another interesting read is Collocation, Collocation, Collocation. Quote from the blog:
“A big part of the problem is socio-political in nature and would appear to be deeply embedded in the human DNA. We naturally tend to come to trust those that we have regular contact with (our family / village / tribe / region / country / team) and have an equal and opposite tendency to distrust those on the outside of these habitual daily contact networks (all those that the lock on our front door or the defences around the tribal village are designed to keep out).”

If a company is interested in real agility and effectiveness, I think it should try really hard to create collocated work environments and not give up early. It might somtimes be difficult, but the reward will be better results and most likely even better motivated staff.

The German IT magazine Computerwoche published my article about agility and management. The article describes ths difficulties when scaling out Scrum in larger organisations.
You can read it online. Wann Scrum funktioniert: Das Management muss Agilität leben.

According to the second rule of the agile manifesto working software is more important than comprehensive documentation. This is definitely true!
To be clear, this does not mean that software developed by agile teams is not documented. If comprehensive documentation brings value to the organisation, agile teams produce this as well. Specifications are written as well in agile projects. Why? Because it is not (and never was) a good idea to start development without knowing what to implement.
But contrary to waterfall projects in which much of the specification is written upfront, in Scrum the specification is written as part of the sprints. And due to the close collaboration in cross functional teams, the specification can be much more lightweight without loss of quality for the final product. This is all great. But there is a challenge to keep in mind.

When it comes to testing (acceptance, performance, etc.), either as part of the sprint (which is definitely the preferred way), or later when the product moves towards production, the testers have to find and classify bugs. Usually they do this based on the specification. In case a functionality is missing or not working as described in the specification it is a bug.
With a lightweight specification that don’t decribe every little detail it is sometimes hard to tell whether someting is a missing feature or rather a change for a later version of the product. This situation can cause conflicts.

But not necessarily. The important factor is that the testers are part of the agile team context from the beginning, so that they share the knowledge and experience with the rest of the team. In a culture of trust, the team can easily negotiate whether a finding is a bug or a change. If the team is commited to deliver quality (the Scrum Master has the responsibility to educate the team to do so), this model works properly.

This strategy correlates with the conflict resolution scenario Use collaboration to resolve the conflict described in the interesting blog post Know These Five Causes of Conflict written by Karen Ruby.

Quote:
“However, if trust is there, this conflict resolution scenario can be the best way to resolve conflicts once and for all. When both parties come together, communicate, and trust each other a definitive resolution to their conflict can occur.”

Although there is a greater likeliness of success in Scrum projects than in non-Scum projects, Scrum projects sometimes fail as well. If you ask the people involved in failed Scrum projects, they quickly accuse Scrum of being the cause for the failure. They claim to have done everything that Scrum requires, but failed, so the method is blamed.
In agile software development the most important factor is the team, the team and … … yes, the team. But a common misconception is that you just have to put together a few people to get a team that performs well. This is completely wrong, as a group of people is something very much different than a team. A group is just a bunch of individuals who neither strive for the same aim nor have a deep common understanding of the project. And they often do not trust each other enough to perform well. A team is different. People in a team trust each other, they strive for a common aim and share a deep understanding. And they have fun doing what they do. But how can a group be turned into a team?

There are well known social processes that every group has to undergo to become a team. One of those processes is the Tuckman principle of forming, storming, norming, performing (and adjourning). In their readable article Teamwork: Why teams are more successful than groups. Dr. Eberhard Huber and Sven Lindenhahn describe key factors of successful agile teams. This very much matches my expericence both as team member and coach of Scrum teams. It is essential that the group undergoes a productive storming phase in which an internal hierarchy and decision making structure is cultivated. This can be hard and tiring, but is essential for success. The key is to bring together the right mixture of individuals who have the interpersonal skills to find their place in a larger group of people in a constructive way. The ability to make compromises is important.

And even agile teams need leadership! Not from the outside in form of a project manager, but rather from inside the team. There must be people with the interpersonal and technical skills to take leadership. The authority can’t be given by management, but needs to be earned every day. Personality is key.

If you staff your next agile team, make sure you have the right mixture of skills on board. I am not talking about just technical skills, that’s self-evident. Technical knowledge can be easily shared in an agile context. What I mean are personal skills such as:

• Ability to make compromises
• Ability to accept constructive criticism
• Ability to take responsibility
• Ability to take leadership when needed

Don’t expect that the team works in harmony from day one. It is absolutely normal that the team members argue a lot, especially at the beginning. This is not a sign of bad team constellation. It is rather a natural step towards a productive agile team.

Although keeping a Scrum team together 100% on-site is the ideal situation, sometimes it is not possible and the team works distributed. In such situations it might be handy to have a tool that can be used instead the whiteboard. A kind of virtual whiteboard that is accessible from everwhere. A popular modeling tool in IT projects is Sparx Enterprise Architect due to its rich modeling capabilities and fair pricing. In order to use it for Scrum planning, I created a UML-Profile which can be used to easily create and maintain Scrum user stories. The profile contains stereotypes for epics, user stories and tasks together with tagged values to track business value, story points and team responsibilities. In order to use it, download the profile and import it using the resource view in Enterprise Architect as show below.

To use the Scrum model elements, open the toolbox and add them to the palette using the More tools … action at the top of the toolbox dialog.

Now create a new diagram for your Sprint planning. You can use swimlanes (Diagram- Swimlanes and Matrix in the menu) to add stage regions to the diagram. Right click on the diagram pane and click properties in context menu. On the elements tab select Tags and Notes. This gives the Scrum elements a card like appearance on the diagram. That’s it. Now you should have something like this:

You can quickly change story points, etc. and the notes using the tagged values and notes view. By dragging the elements between the swimlanes you can change the status of the respective user stories. The package browser (right click on a package in the project browser) can be used to show all stories and tasks in a table view.

A nice gimmick since Enterprise Archtect 9 is the ability to visualize diagrams in whiteboard mode. Just tick the options Whiteboard Mode and Hand Drawn in the diagram options and you will see something like this:

Because the whole model is stored in a repository, you can create story dependencies by connecting the elements, automatically determine backlog sizes and print story cards based on custom templates.

In my opinion using the whiteboard is still the most efficient way for Scrum planning. But especially in cases where teams are distributed, such an approach is hardly possible. As shown in this post, Enterprise Archictect can easily be turned into an effective Scrum planning tool that can be used in those situations.

You can download the Scrum profile here: Scrum.xml
If you want to change the team members, make sure to edit them in the profile before importing it into Enterprise Architect.