There’s been lots of chatter lately about whether Agile is Dead, or if Scrum is [better|worse] than Lean, and whether Lean can be used for Development teams, or if Scrum should be shot, and so on, and thus forth. Here’s my view, subject to correction:
- Agile is a mindset. It is actually agile, with a lowercase a. The manifesto was a marketing document. You can not judge whether someone, or some team, is agile using checklists.
- XP (Extreme Programming) is targeted towards improving the way we write software. If you are working with a software team, you can’t leave home without it. TDD, Pair Programming, Acceptance Tests, Onsite Customer – vital, vital things to a well-oiled software team
- Scrum is at a higher level. The practices can be applied to a software team, but can easily be applied to non-software as well. Its goal is increased communication and decreased risk by helping stabilize the efforts necessary to get to wherever we are trying to go. It’s one of the most likely reached-for agile practices, even though things like the Daily Stand-Up require teams to be past two of the 5 Dysfunctions of a Team to be even remotely effective. Scrum starts to be challenging as it scales without some true experts around – Scrum of Scrums, to me, just isn’t optimal (not that I have a better suggestion)
- Lean seems to be two things, although I know it isn’t. To me (and this is my view after all) the important things here are optimizing the whole, reducing waste, and value stream mapping. The thinking behind this is vital to getting the other practices working well. But Lean is really at home changing organizations and large teams. While things like Value Stream Mapping and Kanban are coming out of this, for people trying to understand agility in the context of their team, figuring out how to improve once you’ve gotten the data can be a little too abstract.
A lot of this also has to do with things like the Dreyfus Model of Skills Acquisition – beginners need to be told what to do – which is why Scrum works so well. 3 practices, we’ll teach them to you in a weekend, and you can get up and running with it. Scrummerfall is easy to do when you aren’t also combining the practices with continuous improvement models.
So what should you start with if you want to make a software team better? There are two ways I suggest:
- Jump in with both feet (or “Throw ’em in the deep end”) – Talk to the team about the XP practices. Agree as a team to give it a go for x amount of time and to reevaluate. Be sure to give enough time for people to become at least a little comfortable (I’d suggest 1-3 months, but YMMV). The key here is continuous reflection on what is working and what isn’t. During the trial period work to make the practices work instead of assuming it won’t work for your team. At the end, have a half to day long retrospective on what worked and why, and then decide as a team how to move forward
- Evaluate and Apply – In this case, you use tools like value stream maps to get a sense of the overall health of the organization and the team. You selectively apply practices to improve areas, remembering that the goal is to optimize the whole. This is actually much harder than option 1 as you have to work to continuously implement new practices. You also lose the “shock and awe” when coming in as a change agent – people expect changes early on, but may be anticipating them settling down.
So I find the whole arguments silly. If we’re optimizing software teams, then we look to software practices. If we aren’t, we don’t. If I use Value Stream Mapping during my Retrospective with my Onsite Customer right after our Product Demos, it’s all part of becoming agile. I may not be “doing” XP or “doing” Scrum or “doing” Lean – and from the people and leaders I’ve talked to, that’s perfectly fine. But I also have enough respect for their ideas that if I’m mixing and matching, and cutting and tweaking, that I not blame a process I’m not even following. Perhaps if more people would simply acknowledge they aren’t following the process, and instead talk about why they aren’t, we could make more progress as a whole.
Until then, we’ll keep seeing people spinning their wheels and being kicked out of groups and denouncing each other’s practices. When ‘craftsmanship over crap<‘ was suggested as the 5th manifesto point, we should have embraced it as a community not only from a software engineering side, but a communication side as well.
Happy Thanksgiving All. Gobble Gobble.