add-memberalign-toparrow-leftarrow-rightbellblockcalendarcamerachatchevron-leftchevron-rightchevron-small-downchevron-upcircle-with-crosscomposecrossfacebookflagfolderglobegoogleimagesinstagramkeylocation-pinmedalmoremuplabelShape 3 + Rectangle 1pagepersonpluspollsImported LayersImported LayersImported LayersshieldstartwitterwinbackClosewinbackCompletewinbackDiscountyahoo

Re: [softwaredev-113] Scrum master training

From: Robert M.
Sent on: Tuesday, December 17, 2013 8:21 PM
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
> Hussman)

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
> absurd.

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
> prescriptive.

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
> functional.

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
uFunctional LLC


"Software Shouldn't be Scary"

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy