Danube - Comments

I shall be recommending this

strange facts — Sun, 14 Jun 2009 12:45:00 -0500

I shall be recommending this article to all future clients... and possibly getting in touch with a few I have worked with already.

Fragile Agile Adoption

Mark Stringer — Tue, 09 Jun 2009 09:34:15 -0500

I think the problem is even worse than you think. It isn't only that lots of people will adopt Agile in a piece-meal way. Even if at some point, while you're there as a consultant, everything is done correctly, when you go away again, things tend to drift.

There's been a lot of talk about how/why it is that even when people can see for their own eyes what companies like Toyota are doing, they can't do it themselves. I wrote a white paper about this a while ago. Toyota have a culture of continuously inculcating their culture with lean ideas, and a culture it seems of continuously improving *that* process, that's what seems to be missing in many applications of these ideas in other organisations.

Soft Skills

stevemcgee99 — Sun, 03 May 2009 14:42:30 -0500

It does seem that Scrum makes more room for individual strengths to contribute than typical 'command and control' management. And, to allow individuals to work in their own way, negotiate amongst themselves, encourage and monitor each other, 'soft skills' will be essential.

The 'theory of mind' concept is a great way to explain the need for some kind of model to frame behavior and provide a suggested response. Like any 'teaching tool', behavioral models seem most effective after they are mastered. I compare this to people learning tennis - only a beginner thinks about how they are holding the racket. Masters use the techniques but apply their other experience and skill to perform well. So, in learning old models like the MBTI or newer ones like EQ or MindOS, the best performance comes once the model is so familiar it is forgotten.

As far as 'open heart' being 'fluffy', I'd say it's 'fuzzy' as in fuzzy logic. There is research and theory behind this topic, however. It has to do with 'psychological boundaries', which can be adjusted by skilled people in ways that not only make themselves more effective, but others around them, too. A great manager uses her or his boundaries very effectively.

I think one of the points of resistance to adopting Agile practices is in the increased need for the team and organization to use their soft skills. Traditional organizations assume people are all the same and interchangeable (think Microsoft 'people icons' in ppt). Predictability comes from an assumption that human 'resources' can do what they are expected to according to plan. Paradoxically, by allowing space for individuals to manage themselves, within the framework provided by a vision, success is often more likely and sustainable.

Thanks Sean!

KatiePlayfair — Fri, 01 May 2009 19:48:03 -0500

Sometimes I believe that the CST process, in particular, is not well understood in the larger business community. Yes, you can get your CSM after a two-day course, but that's simply a requirement to enter the larger Scrum community certification process.

I know my CSP application for the intermediate certification took me one plane ride to Salt Lake and another to Toronto to author, reflecting on the previous two years of experience doing Scrum and acting in the Product Owner role. Of course, that application is nothing compared to what CST's go through.

So although a CST can not guarantee the success of your Scrum transformation, it is at least a good designation by which to choose a pool of coaches and trainers for further evaluation. Next of course you have to look at their clients, company they represent (if any), personal approach, cultural fit with your organization, etc.

Thanks Bryan!

KatiePlayfair — Fri, 01 May 2009 19:38:06 -0500

Allowing failure was one of the hardest concepts for me to internalize (Ok it still is sometimes). Especially when you've been the hero in past projects, to train yourself to let go, not rush into save the day at the expense of yourself and everyone else's learning, and accept that the consequences of failure are probably not life-or-death, at least not on the little things, is such a challenge.

Much like Scrum, learning to allow failure, learning and improvement to happen is a gradual process. Start small. Rome wasn't built in a day, right? :)

Nice Post!

Bryan — Fri, 01 May 2009 10:54:48 -0500

I really liked your list. So often people want a quick fix, but are not willing to make fundamental changes, are not willing to trust people, are not illing to "invite failure" and don't have the patience for real change.

Bravo for pointing this out!
-- Bryan

Watch for MUDAS

PP — Thu, 30 Apr 2009 16:43:07 -0500

Few more things Scrum Master should do/learn is

1. Watch for Waste (Mudas) and see how those can be eliminated on a regular basis

2. After Sprint Retro, you collect "List if things to improve". Keep this list in front of you so that you review them constantly and use them in all meetings.

Not necessary that the SM

PP — Thu, 30 Apr 2009 12:12:42 -0500

Not necessary that the SM need to do development ((s)he can, if willing to), may be they can participate in doing research & paving the path for the team. What matters is "Is (s)he contributing that brings value". Just b'cos that person is NOT writing a code that does not mean that person is not good. My SM was extremely Technical, but gave all opportunity to us, to explore our potential, but always helped us to ensure we did not miss our goal. He was more like a Coach/Mentor who has GREAD Technical/Business lead, who understood Business & Technology.

good article on splitting stories from Lasse Koskela

MichaelJames — Tue, 28 Apr 2009 23:01:15 -0500

http://radio.javaranch.com/lasse/2008/06/13/1213375107328.html

--mj

Good Explanation of Scrum Hierarchy

Sean Blanton, Ph.D. — Mon, 27 Apr 2009 10:38:53 -0500

Nice explanation of the steps on the Scrum ladder.

Additional costs of overtime

Ed Tellman — Thu, 16 Apr 2009 11:55:58 -0500

I agree with your sentiment that programmers have lives also, and shouldn't be compelled to work overtime.

Another way of looking at it from the customer's perspective might be that deciding to work overtime is making a tradeoff on the quality-cost-scope triangle. When people work long hours, it is unlikely that they will be as effective as they are when working normal hours. Things that improve quality like documentation, peer reviews, pair programming, automated tests, etc., are the first things that are likely to be abandoned when time is short and stress is high. A team that is working long hours probably isn't actually meeting its commitment to deliver a high quality product which includes all of the planned features. It may be able to give the illusion of having met the commitment by demonstrating something working at the end of the sprint. But the customer may discover to his dismay later that the code delivered is poorly designed and documented and difficult to maintain because of the stressful conditions under which it was written.

To put a few somewhat arbitrarily selected numbers on it, suppose a developer on the team costs $4000/week for a 40 hour week ($100$/hr * 40hrs). If he works 50 hours, the quality of the work done in each hour declines. The week's work will cost 25% more: 50hrs * 100$/hr = $5000. But the developer may be 20% less effective, since he is starting to omit documentation, tests, desirable but not-strictly-required refactorings, etc. So the work is is delivering as actually only worth $80 per hour. In a week, he is still actually delivering: 50hrs * $80/hr = $4000 worth of value. And as he gets more tired and works long hours for many days in a row, his effectiveness is likely to decline further until eventually he is introducing nearly as many bugs as features. As the overtime increases, the cost goes up but the value of the code delivered remains flat or declines.

A customer who says he doesn't want the team to work overtime may be making a conscious choice on the quality-cost-scope triangle. He is saying that he wants rested developers who work effectively and deliver high quality code, and is willing to sacrifice scope if necessary. The contractor, on the other hand, is implicitly saying he is willing to sacrifice quality and cost, by working overtime, in order to keep the scope fixed.

When a team realizes it is unlikely to meet its commitments mid-sprint, it may want to bring this up with the product owner. The product owner may want to reduce scope instead of having the team work overtime to deliver the planned scope at higher cost and lower quality.

good PO on team. Bad PO, stay away.

james peckham — Mon, 06 Apr 2009 23:34:08 -0500

This may be something to thing about.

What if your PO is abusive or not very scrum-like (you're in a bottom up and struggling against the PO because they're more hindrance than help)

You know... things like: taking over scrum meetings, not showing up to planning meetings, blaming the team for quality problems, not prioritizing stories, trying to squeeze scope...

new fav

LaszloSzalvay — Fri, 27 Mar 2009 11:11:28 -0500

I think this is one of my new favorite posts -

Good article

Robert Crawford — Thu, 26 Mar 2009 12:17:21 -0500

It's great to get a concise but broad brief of Toyota's famous processes.

Identifying the need for change

DadaMungo — Thu, 26 Mar 2009 08:44:18 -0500

Hi, Tobias!

As you mentioned Finland, and we met in a Product Owner training course that you gave here in Espoo last year, I couldn't help but comment on your thought about Britain needing to "upgrade" for winter weather. (Yes, I'm a British ex-pat).

We met when there wasn't any snow on the ground, which means it was sometime between April and October. And there's the difference: in Britain, the cost of winter-proofing is prohibitive when the duration for which such weather has to be endured is considered - a week or two at worst. It's simply not worth investing in the required infrastructure. In Finland, the country would be off-line for half the year.

As a creative person with a perfectionist streak, I am often eager to fix everything because it simply can be fixed, so I empathise with your sentiment. But money talks, and all that. Of course, this is getting a little off-topic, but one common weakness I have observed in the application of Scrum hereabouts is the focus almost exclusively on the Scrum Team, without giving much thought about the Product Owner and the quality of the backlog items, especially providing reasonable and real-world value assessments. We can be as Scrum as we like, but the Garbage-In-Garbage-Out mantra still applies. But, to get back to winter-proofing Britain, I'd give: benefit = 1, penalty = 1, SP = Epic....it'll just never make it to the top of the list, and that's just fine! Put another woolly jumper on and bring a good book or two! ;D

As for your thoughts on PowerPoint, I too have been inclined to think that less is more. The simple rule I have come to adapt is that whatever slideware I use is there to support me, and not vice versa. Having a slide in the background with just a word or two on it to remind us where we are gives us the framework that some people need, without wrestling the control of the discussion from the presenter.

Of course, this thinking is seconded by the agile manifesto itself, wherein we regard interaction with individuals more than processes and tools.