Today I would like to share a success story of a project I accompanied as Scrum Coach and Solution Architect from analysis to production.
Main success factors were:
You can read more in the case study Modernization of business partner management.
When you work with distributed teams it is important to have lightweight tools for efficient communication. Here are some free tools that I would recommend:
Surveymonkey – Online polls
DFN Scheduler – Scheduling
Skype – Video and voice conferencing
Chatzy – Private web based chatrooms (port 80 only, mobile access)
Trello – Scrum and Kanban boards (highly interactive)
Kunagi – Scrum boards (includes tools like planning poker)
Teamviewer – Online meetings and remote control (free for non commercial use only)
Scrum is in many respects very different from traditional project management approaches, especially waterfall models. It requires a different mindset in which it is ok to say:
“I don’t know yet exactly how long the project is going take, but give me some time to get to know the requirements and the team. After some Sprints we will give you a solid estimation based on empirical knowledge. Trust us, we do the best we can to deliver quality on time”.
For many especially “classic-minded” project managers such a statement is unimaginable. They simply can’t understand the culture of Scrum as it is very different from what they are used to.
After applying Scrum in several projects over the last years and after giving many Scrum workshops I think that the only way of learning Scrum is by doing it, ideally accompanied by a skilled coach. Books and certifications help, but they do not create deep understanding.
And here begins the dilemma. Especially managers in larger organisations never work on projects, they manage. Therefore it is hard for them to leave their classic mindset. This leads to non-supportive behavior which often blocks the way to agile adoption in large enterprises. In a recent interview Scrum in larger organisations Jeff Sutherland describes the challenges to change the management mindset.
He says:
“… major challenges you will have to deal with when you implement Scrum in a large organization is to change the mindset in the organization in general and on management-level in particular …”
For the reasons given above this nut is hard to crack. To me it seems that this is impediment number one on the way to agile adoption in larger enterprises.
Many agile techniques such as Kaizen, Sashimi or Kanban correspond to terms and principles found in asian culture. A less known principle is:
“Do not develop an attachment to any one weapon or any one school of fighting”
– Miyamoto Musashi
In the context of agile it means that one should change the process if it helps to achieve the goals. This is something most developers would agree to as processes are often seen as impediments.
The same applies to technology. Translated to the technical world it reads: Do not stick to your favourite technology if there is something better suited to meet the project or customer needs. This is something many developers would not immediately agree to. Developers usually love sticking to their JEE, Spring, .NET, SOAP, REST, [any other technology] with which they grew up. They often argue that learning a new technology is time consuming and therefore hardly possible to change.
I think that is wrong. Provided a developer has a sound background, he or she can become productive in a new technology within a short time. I’ve seen developers switching from JEE to .NET and vice versa without problems. This is possible because technology always evolves. Most new frameworks and programming languages do not reinvent the wheel. The are always based on similar common principles which remain valid and stable over time. It is more a matter of mindset that keeps people trapped in their technology comfort zone.
Is that a problem?
Sometimes yes, especially when paired with Groupthink, it hinders innovation and production efficiency.
How can this prevented?
1. Make sure you have people with long standing experience in different technology domains in your team. People who worked with multiple technologies are usually more willing to reflect technology decisions and align them to the requirements of the business.
2. Don’t start a project with a strong technology committment. Let the team decide which technology is best suited to solve the business problem. Of course in conformance with the corporate standards.
3. Ensure that the team has the freedom to decide which tools they want to use.
Having the option to change weapons (processes, tools, frameworks, etc.) if needed, improves the likeliness of successful project delivery.
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:
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.
Over the last decade I have seen many software solutions. Some excellent and some really bad ones. But most solutions were somewhere in the middle. They just did what they were supposed to do.
But is this really good enough? I don’t think so. Especially today where time to market is critical and the budgets are limited, functioning software is the bare minimum. On top of that other core values are getting more and more important.
Although those values are important for every software project, they are especially important in todays SOA/BPM undertakings as they promise to increase agility and time to market. This can only be achieved with software solutions that are flexible and easy to use. Ideally even for business people without a developer background.
I am glad to be invited to speak at the Agility & User Experience Expert Forum. The conference organized by Accelsis and the Fraunhofer Institute for Experimental Software Engineering is going to take place on 16.June 2011 in Frankfurt/Germany.
The conference is packed with lots of real world examples showing how innovative approaches in the areas of usability and agility can improve corporate software development.
In my presentations I am going to show how agile techniques can be used in fixed price contexts (Yes, that is possible!) and how to achieve real operational agility beyond just Scrum.
I look forward having inspiring discussions and hope to see you there.
You can register here.
People who apply Scrum in their projects are familiar with Tuckman’s stages of group development which describe the phases a team runs through every time it is formed or changed.
The assumption is that the team members have to find their role before they can be productive. They get to know each other and conflicts are resolved during the storming phase.
Then after the norming phase often something interesting happens. When the people feel comfortable with their role they tend to avoid conflicts and discussions. This is natural and not a problem per se, but sometimes it hinders innovation and striving for the better.
In 1952 William H. Whyte already coined the term GroupThink which describes this behavior.
Quotes:
“Groupthink is a type of thought within a deeply cohesive in-group whose members try to minimize conflict and reach consensus without critically testing, analyzing, and evaluating ideas.
During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking.
Groupthink may cause groups to make hasty, irrational decisions, where individual doubts are set aside, for fear of upsetting the group’s balance.”
And indeed if you work with people closely for a longer time (which is common in a Scrum setting), Groupthink is likely to happen. The consequences are underestimated risks, failing sprints and finally not delivering the promised results.
In order to avoid that, a Scrum Master should foster a healthy level of controversy among the team. He or she should encourage the team members to argue for the best solutions.
This must happen in a fair and constructive atmosphere in order not to damage the team. It requires strong interpersonal skills of the team members and the Scrum Master in particular.