> 2010/f/22 Tim Ottinger > > How about the idea that a scrum master is just a manager? > > What differences can you see between a scrum master and a manager ? In mission and relationship to the team. Tim Ottinger http://agileinaflash.blogspot.com/ http://agileotter.blogspot.com/
Hi Jeff, Jeff Morgan wrote: > I think what Toyota did here is not a lean failure at all. I agree. It's a PR failure. The frustration from customers isn't that the faulty part came out. Or that Toyota didn't know what it was. It was that Toyota acted differently and seemed to withhold information and not be open and honest about what was going on. To the general consumer, stopping the line is meaningless when you can't put your kids in your car because you are afraid it won't stop. Especially when you've just paid $30 or $40k for said car. And double-especially when the dealer can't give you any timeline as to what they can do, what they are doing, or what will be done. I'd wager that had Toyota came out and said, "We've had reports of a problem. We are doing step a and b and halting sales until we figure this out. For people who have an affected vehicle, we sincerely apologize and promise to not only make it right, but make sure it doesn't happy again", and then went on to meet that obligation and perhaps a small gift on top of it - free oil changes, or whatever, that people would have been a whole lot less upset. We own Toyota vehicles, and what hurt me wasn't the part. It was their response. And that's a failure we can all learn from. -- --(Continue reading)
On Sun, 31 Jan 2010 09:58:31 -0800, you wrote: >I'm not an expert on fallacies, but I'm sure a rhetoric professor could use >the press surrounding this incident and the comments from the lean >proponents and detractors as an exercise in rooting them out. >For example, non sequitur: > >Toyota is a lean manufacturer >Toyota allowed a defective part to reach the customer >Lean doesn't work or Toyota is/was successful Toyota has a Lean production system Lean equals success Michael
The reactions here sofar find no fault with Lean; either Toyota forgot about Lean, or the whole incident and especially its handling is an example of Lean. When agile projects fail, you often hear it wasn't really agile, or not agile enough. Is there a blindspot here, are agile and Lean always beyond doubt? What evidence would there need to be for a team to say Lean or agile doesn't work for us? Michael
I think the problem is that success is rare, mysterious (having no reliable recipe), and probably multicausal. Failure is not the result of wrongdoing necessarily, but is the natural state. Most businesses fail, most fail before becoming well-known, and many fail after being fabulously successful. We forget that failure is the default, and success is the outlier that needs explaining. Indeed, all our work in any field of endeavor is not really competing against others so much as competing against the default. As such, it is hard to consider any process to be necessarily "the" cause for any success or any failure. Waterfall has well-known failure modes due to increasing cost of change v. increasing irrelevance of requirements & design. Agile combats that.American-style manufacturing and pre-lean Asian style manufacturing has known failure modes that are addressed by Lean. So when we use XP and/or Lean methods, we should fail differently. Nonetheless, failure unrelentingly stalks us all. That we have as many successes as we have is astounding, but cannot be necessarily attributed merely to lean or agile methods, nor merely to leadership, nor merely to craftsmanship. Tim Ottinger http://agileinaflash.blogspot.com/ http://agileotter.blogspot.com/
> What evidence would there need to be for a team to say Lean or agile > doesn't work for us? I would say this is not a good question. Perfection does not exist and absolutes are not conducive to good results. A better question might be: Is there a better methodology? Victor =========================== ----- Original Message ----- From: "Michael KENNY" <kenny <at> acm.org> To: <extremeprogramming <at> yahoogroups.com> Sent: Monday, February 01, 2010 8:42 AM Subject: Re: [XP] Lean failure at Toyota > The reactions here sofar find no fault with Lean; either Toyota forgot > about Lean, or the whole incident and especially its handling is an > example of Lean. > > When agile projects fail, you often hear it wasn't really agile, or > not agile enough. > > Is there a blindspot here, are agile and Lean always beyond doubt? > > What evidence would there need to be for a team to say Lean or agile > doesn't work for us? >(Continue reading)
Hello, Victor. On Monday, February 1, 2010, at 9:08:31 AM, you wrote: > A better question might be: Is there a better methodology? When you say "better methodology", what do you mean? For that matter, when you say "better question", what do you mean? Ron Jeffries www.XProgramming.com www.xprogramming.com/blog Sorry about your cow ... I didn't know she was sacred.
> When agile projects fail, you often hear it wasn't really agile, or > not agile enough. Sure. If it had a failure mode that agile methods should prevent, then it probably wasn't agile enough. If it was in a way that an agile method does not address then it isn't a failure of Agile, but from some other cause. > > Is there a blindspot here, are agile and Lean always beyond doubt? There is always room for something better, if we can find something better. Before agile, we all tried different ways, and changed when agile methods came along. Expect the same for whatever is next, but not when people resurrect the old waterfall ways as an "improvement" over agile, because we've been there. > What evidence would there need to be for a team to say Lean or agile > doesn't work for us? That they cannot implement agile in their context after giving it a fair shot and using competent coaches. If you can't implement it, it doesn't work for you. Otherwise, we need to find failure modes that consistently arise because of the use of agile methods. Are certain failures in certain contexts agile-caused? We don't know that they are. So far, we see those that are not agile-prevented -- and failure is multi- causal.(Continue reading)
On Mon, Feb 1, 2010 at 7:42 AM, Michael KENNY <kenny <at> acm.org> wrote: > What evidence would there need to be for a team to say Lean or agile > doesn't work for us? What evidence would say they do? IMO, its the wrong question. The issue for those of us who think a lot about software process and how to be successful at delivering software, and so forth is more fundamental. Tim's got the right idea: Success is rare. More specifically, success is a number between 0 and 100 and for most endeavors just being slightly above the norm will result in huge gains. Kent's been blogging a good bit about poker and how its shaping his thinking. I've been playing poker very actively this past year as well, and one thing its taught me is that binary notions of win/lose, pass/fail, success/fail are fine in chess, math and other precise activities (like coding) where complete information is possible (in a narrow context) but most activities live in contexts that require a probabilistic definition of success and so a strategy that increases one's chances to a positive expectation is successful, improvement is looking for ways to improve a point or two and no strategy will get you to 100% or even close, the vast majority won't get to 50%. We keep making the mistake that a methodology (a practice, a value, a language, a book, a tool, etc) is going to provide, or be the basis for, or an element of a formula that makes success a certainty, and so when we see a failure it must be because the item in question was misused or abandoned. Lean isn't a formula for success any more than Agile was; both might help improve EV by some number of points (at best) assuming the other factors in a given context don't dwarf their(Continue reading)
Hello Ron, 2010/1/31 Ron Jeffries <ronjeffries <at> acm.org> > >> > What differences can you see between a scrum master and a manager ? > >> > >> Planning, Organizing, Staffing, Directing, Controlling -- Drucker > > > I do agree that these activities are management activities, not > > project activities. > > > However, I can't see why these management activities couldn't be > > handled by self-organized employees, so that managers' behaviours > > wouldn't be different from scrum masters' ones : teaching, coaching > > and facilitating. > > Well, I'm not sure all of what is under those activities could be > done by the team. Neither do I, but this perspective fascinates me, so I am digging... > I am quite sure that in the next decade at least, > they will NOT be delegated to teams as a matter of course. How are you so sure ? > And finally, if a person didn't do any of those functions Drucker > lists, instead doing the things you list, we should probably call > them "teacher" or "coach", not "manager".(Continue reading)
RSS Feed3 | |
|---|---|
8 | |
51 | |
70 | |
10 | |
68 | |
216 | |
15 | |
19 | |
18 | |
277 | |
64 | |
62 | |
274 | |
295 | |
220 | |
76 | |
145 | |
13 | |
9 | |
48 | |
13 | |
31 | |
20 | |
65 | |
34 | |
15 | |
59 | |
181 | |
38 | |
57 | |
271 | |
180 | |
719 | |
346 | |
374 | |
306 | |
228 | |
303 | |
372 | |
352 | |
252 | |
131 | |
137 | |
385 | |
308 | |
343 | |
256 | |
194 | |
234 | |
857 | |
433 | |
1030 | |
950 | |
627 | |
790 | |
198 | |
490 | |
1112 | |
623 | |
430 | |
855 | |
439 | |
1211 | |
1939 | |
775 | |
475 | |
1000 | |
716 | |
570 | |
1011 | |
1152 | |
2902 | |
1590 | |
1527 | |
792 | |
650 | |
577 | |
391 | |
358 | |
739 | |
666 | |
569 | |
834 | |
873 | |
940 | |
709 | |
813 | |
842 | |
586 | |
665 | |
937 | |
1486 | |
1642 | |
2030 | |
924 | |
714 | |
1292 | |
1254 | |
943 | |
1111 | |
1710 | |
1374 | |
1629 | |
1394 | |
1256 | |
945 | |
912 | |
1265 | |
833 | |
1097 | |
1017 | |
1100 | |
1421 | |
1728 | |
2925 | |
2229 | |
1592 | |
1763 | |
1354 | |
1342 | |
1559 | |
1347 | |
1083 | |
1023 | |
1423 | |
1260 | |
1891 | |
2132 | |
2957 | |
2621 | |
2185 | |
2632 | |
2285 | |
3125 | |
1460 | |
2 | |
1 | |
2 |
