Ask Mary Poppendieck Anything!

What about the issue of aligning IT with business processes – especially processes that need to change continuously with improvements? As the head of Motomachi said to the IT guy (in The Toyota Way, by Jeff Liker), “Come back when you have a system that helps us make cars.” As Peter has pointed out, Toyota hasn’t exactly solved that problem themselves, but what’s the ideal state and how do we get there? How does the IT culture go from “But I gave you what you asked for” to let’s really understand what is needed here in its simplest, most usable form”?

When I bring up Visual Management to my groups at the G***le, people scoff at me, saying that index cards, white boards, and like approaches are very 80’s and not fancy enough.

How do I overcome this resistance and help people understand that it is great processes that allow for innovation and the creation of the best products — not technology? How do I help others understand the value of humility and that we are fallible and can actually learn from the #1 car company (#1 company in my book) in the world?

There’s too much hubris where I work.

Many Agile methods suggest a division of responsibility between the Customer and development team. The Customer is responsible for understanding and prioritizing the business needs and the dev team is responsible for estimating and implementing solutions.

This business/technology division of labor seems simple, visible and I can understand the daily responsibilities of each side.

The downside to this is (paraphrasing you from the leandevelopment list) a we/they divide leading to local optimizations.

An alternate structure is the “Chief Engineer” who is responsible for the total business success of a product and leading the engineering as well.

My question: How does the division and delegation of responsibility differ when a Chief Engineer is responsible for the business success?

A Chief Engineer must have broad business and technical experience , but this person can’t be responsible for everything, all the time.

The best guess I can think of is to characterize the two styles into:
* Vertical Style: business/technical sides with a communication contract.
* Horizontal Style: A central figure that uses set-based design to constrain the next levels of work.

Interested in your experience and thoughts,
John

I have been following a new Agile methodology called Hyper, developed by Damon Poole, CTO, Accurev. What do you know about it?

Thank you,
Mark

Can there be “Agile Performance Testing”?
Is there a business case for it?
Are there experiences out there as to how to go about it?
What does it really mean for performance testing to be Agile?

I work at a company that runs a classifieds web site and currently has inherited a lot of waterfall culture from our parent company. Moving to something leaner, this is the first time for me that I’m involved with a small (30 developers) shop that a) runs *lots* of small projects in the order of 20-30 dev days and b) does so spread out over three development sites (2 in the Netherlands, 1 in the Ukraine). Scrum probably will provide the framework for our journey.

What is the one thing to get right in these circumstances? (yeah, simplistic question, but this is a Q&A session and not a consulting gig, I guess )

The term “Lean” is very little known in the software development and system delivery industries. Do you expect there to be more explicit use of it in the future?

It seems IS people are treading their own path towards quality management and capability maturity without reference to other industries.Perhaps if Lean were a more well-known term in IS, we could benefit from several decades of experience and from training in lean principles.

Making a broad generalisation, it seems lean initiatives in many industries need top-management support to have a chance of success. In contrast, there are many accounts of agile programming techniques being adopted at team level with good results.

At what level of organisations do you recommend lean software development be introduced?

Imagine an organistion with high-level sponsorship and a generous budget to make software development lean… Should change begin with education or practice; in the development team or the boardroom; slow or fast; a pilot project or ‘for real’; imposed by decree or encouraged by incentives?

Weekly Agile Reading. Pack 5

Manually filtered top of the most interesting writing published since last Saturday. Of course, most interesting from my personal point of view.

# Agile Implementation
# Ask Mary Poppendieck Anything
# Getting Off Our Tails and Onto the Rails
…

Working with Agile / Scrum methodology is new to me and the struggles of the old mind mapping are at the base of this question. The goal of the burndown chart is of particular interest because in my mind it shows the scope and a total estimate. The programming manager, I am working with and learning from, indicates that only the iteration is estimated and the totoal is only known at that end. Can you give me some insights on how this works for management and planning out into the future for resources and the next project? Thank you.

Where can I go to find documented proof that Agile has improved the bottom line for a company? I am working as a team lead in a web development company, and my superiors all want growth and improvement, but have their eyes to the ground so hard they can’t see any ways to improve other than their own ideas (I’m sure this is a familiar situation). I want to make changes and improvements, but my suggestions are often replied with something to the effect of ‘don’t rock the boat’. I know implementing such paradigms must come from the top down to be effective, and the only thing that will capture the attention of the top is a dollar figure. So again, where can I go for documentation on bottom line profits for a company after incorporating Agile?

What about goals and their metrics and measures? Is Gilb the only management theorist concerned with such?

What do Lean and Agile offer for methods for choosing what to do next?

The Toyota Production System seems far more comprehensive than Lean and Agile put together. Can we sensibly ignore the parts not covered by Lean and Agile?

Shouldn’t we read Ohno before we need to say, “Oh NO!”?

Lean would seem to allow for a broader set of ideas and practices than some Agile adherents would find acceptable. For example, SEI Team Software Process seems closer to Lean both in spirit and in pedigree than much of the Agile body of practice, yet many Agilists regard Watts Humphrey as a villain.

Has Agile become the new orthodoxy? How does Agile add value to Lean? Will the prejudices of the Agile community limit the progress of Lean ideas within software development? When do we get to drop the Lean/Agile qualifier and just be Lean?

I have a few questions about supplier relationships.

I read in the “Toyota Way” that dual sources almost every part which in used in manufacturing their cars. Once something goes wrong in the supply chain, the company that made the mistake will only lose a part of their business, say 5% and that part moves to the other supplier. Also I read that Toyota uses their own quality engineers to improve quality in the suppliers plants. I am a relative newby in both IT and as well as outsourcing, but I am curious on how would you design lean supplier relationships in software development? What are good examples have you seen?

[...] a Q&A session with Lean Software Development luminary Mary Poppendieck. Post your questions here and possibly have them [...]