Scrum as a Diagnostic Tool

Use the Scrum lens for inspection

What is Scrum? If you ask this question, you might hear a rich variety of answers. Reaching from „a method to process tasks“ over „a project management framework“ to „an instrument for organizational change“.

But this is not Scrum. These are different applications of the Scrum framework. Scrum is essentially just a collection of useful and proven to be succesful rules and practices. It is a theoretically close to ideal state for product development.

If you assume the Scrum framework to be a close to ideal state, then you can use it to find problems in different contexts – even without applying  it immediately. Let me give an example: Some years ago I was in trouble with a classically led project. At the same time I learned about the Scrum framework and thought: „How would it be, if we wanted to practice Scrum tomorrow?“. After asking myself this question, several issues why this would not work came to my mind, immediately. E.g. we would find no Product Owner, the customer would never work with us on a daily basis and we could never deliver software every two weeks. Thinking for a while I realized, that these issues where just the problems the project suffered from. Thus, trying to imagine using Scrum in my current situation helped me to consciously realize what the real problems were.

This idea is scalable: If you want to know what the real top five problems of an organization are, just go to a diverse set of people in this organization, explain shortly what Scrum is and ask them if this would work for them. Then carefully listen and note the reasons mentioned for the impossibility of using Scrum. After several interviews try to cluster and prioritize the issues you found and I bet you will have a very close picture of what the central and demanding problems of the respective organization are.

Just try it. This is much cheaper than hiring a consultancy and will – probably – deliver very similar results ;-)

Leadership Dojos

I see – and hear of – many organizations having trouble with leadership. Starting with the question „what is leadership?“ reaching to problems in concrete application of leadership skills in daily business. One urgent question is: „How can we make clear to leaders in our organization, what leadership is and what our organizations expectations to leaders are?“. Seminars and trainings are a frequently chosen approach in trying to sharpen the understanding of leadership in a company. But I have my reasons to doubt this tools are working.

A very pragmatic and effective way to deal with problems of alignment and lack of practice in software development and coaching are coding dojos and coaching dojos. I tried both tools and found them to be very useful in making clear what the expectation of the trainer is and recieving valuable practical lessons. Transfering this concept to the topic of leadership could look as follows:

1. Choose a standard – but not so easy – situation from the field of leadership (e.g. a worker is not motivated, there is a conflict between two co-workers, etc.)
2. Try to model the situation as good as possible and prepare a role play. There are three roles: the „leader“, the „challenger“ and the „observer“. Distribute these roles to at least three people („challenger“ and „observer“ might be taken by more than one person)
3. Take a time frame of approximately 30 minutes and a room where the prepared situation would be likely to happen in reality.
4. The „challenger“ will now try to play his prepared role as good as possible and the „leader“ has to try to „solve“ the given problem. The „observer“ is not allowed to speak and just observers the situation and makes notes for a later discussion.
5. After playing the role play for 30 minutes the game is stopped and the observer tells the leader about his observations. At this point expectations of an organization to their leaders can be made clear in a very practical, effective and sustained way (if the observer knows about these expectations).
6. Restart at step 1 based on the feedback oft the observer.

Did you try something like this before? What are your experiences? Do you have further ideas for concrete situations to role play? Feel free to use the comments section for your feedback!

Build Flexible Organizations!

It is said, that one of the huge challanges of our time is the great volatility of end customer markets. To face this fact, many companies debate, how to cope with this new market reality. Not surprisingly there are thousands of solutions out there, eagerly sold by consultancy companies:

• You need a flexible and highly adaptive IT ecosystem (see SOA)
• You need to be flexible in handling your requirements (see, Agile, Scrum)
• You need flexibility in your high level planning processes (see Beyond Budgeting, Beta-Codex)
• You need flexibility everywhere. Google for "flexible it solutions" and you will find more than 60.000.000 hits...

But having implemented this "solutions", lots of companies find themselves in situations where they are not really satisfied with the flexibility they gained. Why?

It is just not sufficient, to demand all your processes, tools and people to be flexible. After all it is not your processes, tools or people reacting to the market - it is your entire organization as a system, reacting.

Thus, if you want to stay competitive your first priority should probably be to design or redesign your organization in a way that the resulting system is capable to cope with change as a whole. In other words - you should try to build an organization that avoids organizational dept. 

One of the major challanges of our time might therefore be, to build a sustainable organization where management, leadership and structure are much more situational and much less permanent.

It's not the Manager, Stupid!

There is not only plenty of talk about corporate culture. Another beloved target when talking about grievances in organizations are managers. This is not very surprising, since by nature they hold exposed roles and have great impact on the organization and its members. Additionally you will easily find flaws in every single manager, which makes him an easy target.

Bad news here: The manager is not the problem! The manager is a human individual like you and me. Of course he has his mistakes. As you and I have, too. Only do this mistakes have a much greater impact than do those of your fellow workers.

The real problem is, that the system he works in allows his errors to have such an enormous effect. There are only few mechanisms to mitigate bad decisions met by individual managers. Besides this many organizations do not have working mechanisms to cope with individuals not suitable for such a position (if they once have the position). Such mechanisms (for coping with organizational dept) are certainly a key success factor for sustainable successful organizations.

Organizational Dept

In the field of software development, there is a metaphor called "technical dept".  In short, this metaphor says that while you are programming you almost always build up dept. Dept in this case means that your code base decreases in quality over time. You will have to invest time and work to amortize this dept. If you do not amortize your dept, interests will take effect. Thus, as with regular dept, you will always be better off to amortize the dept as soon as possible. Otherwise compound interest will be the effect and at the end you will pay heavily - if you are able to pay back at all anymore.

Speaking about Agile transformations there is another kind of dept. I would call it "organizational dept". It is based on the same concept as technical dept but on an organizational level. As your organization grows, you will take hundreds of decisions. Not all of them will be perfect and thus, you will (with every decision) increase the organizational dept. How does organizational dept look like?

There are multiple instances of organizational dept. Just to mention a few:

• People in the "wrong" position (on jobs they are not suitable for)
• A wide gap between the culture wanted and the culture existing
• Unresolved conflicts between people
• ... and many more ...

As with technical dept, if you do not regularly and fastly cope with organizational dept, interests will occure and over time compound interests will make your dept almost unbearable. At some point you might not be able to pay back at all anymore! Speaking of technical dept, the consequence for a software system is then to be displaced by a new system. What do you think will be the consequence for a company if you get into this state with organizational dept...? I think, we all know!

This is one point why Agile is so successful. Agile folks generally reject living with dept and always try to pay back as soon as possible. The incarnation of this attitude is e.g. the retrospective in Scrum and the focus on continuous improvement and impediments in all Agile methodologies.

Update: Sven Winkler picked up the idea of organizational dept on Boris Glogers Blog and adds some interesing points of view.