Comments for Scaling Software Agility

Comment on Resources by New Whitepaper: A User Story Primer « Scaling Software Agility

New Whitepaper: A User Story Primer « Scaling Software Agility — Fri, 06 Nov 2009 15:12:33 +0000

[...] Resources [...]

Comment on Role of the Product Manager by Pivotal Product Management Blog | Product Owner/Product Manager: Can You be Both?

Thu, 05 Nov 2009 17:44:20 +0000

[...] http://scalingsoftwareagility.wordpress.com/2008/02/28/role-of-the-product-manager/ [...]

Comment on Announcing an Upcoming Book on Agile Requirements by Scale in London – Part II « The Agile Executive

Scale in London – Part II « The Agile Executive — Fri, 30 Oct 2009 12:21:25 +0000

[...] Moreover, Dean is actually ‘binding’ together his insightful blog posts to publish a new book entitled Agile Requirements: Lean Requirements Practices for Teams, Programs and the [...]

Comment on Is Scrum Lean? by Ryan martens

Ryan martens — Sun, 25 Oct 2009 14:30:16 +0000

Dean, Great detailed answer to the question! Thanks for sharing. You increased my convictions on this by 2X

Comment on Organizing at Scale: Feature Teams vs. Component Teams – Part 1 by Luca Minudel

Luca Minudel — Sat, 24 Oct 2009 09:24:55 +0000

thank you for your feedback

found it very interesting

Comment on Organizing at Scale: Feature Teams vs. Component Teams – Part 2 by Markku

Markku — Fri, 23 Oct 2009 21:30:03 +0000

Well, I think in all models the answer comes from Lean thinking: what ever produces most value and least waste. In SW development, dependencies (between people, process, time etc.) are culprits for three main wastes(out of 7): handoffs, delays and context switching. If you analyze the dependencies in your organization and product structures, you should be able to find the best fit solution. In my company it currently seems to be a model where client SW is developed in feature teams separately from backend (feature teams) and service deliveries. But the whole picture is yours, create, refine and finetune your own model by just keeping the Lean and systems thinking in mind.

Comment on Organizing at Scale: Feature Teams vs. Component Teams – Part 1 by Markku Kutvonen

Markku Kutvonen — Fri, 23 Oct 2009 21:15:15 +0000

>
> broader skills and product knowledge,

It is a real point but actually not a huge problem. It naturally depends on the teams, but if you have build the teams correctly, they all have some variety of domain knowledge but more important, enough seniority and problem solving skills that it will not be an obstacle. A real life experience in my unit, after one year in feature teams, 5 teams are working pretty comfortably on quite a large domain set, one of them in maintenance shifts, delivering solutions to customer problems.

Comment on Resource: Agile Process Self-Assessment Survey by Dean Leffingwell

Dean Leffingwell — Tue, 20 Oct 2009 17:26:08 +0000

No fixed rule, but perhaps every 90 days or so. Maybe 6 months even.

To do a really thorough job, I’ve seen teams take from 1-3 hours to do it. Longer the first time, because they’ll likely discuss many aspects of agility as they likely hadn’t yet considered!

Comment on Resource: Agile Process Self-Assessment Survey by D. Hughett

D. Hughett — Fri, 16 Oct 2009 18:43:40 +0000

How often do you recommend teams go through this sort of assessment?

Comment on Are Scrum and XP Lean? (Part 1) by Dean Leffingwell

Dean Leffingwell — Fri, 09 Oct 2009 22:55:34 +0000

Hi Mark,
I agree on the hype cycle comments. Lean is far enough past hype to be proven, and people generally understand that 1) it is hard, and 2) you can never be too lean. Sometimes agile teams “get it” somewhat and then get sloppy about kaizen. I suspect lean organizations do to, but it’s a little more obvious since its a pillar, not just a retrospective.

I agree that it’s a continuum, especially with respect to Srum which has its roots in lean and the New, New Product Development Game. It’s both true and a convenience for us involved in big transformations. When line managers come to understand their key role in “leaning” the software enteprise, they also understand the context for scrum – and more importantly, their direct responsibility to help improve it.

In that context, they are a pig, not a chicken.

–Dean