InfoQ Homepage Presentations Punishment-Driven Development
Punishment-Driven Development
Summary
Louise Elliott discusses why people tend to blame and punish others, the impact of self-blame, the unintended results from punishment, and the alternatives to punishment, which get real results.
Bio
Louise Elliott has worked in the software world for over 25 years and has seen huge changes in both technology and how software development is managed. She has successfully introduced Agile and Lean to many companies and is a great believer in the benefits of self-organizing teams. She is passionate about quality and the need to build it in from the start.
About the conference
Agile Tour London is an annual conference which explores all aspects of agility and its adoption and implementation in a business environment. Packed with inspirational talks and hands-on workshops, Agile Tour London 2016 offers unmatched opportunities to learn from the best agile experts in the industry. Whether you are an agile newbie or been in the industry for years, this is the definitive agile conference you can't afford to miss.
Community comments
Very nice presentation
by Richard Richter,
Re: Very nice presentation
by Louise Elliott,
Very nice presentation
by Richard Richter,
Your message is awaiting moderation. Thank you for participating in the discussion.
I like the stories, I like the material for thinking. It is really hard to do things "egolessly" but it can help a lot. I'm more or less successful with egoless programming, less so with people though. :-) People always heat me up. It requires some set of mind, practice and maybe some of us are simply not able to do it. ;-)
Re: Very nice presentation
by Louise Elliott,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks Richard. I'm not a natural at this either - I continue to get things 'wrong' and go with my gut reaction - which rarely gives me the result I would like. The more I work on it though and recognise my mistakes the better I get. I like to think of it as using the same skills as when debugging code - something isn't happening in the way you would like and you need to use your analytical skills to work out why not, what the source of the problem is and how you might sort it out. You decide what your desired outcome is up front. You use your experience of having seen similar problems in the past to help guide you to possible answers. You experiment to find a solution which will work. You may talk to someone about the problem to see if they have had similar issues.
The skills are actually very similar - the key is in being willing to forego the immediate emotional satisfaction of reacting in order to get the longer term and larger reward. That's a matter of choice.