Does anyone utilize Lego Serious Play?

[Rob Henson]

I know LSP is around in the Agile world and has been introduced and discussed during Gatherings and user groups, I'm curious about 2 things. 

1) Has used it with a client if so, what was the result? 

2) Do you really need to use the silly LSP starter kits and other kits or is that really just marketing to get you to pay more? 

I have more questions, but that will do for now.

Thanks,

Rob

[Yves Hanoulle]

You might have more answers in the agile games google group.


Scrambled by my Yphone

Op 23-okt.-2012 om 19:21 heeft Rob Henson <rob.h...@gmail.com> het
volgende geschreven:

> I know LSP is around in the Agile world and has been introduced and discussed during Gatherings and user groups, I'm curious about 2 things.
>
> 1) Has used it with a client if so, what was the result?
>

Yes and we had great results.
You can see here te result of how we used it at xpdays Benelux

http://www.youtube.com/watch?v=uzeQiFRIvPw&feature=youtube_gdata_player

> 2) Do you really need to use the silly LSP starter kits and other kits or is that really just marketing to get you to pay more?
>

I have done both.

I have a leadership game that I have done with own Lego
And we have done the lsp exercises

They are nicely done and they guide people to ply again with lego.
I would advise to play once LSP with a college coach and see for yourself...

[Mark Levison]

On Tue, Oct 23, 2012 at 1:01 PM, Rob Henson <rob.h...@gmail.com> wrote:

I know LSP is around in the Agile world and has been introduced and discussed during Gatherings and user groups, I'm curious about 2 things. 

1) Has used it with a client if so, what was the result? 

I've participated, but never facilitated. Its a good tool for helping people to start thinking, about understanding a seeing problems. 

2) Do you really need to use the silly LSP starter kits and other kits or is that really just marketing to get you to pay more? 

There are specialized parts, if you wanted I'm sure you cobble something together off the shelf.

Cheers

Mark 

[Todd Charron]

Hi all,

Anyone have any thoughts, opinions, or experience with Dean Leffingwell's Scaled Agile Framework?

http://scaledagileframework.com/

Thanks.

[Tim Ottinger]

I've been in two companies who base their work system on it.

[Mark Levison]

On Tue, Oct 23, 2012 at 2:55 PM, Tim Ottinger <tott...@gmail.com> wrote:

I've been in two companies who base their work system on it.

Which begs the question how was it working in the contexts you saw it?

Cheers

Mark 

[Tim Ottinger]

short answer: It's hard to say.

Slightly longer answer: 'release train' tends to be abused as a
metaphor for "department" and that blurs the lines. They had multiple
release trains for groups doing the same product and the same release
train for people working on different assets with different release
dates and goals.

It's change and inertia. I think I have seen both examples moving
toward a more agile way of working, but getting there slowly by first
bolting it on to their existing org chart, then making only those
changes made necessary by various dysfunctions, and making them only
when they became widely troubling or expensive.

We need tee shirts with the motto "The Task is the reason for the Team."

By the nature of my work, though, I am involved in transition. I see
orgs in their first few years of adoption, not when they're mature and
troubles are ironed out. Rather than judge them by a point measurement
(are they 'really doing it') I have to look at them on a trend line
(are they approaching or withdrawing). Transition coaches have to
silently repeat to themselves "every road out of Rome is also a road
into Rome." So when we see things are not quite what we'd like, we
have to ask if they're trending from or toward the goal.

I think both orgs were tending toward a decent goal, and along the way
fighting the system's immune system tooth and nail.


But also, there are so few real attempts at scaling agile to large
organizations (a problem most choose not to solve) that I have little
to compare it to. It's so much easier to be agile with one product or
a couple of teams with a common pulse. Who does a great job of running
20 or 30 or 50 teams and staying true to the values, to whom we can
compare Leffingwell's deciples?

--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------
http://www.industriallogic.com/
http://agileinaflash.com/
http://agileotter.blogspot.com/

[Todd Charron]

Thanks for the detailed response Tim!

[Jason Shao]

Curious if people have thoughts at where the boundary for something like
SAF are - vs. organic/informal management of multiple teams.

20 people? 50? 200? - and # of products in a portfolio & business unit
arrangement. e.g. I'm not sure we need a framework aggressive as SAF (40
devs/testers ~ 4.5 distinct products) but pieces of the model definitely
appeal to me in terms of holistically managing the cross-team workload.

Jason

[Dan Neumann]

Yes. I am familiar with it. Is there a particular perspective you're looking for? That question is very broad.

Dan Neumann

574-514-3285

[Hans Samios]

I've been involved in two organizations where some of the concepts help, especially as a source of ideas on improving. I have to say that for large products (many teams / one product) the concepts defined are ones that you will probably evolve to over time.

To provide context, the two organizations are mid-sized software development shops (say 400-500 development people), in 8 countries around the world, dealing with products that are millions of lines in size that have been produced over many years (20, 30 years in some cases) with all kinds of technology basis (yes, I still have Fortran code that is part of an active product in one case). We've found that the place where Leffingwell applies is for products that have 10 or more Scrum teams working on them. Concepts such as the "release train" help people understand the first steps they can take to get to "done" after every Sprint even for large legacy products. It provides a framework for this discussion so that even if they don't do it exactly by the book, there is significant progress made. The PSI idea has helped us reduce the risk associated with big product deliveries and also helps us increase the level of automated testing (because everyone has to do QA type work in hardening sprints, and developers find themselves doing lots of manual tests which they hate doing, they naturally work to automate that work).

Other concepts such as the layering / terminology of epcis / features / stories is something that we have not found the need for. We've taken the approach of limiting the size of epics for initiative / portfolio planning so that we don't build up an inventory of "big initiatives" that clog the system. This naturally means that epics are more plan-able in the normal sense.

Still other concepts such as the product owner team (Product Management team) and the release team, is something we evolved to before seeing Leffingwells work and we have seen that work reasonable well. 

And the use of scarce, common people such as UX and architects has involved more creative solutions to 1) allow the person to focus 2) allow the delivery of value. We have found that there is no "one approach fits all" for these situations.

Hope this helps.

Hans Samios

Scrum Master / Agile Coach 

Intergraph Corporation

[Tim Ottinger]

I love that you consider 500 midsized.

I think the majority of shops worldwide are closer to 20 than 200 a company with 50 teams of ten each is quite large.