Interview with Thomas Zimmermann by Monika Zofia Potiopa
There are still many misconceptions about Agile, such as it meaning no documentation, 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 Agile and particularly Scrum, you of course have documentation. Consider a list of user stories, which is essentially another way of documenting what you want to do. It is a common misconception to say that there is no specification. Correct – there is no specification 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 support this. A user story in a backlog is different to a use case or user requirements. The emphasis 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 development process which also requires documentation 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 documentation – user stories to describe the scope and documentation mandated by a product development 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 understand! Another point is where this perception 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 common 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 necessarily 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 sophisticated 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 interpreted 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 interpreted 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 interpret 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 understand 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 using 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 disappointments 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. Understanding the agile way-of-working is changing 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 experience. I can give you one example. I was working with a company in Romania with a group of software developers, where we introduced 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 manager, didn’t need to do anything else anymore. 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 positive 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 retrospectives. 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 retrospectives 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 other. Some are more open minded and trustful. 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 never 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 retrospective, 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, retrospectives are one of the most essential and important part in an agile project process.
He began his career as Chip & Software Developer in the automotive semiconductor industry, where he took over responsibilities related to project and program management. After subsequent tasks in the IT consulting department for the automotive and financial industry, he is currently using his practical experience in the medical devices industry, combining traditional and agile project management methodologies to support the development of an endoscopic operating room as a global project portfolio manager and Agile Coach. He was a member of the PMI board in Southern Germany, where he continues to volunteer for PMI in various roles.
Project Leader o technicznym backgroundzie i product managementowej przeszłości. Ex-perfekcjonistka po „odwyku” identyfikująca się z mottem „bądź najlepszym niedoskonałym sobą, jakim zdołasz”. Fanka specyficznego humoru półświatka IT, wiernego kompana (psa) Astona i kryminalnych podcastów!