Interview with Thomas Zimmermann by Monika Zofia Potiopa


There are still many misconceptions about Agile, such as it meaning no documenta­tion, no processes or no plans. What steps do you think we can take to eliminate these misconceptions?

At the end of the day, if you talk about Ag­ile and particularly Scrum, you of course have documentation. Consider a list of user sto­ries, which is essentially another way of doc­umenting what you want to do. It is a com­mon misconception to say that there is no specification. Correct – there is no specifi­cation in the form of a traditional document. Instead the same content is represented in a different, but much more effective way, i.e. as a prioritized list of user stories. A user story backlog can be online, also suitable for distributed teams. Many tools exist to sup­port this. A user story in a backlog is different to a use case or user requirements. The em­phasis is on the business value for a user. It’s even more specific as you describe in a user story, what the user wants and why. You also add acceptance criteria.

So bottom line, scope documentation exists, no longer this thick book with many pages, which nobody reads and which takes too long time to create – and once it is done, the project scope meanwhile has changed. It’s a different way of doing the same thing and it is incorrect to state that there is no documentation. In addition to that, and as I mentioned in my presentation, agile is the project management methodology. But if you are in product development you very likely also have a standard product develop­ment process which also requires documen­tation as output. This is particularly very important in an industry, which is highly regulated and must be auditable. This set of documents is not related to agile, but necessary. So overall there is documenta­tion – user stories to describe the scope and documentation mandated by a product de­velopment process.

Fot.Robert Chmara


If we hear someone saying that there is no documentation, no process, no plans etc.is it our role to clarify it and make them understand?

Yes, it is. Show and make them under­stand! Another point is where this percep­tion is coming from and why people say that there’s no documentation, there’s no plan? The best thing is to tell and show them that there is of course a plan. There is always an overall plan. It doesn´t matter if you work “agile” or “traditional” or anything in-between, you must have a clear understanding what you want to achieve in your project! A com­mon misunderstanding, when talking about Agile, is that you start working not knowing what to do or what you want to accomplish. Of course, you should very well know what to do! A high-level specification exists, a list of prioritized high-level user stories. On a more abstract level, you very well know your plan, but the tiny little details are not necessari­ly known yet. Your sprints are your plan and by having an understanding of the team’s capacity you also can estimate schedule and cost. By re-prioritizing your backlog, you adopt quickly to necessary changes on a lower level. Yes – sometimes the scope changes by removing items which eventually are not providing business value. But you still maintain the overall goal. And the goal must be defined! It is the traditional thinking that you need to have a detailed plan. Maybe we were trained as project managers to create complex Gantt Charts, to insert sophisti­cated dependencies between tasks, and so on. But this is worthless. Why? Because in reality, nobody ever works according to this detailed plan. Creating too detailed plans is a waste of time. It comes from old school thinking. Not to be negative, but it is just something project managers are used to. And things you are used to do stick in your brain and you hesitate to leave the comfort zone and try something new. And something new… cannot be good? I really recommend to review all the details put into plans and perform a reality check!


Don’t you think that the Agile Manifesto can be subject to many different interpretations? And perhaps that is where these ideas are coming from?

Oh yes! The Agile Manifesto can be in­terpreted in many different ways. And that is what happens. For example. The fourth element of the manifesto “Responding to change over following a plan”, is often in­terpreted as – “there is no plan”. But this is wrong, as I mentioned before. Reading the sentence carefully implies that there is a plan. So you can understand it this or that way. This is the flexibility people have to in­terpret terms differently. If you talk to the people working for a while in agile or at least in an agile mood, they understand very well that there is always a plan. They also under­stand that working agile is very disciplined. There is a wide-spread misconception that agile means free for all. Better to understand and apply the concept of structured freedom and the framework of rules and strategies.


What would you say to people who are us­ing agile only because it’s fancy?

I would ask them why they want to go agile? What’s the business value, what’s the real reason? Do you want to save time? Be more flexible and change requirements more easily? Do you want to save on costs? When managers come and say: „Okay cool. I heard about agile – let’s do this!” I’m always asking them: „So what for? What is the reason?”. If a project is in trouble and somebody comes up to me and says „Let’s switch to agile” I say: „Well… it won’t help. You can do it, but it won’t help”. Moving to agile is not solving problems. If you project is already in trouble, agile won´t rescue it. Agile methodologies provide much more transparency and by that you may be able to detect trouble spots much earlier. However, if you are already in deep trouble, going agile won´t help a lot. It is important to understand the rational why people want to go agile. Clarify it before you go for it! This can avoid surprises or disap­pointments later and manage expectations.

Fot.Robert Chmara


You also said in your presentation, that doing Agile is not equal to being agile. How do you think we could learn these agile mindsets?

This is a little bit harder to answer because you learn agile by experiencing it. Under­standing the agile way-of-working is chang­ing your mindset. And that doesn´t happen from one day to the other. How would you change your mindset? Your mindset changes when you have positive experiences. When you try things out, eventually also faiI, but continue learning by doing and gaining ex­perience. I can give you one example. I was working with a company in Romania with a group of software developers, where we in­troduced Scrum. They had never heard about Scrum before. So we had an agile coach that helped there, got things going. Everybody in the team was eager and open to trying a new way-of-working together. So we started to move in to Scrum and after a while the whole team really loved it. After a while, the Agile coach went away. The team was so self-organized and believed in what they were doing to such an extent that they were running it on their own. I, as a project man­ager, didn’t need to do anything else any­more. So I really felt to be the “Lazy Project Manager”, which was wonderful. The team switched from doing separate, individual work, to working as a team. They got to this point as a team by experiencing the posi­tive side and the power and effectiveness of an agile working mode. How good a team works together is always depending on the people, their characters, their mindset, their workstyle, their experience. You always have different people in teams, usually some are more reserved, some are more open, and it’s the mixture of the individual characters that makes the teams spirit. To sum up, the mindset and the spirit are changed by good experiences.


You mentioned that you love retrospec­tives. I am a big fan of them as well, but from my experience, it is very hard to make people open up. They might feel these ret­rospectives are about assigning blame and looking for the guilty party. How would you try to change their mindset in that regard?

Retrospectives are always about trust! And trust is not something which is simply there. Some people don’t trust each oth­er. Some are more open minded and trust­ful. Various methods and tools exist to help you facilitating retrospectives. Simply search for different methods and tools. You can only learn by doing this and it is very easy. I prefer retrospectives which give the team some fun experience which helps them to open up. When people start talking to each other, they become more open. Like with anything else, you need to break the ice. If people are very close-minded, they don’t say anything. But that is also ok. If people don’t want to share anything, do not enforce this. Building up trust in a team takes time. You might need to run several retrospectives to recognize that trust is building up. But nev­er give up on retrospectives. Stick to them, even if you think there´s nothing to talk about. The point is – you don’t know upfront. Often enough the team was arguing about the need for a retro as they believed there is nothing to share. But after we did the ret­rospective, almost always something was coming to the surface and we had excellent discussions and actions. Even if the retro is only 5, 10 or 15 minutes long, just make it happen. Don´t forget or ignore. To me, retro­spectives are one of the most essential and important part in an agile project process.