Head First Agile: Relevance in practical software development world

[Mohamed Sanaulla]

How is the relevance of the topics covered in the book related to Srcum, XP and Lean principles mapped to the practical software development world? Often we have seen lot of books covering the principles, but their applicability or approach to adopt them goes missing.

[Junilu Lacar]

When it comes to topics like this, I think the best that the authors of books can give you is an overview, an explanation of the principles, the patterns of behavior and organization that are helpful, anti-patterns, and other things of a more abstract and high-level nature. It's really up to the reader to find ways to take those high-level concepts and apply them to specific situations. Since there are so many different ways these ideas and frameworks can be applied, I don't think it's realistic or fair to expect the author's work to apply to every readers' situation. If anything, a brief overview of some case studies might be helpful but I see those as nice bonuses rather than required material. It's great if the book has them but I wouldn't necessarily count it against the author(s) if they didn't include any.

Take for example the practice of co-located teams and constantly available users. That's a highly recommended practice for XP and Scrum. However, there are some companies where having co-located teams and users who are always available is just not a realistic expectation. In those cases, you really should go back to the principles/values, which is rapid feedback and constant collaboration. Given that, you have to adapt different processes and practices so that you can still stick to the principles without necessarily following the recommended practice. It's up to the reader to take what the authors write and see if/how it applies in their specific contexts.

[Andrew Stellman]

That is a fantastic question!! Thanks for asking it!

Jenny and I worked REALLY hard to make Head First Agile as practical and real-world oriented as possible. Both of us spend most of our time working with real teams that build real software in real companies – yes, we write books and do training, but for the most part we're professional software developers – and we aimed this book at people just like the ones we work with every day. We've probably got a half-century of software project experience between us, and over the years we've both specialized in working with troubled teams trying to fix their development problems, and as you can imagine, we've seen a LOT of real-world problems. So we tried to frame all of the agile material in the book in terms of the most common problems that teams run into in the real world.

Here's an example. A lot of agile teams use burndown charts. They're easy to understand, and pretty straightforward. But it's not necessarily easy to see exactly why they're useful. So before we talk about them, we set up a problem: by this point, we've been following a team working on a video game, and they've been using Scrum to get past various problems. Things are going pretty well by this point, but they keep running into a problem – when they reach the end of a sprint, they often have stories they haven't finished. How do they get a handle on how well they're doing in meeting their sprint goals? That's a great time to use a burndown chart – and now instead of being some disconnected, sterile practice, you can see how a real team might use it. And since we based this example on real teams that we've worked on in the real world, we think it will ring true for a lot of readers.

[Junilu Lacar]

Allow me to play the Devil's Advocate about burndown charts.

I only found one paragraph in Chapter 4 about this. So let's say your team decides to start using burndown charts so that you can see how much work is left. Doesn't the team need to do more than just see how much work is left? How does seeing the backlog change the way they manage their backlog and the work left to be done? If they don't do something, isn't the burndown chart just going to make it more obvious (and perhaps disquieting) that they will still have stuff left undone at the end of the sprint? An even more detrimental consequence might be that with each day they get closer to the end of the sprint and see how much they still have left, the burndown chart might turn into another "soul crushing instrument" to get developers to put in extra hours to get the line down to 0 on time. That's an anti-pattern.

Would it benefit the reader to expand on that idea a bit more and explain what kind of actions you need to take when the burndown chart reveals a problem? (Because Agile doesn't fix your problems, it only reveals them, right?)  Something along the lines of when it looks like there still might be things left undone by the time you get to the end of the sprint, then you should get together with your product owner and talk about pulling some stories off of the sprint backlog and do some replanning maybe?