Any self-respecting businessperson uses agile work principles. Even large companies give agile methods a try. Then it’s all about rapid iterations and a new team structure and also about Scrum and Sprints. If you take a closer look, they don’t all have the same idea of what Agile means. We asked two Agile experts: What does Agile mean, and what is Scrum?
Agile ceased being a niche topic quite a while ago: In a study by Germany’s tech sector association Bitkom from last fall, more than half the companies with more than 2,000 employees stated that they already work with agile methods. A further 15 percent said they plan to use them this year. The method of choice is Scrum: 79 percent of the surveyed companies that said they work with Agile count on Scrum.
Agile originally described an approach to software development. Published in 2001, the “Manifesto for Agile Software Development” lists four relatively general values and twelve principles. The manifesto calls for close cooperation between developers and clients in short feedback loops. Within the framework, each individual developer is given a great deal of freedom for their work.
Scrum is a method for agile cooperation in a team. The rules that can be used to develop a product with Scrum are written down in the Scrum Guide. It designates three roles in the Scrum Team: The Product Development Team is completely self-organizing and selects its own working methods. In addition to developers, there is also a Product Owner who is responsible for the product and its functions but is not part of the Development Team. A decisive but also somewhat vague role is played by the Scrum Master: They make sure the rules are followed and support the work process. They coach the Development Team if needed and make sure the developers have all of the necessary resources for their work. Various feedback loops at set intervals are meant to ensure that work results are constantly monitored and optimized. Within a team, feedback meetings (Daily Scrums) are scheduled daily. After completing a work phase that lasts a maximum of one month — which is called a Sprint — everyone involved meets up, discusses the results and plans the next steps to take.
Christian Kroemer and Tobias Hingerl are software developers at Comsysto Reply. Both work using Scrum and help companies use Agile methods. We had the opportunity to talk with both Agile experts.
Now just to get started: What is Scrum and what is Agile? Who are Agile methods suitable for?
Tobias Hingerl: Scrum is a framework, which makes it one of many Agile approaches. They’re often mixed up or even considered synonymous: “Agile is Scrum.” That, however, is nonsense. There are a lot of other models, frameworks and Agile methodologies. Agility is the foundation of Scrum. If you work with Scrum without being committed to Agile values, then you’re using a tool that you don’t understand.
Christian Kroemer: Agile is basically suitable for just about anyone. Agility is a mindset that relies very heavily on learning. Hopefully almost everyone does an activity where there’s something to learn. Then it makes sense to integrate points where you can reflect about how work is going and where you can improve. That’s actually why Agile makes sense anywhere where 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 with Agile?
Christian Kroemer: Because you want to survive on the market. If you’re in a somewhat uncertain situation, which is probably the case for most startups, creating a five-year plan and sticking to it as closely as possible won’t help, but working in the shortest possible iterations and learning loops will. I think you’re working in agile terms if you can say after two years that: I had no idea two years ago that I would be where I am now, but I’m convinced that this result is the best possible result.
Tobias Hingerl: The basis is constantly questioning your work: Am I still doing what’s right? And I think that it’s even more important for a startup than for a large company because you might otherwise just be gone after two years.
That sounds pretty similar to the Lean Startup concept: testing a product as quickly as possible to improve it or let it fail early on.
Christian Kroemer: In a lean startup, it’s a matter of focusing on what really brings value and trying to leave out everything else. I think that’s fairly essential for a startup because you really just have very limited resources. That also plays a role in Agile. For example, the Agile Manifesto says: A working product is more important to us than super-detailed documentation. I personally think the core idea behind it is that you want to learn as quickly as possible. A product — even if it’s just a very rudimentary prototype — is something I can show someone and get feedback on.
Tobias Hingerl: If I’ve prepared a document somewhere where all the features are described, but I still haven’t done any of it, then I don’t know if it can actually work. I also don’t know how much effort it will require. I can’t get any real feedback from anyone. That’s exactly where a lean approach helps because you can tell faster if you’re doing things right. Agile is also more than just working iteratively. Above all else, it’s about leaving things out that are just overhead, like a five-year plan and verifying that you’re following it. It doesn’t help you make sure you’re doing things right, all it does is make sure you insist on doing what seemed right five years ago.
Where can Scrum be used? Just in software development?
Tobias Hingerl: That is clearly defined in the Scrum Guide: for product development and complex adaptive problems. If that’s not what you have, then you don’t need Scrum and perhaps any Agile methods either. The human part, improvement based on retrospection, could probably always apply. But if your product isn’t complex, or in other words: You can’t exactly plan how things will go beforehand and you can’t react in adaptive terms, meaning flexibly and with short lead times, then Agile product development won’t really be of any use.
“That’s an extreme break with conventional structures”
So what are the different roles in a Scrum Team about?
Tobias Hingerl: First you have the Development Team. No roles are assigned within the team. There aren’t any testers or architects who tell the team what they should do. The team should be able to complete all of the tasks that come up. The key words are: self-organizing and cross-functional. There is also a Scrum Master and a Product Owner. The Product Owner is often selected by the client and is responsible for the idea behind the product and the budget. The Scrum Master plays more of a supportive, coaching role and doesn’t really get too involved in daily business, but instead observes from afar. They might also help motivate and are most importantly responsible for making sure that the team learns continuously and improves continuously. If a team is just starting out with Agile methods, then a Scrum Master will have to explain and teach a lot and perhaps also rigorously moderate meetings to make sure the team understands how Scrum works. The whole time, the goal always has to be removing impediments so the team can work in a self-organized manner over the mid-term.
What kind of background do Scrum Masters usually have? Something I once heard from an acquaintance was: “IT guys who don’t feel like doing IT anymore”
Christian Kroemer: You often find bad Scrum Masters in that kind of situation. For the good ones, I don’t think their background is all that important. Something that all good Scrum Masters have in common is that they genuinely like working with people and want to make progress. I don’t think it’s really that important if someone has a strong IT background or comes from psychology, education or wherever. I’ve met people from both sides who are good examples.
A Scrum Master doesn’t need to technically understand what the developers are doing?
Christian Kroemer: Not necessarily. I think it helps, but that’s also a controversial debate within the Agile community.
Tobias Hingerl: A lot of Scrum Masters still work part-time as developers, at least that’s often the case for us. That can also sometimes make working more difficult because you have two different hats on and two different areas of responsibility. The developer in you might want something else than what the Scrum Master wants.
Is it a problem that the Scrum Master job is not enough to be full-time, but is too much work to be part-time?
Christian Kroemer: That’s an issue that’s also discussed quite often. There’s a nice phrase: A good Scrum Master can simultaneously take care of two to three teams; an excellent Scrum Master can only take care of one. I’m not sure if that’s true or not. If I work as a Scrum Master in a company that truly works in Agile terms, then I might have less to do. But that also gives me the time to coach each individual team member, which helps to promote the entire team.
Every Scrum Master figures out their own style. But you need a few years of experience first. We can teach people how Scrum works and how to get started with training. But you can’t really teach anyone what it really means to be a Scrum Master in two days. There’s hardly anything about it in the Scrum Guide.
Where’s the authority in a Scrum team? After all, a Scrum Master isn’t a supervisor.
Tobias Hingerl: That’s a very important issue. How the team gets work done is decided by the Developer Team. That’s an extreme break with conventional structures. Some companies that implement Scrum make the previous team manager the Scrum Master and the department head becomes the Product Owner. The Product Owner then tells the Scrum Master what needs doing and the Scrum Master tells the team. That isn’t Scrum.
Christian Kroemer: There are some solutions that might sound surprising for Scrum at first: For example, if everyone in the team agrees that one of the developers is the best software engineer in the team and they should always make the architecture decisions, then that’s okay. What’s important is for the decision to come from the team and not from a supervisor. The team also has to be able to tell the developer if they’re no longer the right person for the job.
Who is responsible for staff and who conducts salary negotiations?
Christian Kroemer: I don’t think it should be one of the team members. If you know you’re going to be negotiating your salary with your Scrum Master in two months, you might just do certain things to look good, even though it doesn’t actually help the team. That’s an incentive that goes in the wrong direction. There are also companies that work with an open salary, which is when your colleagues decide what you earn. They definitely wouldn’t reward you for playing the hero but not actually doing anything.
How do Sprint Reviews work in Scrum?
Tobias Hingerl: There are two formats: the Sprint Review and Sprint Retrospective. Both are held after a Sprint, which lasts at least one but no longer than four weeks. During Sprint Reviews, all of the stakeholders look at the product together: Does it live up to their expectations? If not, it will be adapted in the next Sprint. The Sprint Retrospective is the feedback loop within the team: How do we get things done? The Scrum Master usually runs it. A regular discussion is whether the Product Owner should also take part in the Sprint Retrospective, especially if they’ve been selected by the client.
“With some clients, it doesn’t initially make sense to work with Agile.”
What advantages does Agile working offer compared to classic project work in terms of budget, timeline and hierarchy?
Tobias Hingerl: First and foremost, adaptability. For example: As a college student, I worked for a federal agency. During the first phase, we spent two years writing the product requirements document and scope statement. Then four and a half years of development followed. After six years, the product was shown to the client. No one knows, however, if the product is what the client specified six years ago. And no one knows in the beginning if it will even be possible to adhere to the specified budget and timeline. To be frank, that’s just dishonest. That can’t happen with Agile. You get feedback much earlier, and that makes the results better.
Christian Kroemer: I think there are even more advantages on a soft level: At least here in Germany, and specifically in Munich, and even more specifically in IT, it’s pretty clear that the job market favors employees. We both could basically choose where we want to work. I think the classic project development business is not necessarily the environment where you attract the best people. That’s where plans are made that are typically very ambitious, which puts major pressure on the team. That on its own is not good if you want to have happy employees. There’s also nothing to motivate employees to think about whether they’re doing things right or not. They follow the plan and you lose the creative people. It’s also a lot more motivational for a developer to hear directly from the client that they solved a concrete problem than to have a project manager say: “Great, we met the deadline,” but the developer has no idea why.
Don’t clients complain and say: I’m paying all this money and now I have to do all this work with you?
Christian Kroemer: Yes, that kind of client does exist. It doesn’t initially make sense to work with them with Agile. But we have implemented some projects where we still work using Agile within the team. We simply send the client interim results with no strings attached. We usually automatically receive feedback that we can use for orientation.
Tobias Hingerl: I think a change in thinking has taken place. I don’t know too many clients who would now say: Come back in a year and show me the results. People have seen for themselves that it doesn’t work.
Isn’t it much more difficult for the client to plan how much a project will cost and how long it will take when the service provider works with Agile?
Christian Kroemer: Some large companies need a set price to be able to make a purchase. What we communicate quite clearly is: This number is our best guess at this point in time, but we don’t understand your domain very well, aren’t familiar with your technology and you’ll definitely want changes made in six months, and that’s something we welcome too. We want to give clients a lot of freedom, but we can’t honestly guarantee how it will all look as a whole. If a client then says: “I won’t go along with that,” then it’s probably best to not even accept the job. That would just frustrate our employees. We don’t want to even play with that kind of deception.
There are some interesting suggestions about how to deal with that uncertainty contractually. If a project takes longer than anticipated, the service provider and client could share the additional costs using a predetermined formula. If we finish faster, then the service provider’s margin increases, but the client also has to pay less. That puts both parties in one boat and prevents fighting against one another. That’s just one of many examples. If you know and trust each other, a fixed daily rate is of course the easiest solution.
“It’s important to do things explicitly and to improve them continuously”
Working with Agile and Scrum seems very formalized. “Scrum Guide” and “Agile Manifesto” sound a bit like sacred texts. Is it heresy to deviate from the doctrine? Or are they just guidelines?
Christian Kroemer: We just recently had a workshop with Peter Götz, who represents the concept for Scrum.org, one of the leading organizations. He said it basically doesn’t matter to him at all if someone does Scrum properly or not. If someone wants to do something differently, that’s totally okay. It can still be Agile and just right for that person’s situation. But from a formal point of view, it isn’t Scrum — but that doesn’t matter. But if you call something Scrum, then it really should be Scrum. Particularly large companies that want to become Agile often stick a “Scrum” label on something that’s completely different.
If a startup says: We want to become Agile and use Scrum — what initial steps would need to be implemented to get there?
Christian Kroemer: To begin with, I wouldn’t even fixate on Scrum yet. There are other methods too, like Kanban. It says: It’s important to do things explicitly and to improve them continuously. If you implement Kanban, you don’t change anything at all to begin with. You start with your status quo and respect things as they are. And I’m assuming you don’t just have idiots in the company, but rather people who do things for a reason. Then you increase transparency as much as possible, make everything explicit and establish some kind of retrospective, reflection and continuous improvement. That alone is already super agile, regardless of whether it’s called Scrum or whatever else it might be.