Anyone who takes themselves seriously works agile. Even large corporations are trying agile methods. People talk about rapid iterations and new team structures, about Scrum and sprints. But when you look more closely, different people mean different things. We asked two agile experts: What does agile mean, what is Scrum?
Agile is no longer a niche topic: In a study by Bitkom, the ITK industry association, conducted last fall, more than half of companies with more than 2,000 employees reported already working with agile methods. Another 15 percent plan to introduce them this year. Scrum is the method of choice: 79 percent of surveyed companies that claim to work agile rely on Scrum.
Originally, agile describes an approach to software development. The “Manifesto for Agile Software Development” published in 2001 lists four relatively general principles and twelve principles. The manifesto calls for close collaboration between developers and customers in short feedback loops. Individual developers are given considerable freedom in their work.
Scrum is a method of agile collaboration within teams. The rules for developing a product with Scrum are documented in the Scrum Guide. Three roles are defined in the Scrum team: The development team works completely independently and chooses its own way of working. In addition to developers, there is a product owner responsible for the product and its features, but not part of the development team. The Scrum Master has a crucial but somewhat nebulous role: they ensure that rules are followed and guide the work process. They coach the development team when needed and ensure that developers have all the resources they need for their work. Various feedback loops at fixed intervals are meant to ensure that work results are continuously monitored and optimized. Daily coordination rounds are scheduled within a team. After completing a work phase lasting no more than one month — a so-called sprint — all participants meet to discuss results and plan the next steps.
Christian Kroemer and Tobias Hingerl are software developers at Comsysto Reply, work according to Scrum themselves, and support companies in implementing agile methods. We had the opportunity to speak with these two agile experts.
First, to get started: What is Scrum, what is agile? And who is suited for agile methods?
Tobias Hingerl: Scrum is a framework and thus one of many agile approaches. People often confuse or even equate it: “Agile is Scrum”. But that’s nonsense. There are many other models, frameworks, and agile methodologies. Agility is the foundation of Scrum. If you work with Scrum without embracing agile values, you’re using a tool you don’t understand.
Christian Kroemer: Basically, agile is suitable for almost everyone. Agility is a mindset that strongly emphasizes learning. Hopefully everyone has a task where there’s something to learn. So it makes sense to build in points where you reflect on how work is going and where you can improve. That’s why agile actually makes sense wherever more than two people work together. At least on an interpersonal level, there’s always something to improve.
“The basis is constantly questioning your work”
Why should I want to work agile?
Christian Kroemer: Because you want to survive in the market. If you’re in an uncertain context, as is likely the case with most startups, it doesn’t help to create a five-year plan and stick to it as closely as possible. Instead, you need to work in the shortest possible iterations and learning loops. I think you work agile when you can say after two years: I had no idea two years ago where I’d end up, but I’m convinced this result is the best possible.
Tobias Hingerl: The basis is constantly questioning your work: Am I still doing the right thing? And I think it’s even more important for a startup than for a large company, because otherwise after two years you’re simply gone.
Tobias Hingerl (l.) and Christian Kroemer (r.) train Scrum masters and work themselves as software developers.
That sounds quite similar to the lean startup idea: test a product as quickly as possible to improve it or fail early.
Christian Kroemer: Lean Startup is about focusing on what really creates value and trying to eliminate everything else. I think that’s relatively essential for a startup because you simply have very limited resources. Agile incorporates that too. In the Agile Manifesto, for example, it says: A working product is more important to us than comprehensive documentation. I personally believe the core idea is that you want to learn as quickly as possible. A product — even if it’s just a very basic prototype — I can show to someone and get feedback.
Tobias Hingerl: If I’ve written a document describing all the features but haven’t actually done anything yet, I don’t know if it will work. I also don’t know how much effort it will take. I can’t get real feedback from anyone. In that sense, this lean approach helps you quickly recognize whether you’re doing the right thing. But agile is more than just working iteratively. It’s also about eliminating things that are just overhead, like five-year plans and controlling whether they’re met. That doesn’t help you do the right thing; at best, it helps you persistently do what looked right five years ago.
Where is Scrum applicable? Only in software development?
Tobias Hingerl: The Scrum Guide defines this clearly: for product development and “complex adaptive problems”. If you don’t have that, you don’t need Scrum and maybe not any agile method at all. The human aspect of getting better through reflection probably always applies. But if your product isn’t complex — meaning you can’t plan exactly where it will go beforehand — and it’s not adaptive, meaning you can’t respond flexibly with short lead times — then agile product development won’t really help.
“That’s a sharp break from traditional structures”
What are the different roles in the Scrum team?
Tobias Hingerl: First, there’s the development team. Within the team, there are no roles, no testers and no architects telling other team members what to do. The team should be able to handle all tasks that arise. The key points are: self-organizing and cross-functional. In addition, there’s a Scrum Master and a Product Owner. The product owner is often provided by the customer and is responsible for the product idea and the budget. The Scrum Master has a more supportive, coaching role that doesn’t really get involved in day-to-day business, but rather observes from the outside, maybe gives impulses, and is especially responsible for ensuring continuous learning and continuous improvement in the team. If a team is completely new to agile methods, a Scrum Master often has to explain, teach, and maybe even moderate meetings firmly so the team understands how Scrum works. But the goal should always be to resolve impediments so the team can work self-organized in the medium term.
What background do Scrum masters typically have? A friend of mine once said: “IT people who don’t want to do IT anymore”
Christian Kroemer: You often find bad Scrum masters from that corner. With the good ones, I don’t think the background is that important. What all good Scrum masters have in common is that they genuinely enjoy working with people and want to move things forward. Whether someone has a strong IT background, comes from psychology, pedagogy, or elsewhere, I don’t think that’s so important. I’ve seen good examples from both directions.
Does a Scrum Master need to understand technically what the development team is doing?
Christian Kroemer: Not necessarily. I think it helps, but that’s a controversial debate in the agile community.
Tobias Hingerl: Many Scrum masters still work half the time as developers themselves, as is often the case with us. But that can sometimes make the work more difficult because you have two different hats with two different responsibilities. The developer might want something different than a Scrum Master.
Is it a problem that a Scrum Master’s job is too little for a full-time position and too much for a part-time position?
Christian Kroemer: That’s also a frequently discussed question. There’s a nice saying about it: A good Scrum Master can manage two to three teams at once, a very good one only one. Whether that’s true, I’m not sure. If I work as a Scrum Master in an organization that really operates agile, I might have less to do. But then I have the time to coach individual team members one-on-one and advance the entire team.
Every Scrum Master finds their own style. But that requires a few years of experience. In training, we can teach how Scrum works and how to get started. But you can’t really teach someone in two days what it means to be a Scrum Master. There’s also very little about it in the Scrum Guide.
What about the chain of command in the Scrum team? A Scrum Master isn’t a supervisor.
Tobias Hingerl: That’s a very important topic. How the team accomplishes the work is a decision only the development team makes. That’s a sharp break from traditional structures. Some companies that introduce Scrum make the former team leader the Scrum Master and the department manager the product owner. The product owner then tells the Scrum Master what to do and the Scrum Master passes it on to the team. That’s not Scrum.
Christian Kroemer: There are also solutions that might sound surprising for Scrum: If everyone on the team agrees, for example, that a developer is the best software engineer and architecture decisions should always be made by them, then that’s okay. The important thing is that the decision comes from the team and not from a supervisor. But the team also has to be able to tell the developer if they’re no longer the right person for it.
Who then has personnel responsibility and who conducts salary negotiations?
Christian Kroemer: I don’t see that with a team member. If you know you’ll be having salary negotiations with your Scrum Master in two months, you might do things just to look good, even though it doesn’t help the team at all. That’s an incentive going in the wrong direction. There are also companies that work with open salary. Your colleagues then decide what you earn. And they certainly won’t reward you for playing the hero but not actually doing anything.
What do the review rounds look like in Scrum?
Tobias Hingerl: There are two formats: the review meeting and the retrospective. Both occur after a sprint, which lasts at least one and at most four weeks. At the review meeting, all stakeholders look at the product together: Does it meet expectations? If not, it’s adjusted in the next sprint. The retrospective is the internal team feedback loop: How do we implement things? The Scrum Master typically moderates this. There’s ongoing discussion about whether the product owner should also attend the retrospective, especially if they’re provided by the customer.
“There are customers for whom agile collaboration doesn’t make sense at first”
What are the advantages of agile work compared to traditional project work with budget, schedule, and hierarchy?
Tobias Hingerl: First and foremost, adaptability. An example: As a student, I worked in a federal agency. In the first phase, they spent two years writing a requirements specification and system specification. Then came four and a half years of development. After six years, the product was shown to the customer. But nobody knows if the product is what the customer specified six years ago. Initially, nobody even knows if the budget and timeline that were set can be met. That’s simply dishonest, frankly. That can’t happen in agile. You get feedback much earlier. That makes the result better.
Christian Kroemer: I also see other advantages on the soft side: At least here in Germany, and especially in Munich and especially in IT, we have a relatively clear employee market. Effectively, both of us can choose where we want to work, for example. I believe traditional project business isn’t necessarily the environment to attract the best people. Plans are made that are typically very ambitious. That creates great pressure on the team. That’s already not good if you want employees to feel comfortable. There also aren’t any incentives for employees to think about whether they’re actually doing the right thing. They follow the plan and you lose the creative people. Moreover, it’s much more motivating for a developer to hear directly from the customer that they’ve solved a concrete problem than to have the project manager say: “Great, we hit the deadline”, but the developer has no idea why.
Don’t customers complain, saying: I’m paying so much money and now I have to work with you all the time?
Christian Kroemer: Yes, there are such customers. Agile collaboration doesn’t make sense for them in the first place. But we’ve also implemented projects so we work agile internally. We then send the customer an interim status without obligation. That usually automatically generates feedback we can orient ourselves toward.
Tobias Hingerl: I think there’s been a shift in thinking by now. I don’t know many customers anymore who say: Come back in a year and show me the result. People see for themselves that it doesn’t work.
Isn’t it much more difficult for the client to plan what a project will cost and how long it will take when the service provider works agile?
Christian Kroemer: Some large customers need a fixed price for procurement. We then communicate clearly: This number is our best guess at this point in time, but we don’t really understand your domain, we don’t know your technology, you’ll definitely have change requests in six months and we want that too. We want to give the customer a lot of freedom, but we can’t honestly promise one hundred percent what it will look like. If a customer then says: “I’m not doing that”, it’s probably best not to take the order in the first place. Otherwise our employees just get frustrated. We don’t want to play this kind of dishonesty.
There are interesting proposals for dealing with this uncertainty contractually. If a project takes longer than estimated, the service provider and customer can, for example, split the additional costs according to a set formula. If you finish faster, the service provider’s margin increases, but the customer pays less too. This puts both sides in the same boat and avoids fighting each other. That’s just one example of many. If you know each other and trust each other, a fixed daily rate is of course the simplest.
“It’s important to make things explicit and continuously improve them”
The way of working with agile and Scrum seems very formalized. “Scrum Guide” and “Agile Manifesto” sound a bit like holy scripture. Is it heresy to deviate from the pure doctrine? Or are they just guidelines?
Christian Kroemer: We recently had a workshop with Peter Götz, who helped develop the concept for Scrum.org, one of the leading organizations. He said he basically doesn’t care whether someone does Scrum correctly or not. If you want to do something differently, that’s completely okay. It can still be agile and exactly right for your environment. But formally speaking, it’s just not Scrum — which is also not bad. But if you call something Scrum, then Scrum should actually be in it. Large corporations wanting to become agile, however, often just slap the label “Scrum” on something completely different.
If a startup says: We want to become agile and implement Scrum — what would be the first steps to get there?
Christian Kroemer: I wouldn’t lock myself into Scrum at all initially. There are other methods, like Kanban. It says: It’s important to make things explicit and continuously improve them. When you introduce Kanban, you don’t change anything at first. You start with your status quo and respect that things are the way they are. Because you probably don’t just have idiots in your company, but people who do things for reasons. Then you increase transparency as much as possible, make everything explicit, and establish some form of retrospectives, reflection, and continuous improvement. That alone is already super agile, regardless of whether it’s called Scrum or whatever.