The book This is Agile: Beyond the basics. Beyond the Hype. Beyond Scrum by Sander Hoogendoorn covers situations that enterprises can encounter when adopting agile, and provides solutions on how to deal with them. It is a translation of the Dutch book Dit is Agile.
To get an impression of this book you can download an excerpt of This is Agile.
InfoQ interviewed Sander about managing agile projects, balancing the work in iterations, and different kinds of agile approaches.
InfoQ: There are already many books about agile. What makes your book This is Agile different?
Sander: It’s basically the same with any subject. Usually there are many textbooks about what a specific approach or technique is, and there are fewer books that look at a subject from practical experience. As with my previous book on use cases and UML, my book on agile captures nearly twenty years of experience in short iterative and agile projects. From the trenches. So I’d say it goes way beyond the basics, and way beyond the hype that agile is. It gives many small hints and tips and contains many authentic anecdotes.
InfoQ: In your book you talk a lot about how to manage agile projects. What are the main differences from a project point of view when you work with agile teams? What makes a project agile?
Sander: Personally, I don’t really care whether a project is agile or not. Being agile is not a goal; it’s a means to achieve your goals. So if you consider your projects to be successful, please don’t change the way they are run, waterfall or not. But if you do want to have a checklist of what makes agile tick, there’s a short checklist in one of the earlier chapters of This Is Agile that sums it up more or less. Think of short iterations, a small unit of work, continuous planning, early testing and simple communication.
InfoQ: Some question if organizations still need projects when they adopt agile. Can you share your thoughts on this?
Sander: It depends on how you define projects. In my opinion, a project is scoped to reach a specific goal, within a certain period of time, with a defined group of people. The more straightforward the goals are, and the shorter the period of time and the group of people, the bigger the chances of success. We’ve seen many large and complex projects fail in this industry. That doesn’t mean that projects are bad.
However, if it is hard or impossible to define a single concrete and achievable goal, or if you are conducting continuous development, such as product development, it might be a better idea to just work on a backlog, and simply pick the next item from this backlog as soon as the previous item is finished, moving beyond projects, and beyond iterations as well.
InfoQ: Your book talks about the facilitating project manager. Can you elaborate on this?
Sander: In my opinion the role of agile coach, and specifically the role of scrum master, is highly overrated. Many people enroll in certification programs and are certified in whatever; that doesn’t mean that they are able to manage the environment of the project, the organization, steering committees, etc. This is typically the role of the facilitating project manager. So yes, I do see a role for project managers in agile projects. However, it is quite different from that in traditional projects, where project managers distribute tasks and control the schedule.
InfoQ: Balancing the work that can be done in an iteration can be hard. What can teams do to find a good balance?
Sander: I would recommend not trying to treat each sprint or iteration as a mini-project. As we are not good at estimating our work, why bother? A lot of teams spend a lot of time in trying to figure out how much work they can do exactly in a two or four week period. And often don’t succeed in that, resulting in what people refer to as “failing sprints” or even “red sprints”. So stop doing that.
InfoQ: In your book you mention different kinds of workshops for agile teams. Can you give some examples?
Sander: The one I would recommend most, is a workshop I refer to as the “design session”. Different from what a lot of teams do, we don’t do backlog grooming, or whatever people call this, at sprint kick-off. We only start working on a work item as soon as we pick the item from the backlog, which could be any day during a sprint. And that’s when we conduct design sessions, usually right after the daily stand-up, since everybody’s there.
InfoQ: Why would you do workshops, which benefits can they bring?
Sander: There’s a lot of benefits from doing these design sessions. Basically it gives you the opportunity to merge the ideas from all the different roles in the team. The client (or product owner if you insist), the analysts, the developers, the testers, maybe the enterprise architect. Different people have very different views on the work items. Mixing those gives the best result possible in designing your work items. And it prevents rework later.
InfoQ: One of the possible solutions to manage agile requirements is with smart use cases. Can you describe how this works?
Sander: In short, smart use cases is a proven requirements technique, that is based on traditional use cases, but adding a modeling approach that, much more than user stories, offer projects a way to structure the requirements of a project. If you model smart use cases following the guidelines from the approach, you still have small work items for your agile projects, but the way you elaborate on them during sprints is much more standardized than you do with user stories, allowing teams to estimate, build and test your work items better.
InfoQ: Your book mentions lightweight and middleweight agile approaches. Can you name some, and elaborate on when you could apply which one?
Sander: I consider approaches such as Scrum, Extreme Programming and Crystal Clear as lightweight. They have very minimal process, only a few roles, and present very little advice, for instance, on how to deal with architecture, requirements or design. Although this makes them widely applicable, it also leaves a lot of questions open for teams, especially for starting teams. Middleweight approaches tend to have a bit more ceremony, such as preliminary iterations for preparing the project, or how to deal with requirements. Examples are DSDM, Smart of Feature Driven Development. In the end, in any case, you should assemble your own agile approach from the practices from any of these approaches, and sometimes even leveraging techniques that were available from before you went agile.
InfoQ: There's a chapter in your book on bumps and potholes that you can encounter when traveling the road from traditional to agile. Can you name some of them, and give our readers advice how to deal with them?
Sander: There is quite a lot that can go wrong in agile projects. Going agile is not a silver bullet that solves all your problems. Agile projects can and will fail too. A very common anti-patterns is what I refer to as Scrumdamentalism. This pattern shows up with teams that just start with Scrum, and tend to apply it in a very dogmatic way. I’ve seen projects that literally didn’t have a project plan, just because the scrum master said that you don’t have project plans in Scrum. Just because the Scrum guide doesn’t mention it that doesn’t mean it isn’t useful.
Another very relevant agile anti-pattern we’ll see more often in the coming years is that many organization will start to institutionalize agile, and produce an agile handbook. This often is a starting point for teams to just adopt this handbook and stop learning. And in my opinion, the day you stop learning, is the day you will start loosing the benefits of being agile.
Sander Hoogendoorn is the author of the best-selling book This Is Agile and is an appreciated dad, programmer, software architect, speaker, and writer. As principal technology officer and global agile thought-leader at Capgemini, Sander innovates and coaches software development at Capgemini and its many international clients. He has published more than 250 articles in international magazines and is an inspiring (keynote) speaker at many international conferences. Twitter: @aahoogendoorn.