Dahlia Bock

I recently watched this video of Uncle Bob. He asks the hard question, why are we still talking about XP (or Scrum or Agile for that matter) after 10 years? There are many organizations that claim to practice Agile and claim to be experts on it but there is always something (or a few things) missing and they continuously run into problems like painful deployments, constant broken builds, features not making releases on time, miscommunication between stakeholders and developers, etc. Issues like these are common to software development teams but Agile is supposed to help solve some of them.

So what are we missing? What are we not doing right?

In a recent conversation with a colleague, I posed these three questions.

1. What have you experienced to be a project’s biggest pains?
   - lack of communication
   - broken software being deployed
   - dependency of 3rd party components in the build
   - long meetings to define and discuss stuff instead of just trying them out and seeing what happens
   - upfront analysis and having to redo it later
2. Do you think those teams of yours were practicing Agile right?
   No
3. Do you think that practicing Agile right would help with the pain points you have experienced?
   I think we should cut the the meetings and try the set based concurrent engineering approach of lean, i.e. more prototyping. We need more people to care about the quality of what we produce. We should analyze as we need to, not up front. That would make the project more fun for people, more like they are producing something worthwhile. Colocated teams would improve a lot of things.

What are the things we should be doing to make sure that we’re practicing Agile properly? My colleague, Liz Keogh, recently wrote a post entitled What does “Not Agile” look like? and exhorts us to examine if we’re actually doing Agile justice. I think we’ve arrived to a point where we have talked about Agile enough and should actually be doing it right.

In Uncle Bob’s video, he points out a few things, and I paraphrase:

XP did not set out to conquer the business world, it set out to make it easier for a small team of programmers to do a good job. So what got left behind? The technical aspect of Agile. Scrum focuses on features, we have to go through the backlog, feature after feature, banging it all out, architecture and design doesn’t get attention. XP however is all about architecture and design. We improve on them iteration after iteration.

Who here has been significantly impeded by bad code? So why did you write it?

The only way you can get done on time is to refuse the mess. You want to go fast? Don’t rush. Seeming fast is not being fast. We are often seduced by the seeming fast. Refactoring is the act of changing the structure of a piece of code without changing its functionality. It shouldn’t be something we put on the schedule, we should be constantly doing it.

In this other video, Robin Dymond talks about how Lean helps to take Agile to the ‘next level’ and why organizations that fail to change will not have successful Agile teams. He also believes that organizations will need to reorganize around teams to get the most our of Agile.

Just hot off the press, my colleague Mark’s views on Lean and organizing teams for better efficiency.

I think that Agile is about weeding out the practices that don’t work and replacing them with ones that do. It’s all about embracing change and working towards a perfect software development environment, however far-fetched that might be. I think we should still try.