Quoting Jaz Singh <[address removed]>:
> I guess I have to put in my thoughts!
Now that you've mentioned the E-word, so must I (again)!
> We had some really good training and agile coaching from The Dude: (David
Name noted. Twin Cities?
That reminds me. Besides training, someone who can coach you as you
"do Agile" might be even more important. Local is good unless you have
deep pockets to cover travel, especially since the teachable moments
don't happen all at once, or on a schedule.
> Our team, like many teams, started trying Agile by trying Scrum. As we
> progressed as a team, I observed that Scrum is really quite prescriptive.
> In some sense, these processes tend to be illogical, and potentially
Shu-Ha-Ri is a common metaphor among Agile trainers.
The prescriptive part is there on purpose. "Do it exactly like this to start."
When that's working (3-4 cycles), start making changes, under control
via well-facilitated retrospectives--read your Derby & Larsen!
Eventually, you'll just be "doing."
> I won't go into this much, but clearly there are issues, such as the
> expectation that software developers can estimate.
Ah, the E-word!
The Estimation Problem is why we went Agile 10 years ago. At least
Agile faces it head on. Plus, Agile lets you put the uncertainty in
the scope where it belongs.
It's still a problem. I'm developing some public Estimation training
as we speak.
> I have even heard of the term "Scrum ceremonies." If ever there was a term
> that is antithetical to the agile manifesto, that would be it!
> From what I have seen, a good agile team will naturally drop the
> absurdities, in favor of a more natural iterative process.
> I'd recommend reading up on Kanban models, which tend to be more natural
> for the development lifecycle, and fits better with the development process
> as a whole.
> Kanban tends to handle changes a fair bit more reasonably, and is not so
David Anderson's book is good. The software world is newer to Kanban,
so maybe it's working well because the Innovators and Early Adopters
have it. They can make anything work! Kanban does handle constraints
and external dependencies well, though. I helped with it one place
(software & hardware dev) and have heard of one other place in Madison
where they run it.
> A good team will adopt practices that work for the team, and discard those
> that don't.
> Above all, iterate and adjust your processes to keep the team efficient and
I've also seen them fall into their own ruts. That's another situation
where an outside person can be helpful--jiggle them out of the local
minimum they've fallen into.
Robert Merrill, Principal
"Software Shouldn't be Scary"