Anyone who's serious about their work works agilely. Even large companies are dabbling in agile methods. There's talk of rapid iterations and a new team structure, of Scrum and sprints. Upon closer inspection, not everyone means the same thing. We asked two agile experts: What does Agile mean, and what is Scrum?
Agile is no longer a niche topic: In a study conducted last fall by the ICT industry association Bitkom, more than half of companies with more than 2,000 employees reported already using agile methods. Another 15 percent plan to use them this year. Scrum is the method of choice: 79 percent of the companies surveyed that report using agile methods rely on Scrum.
Agile originally described an approach to software development. In the 2001 published "Manifesto for Agile Software Development" lists four relatively general guiding principles and twelve principles. The manifesto calls for close collaboration between developers and customers in short coordination loops. Individual developers are granted considerable freedom in their work.
Scrum is a method of agile teamwork. The rules according to which a product can be developed with Scrum are Scrum Guide There, three roles in the Scrum team are defined: The Product development team works completely independently and chooses his own working method. In addition to the developers, there is a Product Owner, who is responsible for the product and its features, but is not part of the development team. A crucial but somewhat nebulous role is played by the Scrum Master: This person monitors compliance with the rules and accompanies the work process. They coach the development team as needed and ensure that the developers have access to all the resources they need to complete their work. Various feedback loops at regular intervals ensure that the results of the work are constantly monitored and optimized. Daily coordination sessions are planned within the team. After completing a work phase of up to one month—a so-called sprint—all participants come together, discuss the results, and plan the next steps.
Christian Kroemer and Tobias Hingerl are software developers at Comsysto ReplyThey work according to Scrum themselves and support companies in implementing agile methods. We had the opportunity to speak with the two agile experts.
First of all, to get started: What is Scrum, what is Agile? And who are agile methods suitable for?
Tobias Hingerl: Scrum is a framework and thus one of many agile approaches. The two are often confused or even equated: "Agile is Scrum." However, that's nonsense. There are many other models, frameworks, and agile methodologies. Agility is the foundation of Scrum. If you work with Scrum without adhering to agile values, you're using a tool you don't understand.
Christian Kroemer: Agile is essentially suitable for almost everyone. Agile is a mindset that strongly emphasizes learning. Hopefully, almost everyone has a job where there's something to learn. It makes sense to incorporate points where you reflect on how the work is going and where you can improve. Agile therefore makes sense anywhere where more than two people work together. At least on an interpersonal level, there's always room for improvement.
“The basis is to constantly question your work”
Why should I want to work agile?
Christian Kroemer: Because you want to survive in the market. If you're operating in a rather uncertain context, as is probably the case with most startups, it doesn't help to create a five-year plan and stick to it as precisely as possible. Instead, you should work in the shortest possible iterations and learning loops. I believe you're working agile when, after two years, you can say: I had no idea two years ago that I'd end up like this, but I'm convinced this is the best possible outcome.
Tobias Hingerl: The foundation is to constantly question your work: Am I still doing the right thing? And I think that's even more important for a startup than for a large company, because otherwise you're simply gone after two years.
That sounds pretty similar to the idea of the Lean Startup: testing a product as quickly as possible in order to improve it or let it fail early.
Christian Kroemer: Lean Startup is about focusing on what truly creates value and trying to leave everything else out. I think that's relatively essential for a startup because you simply have very limited resources. It also plays a role in Agile. The Agile Manifesto, for example, states: "A working product is more important to us than super-detailed documentation." Personally, I believe the core of it is the desire to learn as quickly as possible. I can show someone a product—even if it's just a very rudimentary prototype—and get feedback.
Tobias Hingerl: If I've drafted a document somewhere that describes all the features, but I haven't done anything yet, then I don't know if it will work. I also don't know how much work it will take. I can't get real feedback from anyone. In that respect, this lean approach helps you recognize more quickly whether you're doing the right thing. But agile is more than just iterative work. Above all, it's about omitting things that are just overhead, like five-year plans and monitoring whether you're sticking to them. That doesn't help you do the right thing; at most, it helps you persist in doing what seemed right five years ago.
Where is Scrum applicable? Only in software development?
Tobias Hingerl: This is clearly defined in the Scrum Guide: For product development and "complex adaptive problems." If you don't have that, you don't need Scrum, and perhaps you don't need agile methods at all. The human element of improving through reflection probably always works. But if your product isn't complex—meaning you can't plan exactly where it's going in advance, and it's not adaptive, meaning you can react flexibly and with short lead times—then agile product development isn't really worth it.
“This is a stark break with classical structures”
What are the different roles in the Scrum team?
Tobias Hingerl: On the one hand, there is the development teamWithin the team, there are no roles, no testers, and no architects who tell the others what to do. The team should be able to complete all tasks that arise. The keywords are: self-organized and cross-functional. In addition, there is a Scrum Master and a Product OwnerThe Product Owner is often appointed by the customer and is responsible for the idea behind the product and the budget. The Scrum Master has a more supportive, coaching role, not interfering too much in day-to-day business, but observing from the outside, perhaps providing input, and, above all, being responsible for ensuring continuous learning and improvement within the team. If a team is completely new to agile methods, then a Scrum Master must also do a lot of explaining, teaching, and perhaps even moderate meetings closely so that the team understands how Scrum works. The goal, however, must always be impediments (Editor's note: Obstacles) so that the team can work in a self-organised manner in the medium term.
What background do Scrum Masters typically have? I once heard a friend describe them as "IT people who are fed up with IT."
Christian Kroemer: Bad Scrum Masters often come from this area. For good Scrum Masters, I don't think background matters all that much. What all good Scrum Masters have in common is their passion for working with people and driving things forward. Whether someone has a strong IT background, or a background in psychology, education, or something else, I don't think it matters all that much. I've seen good examples from both backgrounds.
A Scrum Master doesn’t have to understand what the development team is working on?
Christian Kroemer: Not necessarily. I think it helps, but it's a controversial debate in the agile community.
Tobias Hingerl: Many Scrum Masters also work part-time as developers, which is often the case with us. This sometimes makes the work more difficult, because you're wearing two different hats with two different responsibilities. The developer might want something different than a Scrum Master.
Is it a problem that the job of a Scrum Master is too little for a full-time position and too much for a part-time position?
Christian Kroemer: This is also a frequently discussed question. There's a nice saying about it: A good Scrum Master can manage two or three teams simultaneously, while a very good one can only manage one. I don't know if that's true, though. If I work as a Scrum Master in an organization that truly embraces agile practices, I might have less to do. But then I have the time to coach individual team members one-on-one and thus advance the entire team.
Every Scrum Master finds their own style. This requires several years of experience. We can teach how Scrum works and how to get started in training. But you can't really teach someone what it means to be a Scrum Master in two days. The Scrum Guide doesn't say much about it either.
What exactly does the authority to give instructions look like in a Scrum team? A Scrum Master is not a supervisor.
Tobias Hingerl: This is a very important topic. Only the development team has the right to decide how the team completes its work. This is a stark departure from traditional structures. Some companies that implement Scrum make the current team leader the Scrum Master and the department head 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 initially sound surprising for Scrum: For example, if everyone on the team agrees that a developer is the best software engineer and that architectural decisions should always be made by that developer, then that's fine. The important thing is that the decision comes from the team and not from the manager. However, the team must also be able to tell the developer when they are no longer the right person for the job.
Who then has personnel responsibility and who conducts salary negotiations?
Christian Kroemer: I don't see that happening with a team member. If you know you'll be negotiating your salary 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 that goes in the wrong direction. There are also companies that work with a Open Salary work. Your colleagues will then decide what you earn. And they certainly won't reward you for playing the hero but actually doing nothing.
What do the review rounds look like in Scrum?
Tobias Hingerl: There are two formats: the review meeting and the retrospective. Both take place after a sprint, which lasts at least one and a maximum of four weeks. During the review meeting, all stakeholders review the product together: Does it meet expectations? If not, it is adjusted for the next sprint. The retrospective is the team's internal feedback loop: How are we implementing things? The Scrum Master typically moderates this. There is frequent discussion about whether the product owner should also participate in the retrospective, especially if the customer provides the position.
“There are customers with 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. The first phase involved two years of writing the requirements specification and specifications. This was followed by four and a half years of development. After six years, the product was presented to the customer. But no one knows whether the product is what the customer envisioned six years ago. At the beginning, no one knows whether the previously agreed budget and timeline can even be met. Frankly, that's simply dishonest. In agile, that can't happen. You get feedback much earlier. This improves the result.
Christian Kroemer: I also see further advantages on a soft level: At least here in Germany, and especially in Munich, and especially in IT, we have a relatively clear labor market. Effectively, we can both choose where we want to work, for example. I don't think the classic project business is necessarily the environment that attracts the best people. Plans are made that are typically very ambitious. This creates a lot of pressure on the team. That's not good if you want employees to feel comfortable. This also gives employees no incentive to think about whether they're actually doing the right thing. They follow the plan, and you lose the creative people. Furthermore, it's much more motivating when a developer hears directly from the customer that they've solved a specific problem than when the project manager says, "Great, we met the deadline," but the developer has no idea why.
Aren't there complaints from customers who say: I pay so much money and now I have to work with you all the time?
Christian Kroemer: Yes, there are clients like that. Agile collaboration doesn't make sense with them. However, we've also implemented projects in such a way that we still work agile internally. We then send the client an interim report without obligation. This usually automatically provides us with feedback that we can use as a guide.
Tobias Hingerl: I think there's been a shift in thinking in this regard. I don't know many clients anymore who say, "Come back in a year and show me the results." People can 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 if the service provider works agilely?
Christian Kroemer: Some large customers require a fixed price for their purchases. We then communicate clearly: This figure is our Best Guess at the moment, but we don't really understand your domain well, we don't know your technology, you'll definitely have requests for changes in six months, and we want that too. We want to give the customer a lot of freedom, but honestly, we can't promise 100 percent how the whole thing will look. If a customer then says, "I'm not going to do that," it's probably best not to accept the order at all. Otherwise, our employees will just get frustrated. We don't want to play around with that dishonesty.
There are exciting proposals for dealing with this uncertainty contractually. If a project takes longer than estimated, for example, the service provider and client can split the additional costs according to a fixed formula. If the project is completed faster, the service provider's margin increases, but the client also pays less. This brings both sides into the same boat and avoids a fight against each other. This is just one example of many. However, if you know and trust each other, a fixed daily rate is naturally the simplest.
“It is important to make things explicit and to continuously improve them.”
The Agile and Scrum approach seems very formalized. The "Scrum Guide" and "Agile Manifesto" sound a bit like holy writ. Is it heresy to deviate from the pure doctrine? Or are they just guidelines?
Christian Kroemer: We recently held a workshop with Peter Götz, who co-promotes the concept for Scrum.org, one of the leading organizations. He said that fundamentally, it doesn't matter to him whether someone does Scrum correctly or not. If you want to do something differently, that's perfectly fine. It can still be agile and exactly right for your environment. But from a formal perspective, it's just not Scrum—which isn't a bad thing. Only if you call something Scrum should it really be Scrum. Large corporations, in particular, that want to become agile often slap the "Scrum" label on something completely different.
If a startup says: We want to become agile and use Scrum — what would be the first steps to take to get there?
Christian Kroemer: I wouldn't commit to Scrum at all for now. There are other methods, like Kanban. That says: It's important to make things explicit and to continuously improve them. When you introduce Kanban, you don't change anything at all. You start with your status quo and respect that things are the way they are. After all, you probably don't just have idiots in the company, but people who do things for a reason. Then you increase transparency as much as possible, make everything explicit, and establish some form of retrospectives, reflection, and continuous improvement. That alone is super agile, regardless of whether it's called Scrum or whatever.
