Month: November 2011

How to Staff an Agile Team

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.

Agility through Business Process Automation?

Sometimes business process automation (BPA) is described as the silver bullet to improve agility and time to market. Especially large vendors spend huge amounts of marketing budget to promote their BPM tool suites, “360 Degree”- and “Zero Code”-approaches.

But why does BPM increasy agility? Is it really easier to adapt processes to business changes if a process has been automated using a BPM suite?

Sometimes yes, in the narrow range of allowed options. Often no, cause IT-coded processes are not as flexible as people in an organisation. But that does not mean that business process automation is a bad idea at all. There are areas in which process automation makes perfect sense.

Especially processes for which the following factors apply:

  • clearly structured and predictable
  • repetetive
  • frequently executed

Interestingly, often agility does not come from automated processes itself, but rather from the people who have their hands free for other more sophisticated ad hoc processes. We have experienced that in a large project for an international organisation from the public sector. Provided people have the right skills, BPA can help turning people from “routine workers” to “knowledge workers” (see It is All Taylor’s Fault). BPA allowed them to automate their repetetive tasks. It was a great improvement and productivity gain for the people and the organisation. The key was to give them a tooling that they were able to control, even without much help from IT guys.

Knowledge workers do not need their processes automated. They need other tools mostly to get the right structured information at the right time. IT can help in this regard, but not via BPA. I would call this Business Process Facilitation (BPF) rather than automation.

BPF means giving the people tools to do their job in a efficient manner without imposing predefined processes on them. In other words, it leaves the process and decision power with the people not the machines. User centered dashboards, search engines and adaptive case management tools are examples for BPF. We have experienced this in another project in which we evaluated the value of process automation using a BPM-Suite. In this highly dynamic environment the decision was to not implement BPM as it would have hindered agilty. Instead we implemented BPF to support the knowledge workers. The system mainly focused on efficient data management and decision making.

All in all it is not black and white, not Taylorism against knowledge work. Success comes from a combination of both. The key is focusing on things that are beneficial for the people and organisation. Sometimes it is automation, sometimes not. Process automation is cleary no silver bullet, but if applied wisely and with the right focus it can help organisations to improve efficiency.