tag:blogger.com,1999:blog-55945382023-11-15T09:35:23.398-05:00coachspoton coaching software development teams, being a Dad, and the art of change.timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.comBlogger147125tag:blogger.com,1999:blog-5594538.post-249764750414150782009-05-23T07:41:00.000-04:002009-05-24T17:24:08.590-04:00Goodbye England, hello Canada!<p>I've recently moved with my family to Ottawa, Canada. There were a slew of reasons for doing so but the principal ones were the amount of travel I was doing for work - which took me away from my home and family too often - and the fact as an independent consultant I saw lots of "beginnings" - helping teams to start down the road to Agility - but felt I was missing out on the bigger picture: I want to go back "inside an organisation" and coach teams and individuals over a longer period than a consulting gig allows.</p><br />It was a slog getting everything packed up before we left - although we allowed plenty of time for it, the work definitely seemed to expand to fill the hours available - and after we arrived I couldn't remember precisely which items had come with us on the plane rather than being packed into boxes to follow by sea. So I wasn't quite sure what to expect when I opened the work-related folder I had packed into my suitcase. This is what I found: one copy of Kent Beck's <a href="http://www.wordle.net/gallery/What_is_XP">XP Explained (2nd edition)</a>; one printout of Martin Fowler's article <a href="http://www.martinfowler.com/articles/newMethodology.html">The New Methodology</a> dated December 2000; printouts of Alistair Cockburn's articles <a href="http://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development">Characterizing people as non-linear, first-order components in software development</a> and <a href="http://alistair.cockburn.us/Software+development+as+a+cooperative+game">Software development as a cooperative game</a> dated March 2001; my most recent notebook; a few index cards; and a small packet of coloured "sticky dots".<br />Which made me think about why I had selected these particular things (ignoring the notebook and index cards which get stuffed into a bag to go with me pretty much everywhere), especially since I probably packed them "on autopilot". Well, Kent's book is pretty much a no-brainer: it's small, the XP values and principles resonate deeply with me and I frequently find myself dipping into it. The article printouts were probably selected on the basis of their dates (although they remain a good read): they have sentimental value from back when I started applying an Agile approach to my own projects, and remind me of the wonderful people I got to meet in London through the Extreme Tuesday club and Thoughtworks. Which leaves the "sticky dots": I think I must have thrown them in as props to represent the kind of facilitative role I enjoy taking as a coach and which I've learned so much about through the retrospectives community.<br />Here's hoping that I find the kind of work I'm looking for!timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com2tag:blogger.com,1999:blog-5594538.post-64693491714245675322007-07-16T03:13:00.001-04:002009-04-03T11:01:33.840-04:00Our most important projectI've had a couple of experiences with introducing Agile on "our most important project", and they've been both a fascinating mix of a genuine desire to run the project differently (to avoid past problems) and the fear of introducing risks by changing the status quo. As Tom De Marco says in a lovely line in <a href="http://www.dorsethouse.com/books/pw.html">Peopleware</a>: <em>People don't like change. I'll say that again - people don't like change.</em>.<br />So what to do?<br />First let's take a moment to put ourselves in the project team's shoes, and appreciate how profoundly scary it can be to work on a high-profile project, with all the weight of expectation and oversight it entails. Because on top of all the existing pressure on people we're adding the burden of learning to do things in a different way (which may be overwhelming), and removing the comforting thought that "it's ok, we've done this before". On what basis can we be confident that this is the right team, the right project, and the right time to introduce change? <br />Second let's stop and think about ourselves a little. Do we have the support inside (and outside) the organisation that we need? Are we in the right state of mind to cope with actual or potential failure, and any nay-sayers who might try to shoot us down or the ideas we espouse? (An early "thanks, but no thanks" to the engagement may save a lot of pain later on...) <br />Assuming we believe that everyone is prepared for the challenge then I'd argue that the final thing to do is to seek out and connect with the positive drivers for change that already exist. Approaches such as Appreciative Inquiry should allow us to envision this project's future (Agile) success and tie it together with those past times when things have gone well. But if we can't, then perhaps that is the strongest possible signal that "our most important project" should be run in the same way as usual.timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-63527776227567097782007-05-14T07:15:00.004-04:002009-04-02T16:10:37.148-04:00Communication, communication, communicationI believe that software development is for the most part a social activity. This implies that in many circumstances the most valuable work that a coach can do is to improve the quality of <em>interactions</em> between people in a team (especially when the <em>individuals</em> that the team will be made up of is not a variable that can be influenced.) <br />So I often find myself reflecting on the quality, frequency and modes of communication that I observe: trying to understand why a particular phrase is used or stance is taken. (Which also involves wondering about the things that are not explicitly discussed as well as the things that are.) And quite often in teams that are struggling there seems to be a lot of miscommunication that only serves to perpetuate the problems that the team is struggling with. <br /><a href="http://www.bkconnection.com/ProdDetails.asp?ID=9781576754559">Barry Oshry's work</a> on the way that people <em>make up stories</em> to explain what they don't understand - reframing other's motivations or intent to place them within their own perspective - has been exceptionally helpful for me in making sense of such situations, and the application of Virgina Satir's <a href="http://www.chacocanyon.com/essays/orgpatterns.shtml">coping model in organisations</a> has also provided useful insights. <br />Sometimes however there seems to be a repetitive cycle of miscommunication between particular individuals whose dynamic seems to fit more with the ideas of <a href="http://www.ericberne.com/Games_People_Play.htm">Games People Play</a> and the roles of <em><a href="http://www.ta-tutor.com/!dratri/xdrallp.htm">Persecutor, Rescuer and Victim</a></em> in the <a href="http://en.wikipedia.org/wiki/Karpman_drama_triangle">Karpman Drama Triangle</a>. While it helps to have some awareness of what might be going on in these circumstances, I find such situations quite stressful. It is tempting (for my ego!) to try and play the part of "the hero" who can "save" the team, but I recognise that by doing so I would leave people stuck in the same disempowered situation as they were before I joined them. Which is not what I believe an Agile coach should do.timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-14468823571385696892007-04-30T10:54:00.000-04:002009-04-02T11:11:47.486-04:00Learning from experienceAs a long-time advocate of retrospectives, one of the most rewarding parts of the teacher training course was seeing the idea of "learning from experience" in a different context. A large part of the art of teaching is actually about encouraging learning: moving beyond the transmission of knowledge and practical skills so that pupils develop their own <em>"metacognitive ability"</em>, identifying the ways in which they learn and reflecting on their own thought processes in the light of experience. (Happily trainee teachers are also expected to do the same and become <em><a href="http://www.infed.org/thinkers/et-schon.htm#_The_reflective_practitioner">Reflective Practitioners</a></em> through a mixture of self-evaluation and mentoring). <br /><a href="http://www.campaign-for-learning.org.uk/cfl/learninginschools/l2l/index.asp">Learning to Learn</a> seems to be a fairly hot topic in educational research, and in my reading around it I often found successful learners described in terms such as <em>"resilient"</em>, <em>"resourceful"</em>, and <em>"reflective"</em> (definitely attributes I have seen in the most successful software teams, and the individuals within them). It was extremely rewarding as well to read <a href="http://www.papert.org/">Papert's</a> book <em>"The Children's Machine"</em>, whose emphasis on how we learn through exploration – reaching conclusions about abstract concepts through progressive, concrete experience – resonated with so much of the debate in software circles about emergent design. <br />Back in the business world, people like <a href="http://www.solonline.org/aboutsol/who/Senge/">Senge</a> have been popularising the idea of <em>learning organisations</em> for a long time. So why do software teams, even Agile ones, often see (or gain) so little value from retrospectives? Are the retrospectives not being done "right"? Do teams see the retrospective event as the only time to reflect so that they miss the learning opportunities that crop up more frequently? Or are there so many limits to what people are "allowed" to question and change within their organisation that they simply give up on the whole idea of trying to learn and improve...?timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-6856108581506484032007-03-09T09:51:00.001-05:002009-04-02T10:52:49.740-04:00Arriving back at the beginning...As <a href="http://www.tristan.icom43.net/quartets/gidding.html">T.S. Eliot wrote</a>:<br /><em>the end of all our exploring<br />Will be to arrive where we started<br />And know the place for the first time.</em><br /><br />I'm back at the code-face again: working as an Agile Coach with software teams. It's an interesting experience: I feel that my time away has helped me see the challenges and pressures of project delivery more clearly (such as tight schedules without clear priorities, restrictive budgetary rules that confuse “cost” with “value”, and management / reporting structures that reinforce divisions between groups instead of opening up communication and collaboration between the individuals that need to work together to achieve the desired results.) Perhaps as an outsider – a consultant – I have a privileged viewpoint, though I don't really buy that argument. People within the teams I work with often describe the problems they have in terms of the complex, systemic interactions within their organisation: problems that require more than a simple “fix” to one activity (or even, shudder, one person) in isolation.timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com3tag:blogger.com,1999:blog-5594538.post-86375036394850661032006-08-12T12:45:00.001-04:002008-12-09T09:51:07.348-05:00Moving on, moving out<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger2/7594/682/1600/timHeadshot.jpg"><img width="100" style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;" src="http://photos1.blogger.com/blogger2/7594/682/320/timHeadshot.jpg" border="0" alt="" /></a>After 14 years working as a software developer and with software development teams I've decided to try something completely different: I'm now training as a <a href="http://www.standards.dfes.gov.uk/secondary/keystage3/subjects/ict/">secondary school ICT teacher</a> in the UK (ages 11-18) and I won't be posting here any more...timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1120638440019869352005-07-06T04:24:00.000-04:002005-07-06T04:27:20.020-04:00Why might you think otherwise?<em>Having to work harder and act like 'robots', with little scope for personal initiative, are the chief reasons for declining job satisfaction in Britain</em>, <a href="http://www.jobserve.com/e2757.news">according to a new study</a>.<br />Feelings of insecurity, too high expectations and people being 'over-educated' and unable to find work to match their qualifications, are largely dismissed, in the study led by Professor Francis Green of the University of Kent. His team found no evidence to back suggestions that the dull mood of workers may be due to successive generations having ever higher expectations from their jobs and being disappointed by the realities of employment.<br />Tim Osborn-Jones at <a href="http://www.jobserve.com/e2759.news">Henley Management College said</a>: “Employee commitment is known to be important but complex. Staff that 'want' to stay are likely to go the extra mile to achieve an exceptional outcome. Staff driven more by a 'need' to stay (lack of alternatives), or sense of 'ought' to stay, may be less concerned with outcomes. <br /><em>"Henley's own research also suggests that, even in today's downsized, de-layered organisational world, most talented individuals want an employment relationship based on trust, social exchange, and will engage when given the opportunity to achieve self-fulfilment, a sense of accomplishment and fun and enjoyment at work."</em>timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1120638263791380242005-07-06T04:20:00.000-04:002005-07-06T04:24:25.806-04:00RetronymsA <a href="http://www.worldwidewords.org/weirdwords/ww-ret1.htm"><em>retronym</em></a> is a word invented in the present to describe something that needed no definition in the past. (For example the "acoustic guitar" is a retronym that was only needed after the electric guitar was invented.) What retronyms might there be for the <a href="http://www.sdmagazine.com/documents/s=826/sdm0208j/">Fragile software processes</a> that previously had no name:<ul><li>Blame oriented software engineering?</li><li>Just too late software production?</li><li>Document driven design?</li><li>Test last and hope development?</li></ul> (With thanks to Conan Dalton for starting this discussion at XP2005...)timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1120552273248977412005-07-05T04:26:00.000-04:002005-07-10T05:47:39.010-04:00Announcing "Experiences": an e-zine for software practitionersStory-telling is a long-established human activity with a rich and diverse history. Today the <a href="http://www.storytellingcenter.net/resources/articles/simmons.htm">power of story-telling</a> is applied in software development teams through retrospectives, appreciative inquiry, narrative therapy, and cynefin techniques, as well as around the water cooler. Stories help us to understand, question, and inform the way we practice our craft. (Think for example of the way that the story of the C3 project was woven in to the early XP movement.)<br />It struck me a while ago that the only stories that software practitioners tend to share in print are 'headline' stories: bigger, bolder and more in-your-face than many of us might relate to. Where are the everyday stories of 'aha' moments, hopes and disappointments, and tales from the code face? There are plenty of these in blogs – one of the reasons why the blogging medium is so popular, I think – but no collections publishing a variety of voices in one place. <br />Or at least there were no such collections until Joel Spolsky put together <a href="http://www.joelonsoftware.com/articles/BestSoftwareWriting.html"><em>Best Software Writing</em></a>. <br />There are plenty more interesting and informative stories not in that book, and the number of those unheard stories increases every day. So I wondered to myself, why not seek out more stories and make them available electronically? Which is what I intend to do: this is the official announcement of the launch of the grass roots e-zine <em>Experiences</em>, that will collect stories from software practitioners and share them in the community. <br />My vision is that this e-zine becomes a collaborative endeavour, "published" three to four times a year, with varying editors, themes and contributors. For the first edition I'm looking for descriptions around 500 words long of events that actually happened to you, with or without an explicit commentary or lessons learnt section. Preference will be given to European contributors providing original (unpublished) material covered by a <a href="http://creativecommons.org/">Creative Commons</a> license. The target audience is software practitioners and consultants working in Europe, but stories don't have to be limited to the realm of software development. If you'd like to contribute or have any questions or observations then <a href="http://tinyurl.com/8qphx">I'd love to hear from you</a>! Here's hoping for a great launch issue in August...timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119820170239902422005-06-24T15:59:00.000-04:002005-06-26T17:11:18.350-04:00Wrapping up with Kent at XP2005The end of the conference featured Kent Beck, twice. First he joined a panel discussion on Leadership (summarised <a href="http://stevef.truemesh.com/archives/000516.html">here</a> by Steve Freeman, and from which I took away the strong conclusion that leadership starts with holding one's own congruent stance in the face of resistance and then pulls others in to acting congruently as well). Then he had the stage to himself for the keynote speech, entitled <em>Another notch</em>. It addressed in a wide-ranging way the possibilities opened up by embedding the values of XP in an organisation's culture and philosophy, a theme that seemed to be bubbling under many of the sessions in the conference.<br />Initially Kent pursued the idea that XP is bigger than mere practices, that "technical success is not success", and that all the best TDD and refactoring and continuous integration in the world won't matter if a project fails to meet the needs and timetables of its sponsors and users. "Typing in a line of code has consequences" he said, and those consequences are part of a larger world-view that needs to be embraced if XP is to move up another notch. Is programming really the best focus of all of our energy? Perhaps the application of the technical processes described in the first edition of the white XP book has moved project constraints away from programming to a different aspect of the development process? (The theory of constraints shows that micro-optimisation of one step in a complex process can in fact degrade the throughput of the process as a whole.) There might be a lot of other non-programming tasks that can be done right now to eliminate the constraints in the wider team, department or organisation: "it's a fiction to believe that if I get all my tests green then the project's ok and I've done my part" as he put it. <br />The next part of the speech was a request for the XP community to take accountability - "rendering an account of your actions to others" - more seriously. Accountability is a synonym for fault in blame-ridden organisations, but this is not its real meaning. To hold myself accountable is to be proud, honest and open about what I do, to live the values I espouse. To "overcome the disconnect between the satisfaction I get from programming and the dissatisfaction I get from life". To understand that I can't really change my organisation, and I can really change myself. To cope with the realisation that enacting the transition to XP requires respect for the starting point, and is "more than saying everything will work out if everyone does as I say". (At which point Kent started praising the approach taken by <a href="http://coachspot.blogspot.com/2005_06_01_coachspot_archive.html#111964785382738828">Appreciative Inquiry</a>, which was nice...)<br />He wrapped up by sketching out his vision for what will happen as XP is taken up another notch. People and projects will be truly accountable and have nothing to hide. Teams and individuals will express their XP values in all their actions and interactions. The confidence to hold onto ones self in the face of pressure will engender trust, creativity and learning. And as a happy side effect software projects will get delivered quickly and at high levels of quality too.<br />I'll sign up to that.timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119815348909601102005-06-23T15:27:00.000-04:002005-06-26T15:59:04.646-04:00The Drawing CarouselI heard good reports about this workshop when it was run at the 2004 XPDays and I wasn't disappointed at XP2005. <a href="http://www.tryx.com/">Vera Peeters</a> used the analogy of a <a href="http://www.pst.informatik.uni-muenchen.de/~baumeist/xp2005/index277.html">group collaborating on a drawing</a> to guide 8-person teams through an exploration of what pair programming is about. From the perspective of someone who has experienced pair programming teams already I think that I mostly had fun (!), observed some <a href="http://www.infed.org/thinkers/tuckman.htm"><em>forming, storming, and norming</em></a> close up, and got a better idea of the perils of ignoring what you know to be "right" (e.g. integrating early and often, reflecting on and adjusting your process) just because the customer starts with a different perspective to your own.timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119794925111973892005-06-22T15:52:00.000-04:002005-06-26T10:08:48.603-04:00Workshops that I co-facilitated at XP2005On Tuesday I co-facilitated two workshops, exploring <em>Informative workspaces</em> with <a href="http://www.twelve71.org/blogs/rachel/">Rachel Davies</a> in the morning, and <em>Teamwork and team working</em> with <a href="http://redsquirrel.com/cgi-bin/dave">Dave Hoover</a> in the afternoon. <br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/3854/201/1600/PHTO0013.jpg"><img style="float:left; margin:10px 10px 10px 0;cursor:pointer; cursor:hand;" src="http://photos1.blogger.com/blogger/3854/201/320/PHTO0013.jpg" border="0" alt="Themes in informative workspaces" /></a> The morning session was well attended and generated a number of anecdotes about <a href="http://www.agilexp.com/workspace-gallery.php">the elements of an informative workspace</a>, from which some themes emerged (see <a href="http://photos1.blogger.com/blogger/3854/201/320/PHTO0013.jpg">photo on left</a>). Sadly, the subgroups that explored a few of these themes expressed concern about how others in the organisation might misinterpret or misrepresent an informative workspace. Perhaps this is a recognition that, <a href="http://www-128.ibm.com/developerworks/java/library/j-beck/">as Kent Beck said</a>, <em>if your organization punishes honest communications and you start to communicate honestly, you'll be destroyed</em>. (The workshop also uncovered other - more uplifting! - aspects of informative workspaces that I hope will be summarised more formally in the future.) Thank you Rachel for inviting me to join your session - it was great to be a part of it.<br />The afternoon session was less well attended, which surprised me as "people and teams" seemed to be a fairly popular topic of conversation in the bar. (Note to self: more flagrant self-promotion next time!) The workshop content and approach altered a fair amount between the time of the submission process and my arrival in Sheffield, reflecting my own recent professional wanderings via <a href="http://coachspot.blogspot.com/2004_11_01_coachspot_archive.html#109992594712765677">AYE</a>, much <a href="http://coachspot.blogspot.com/2004_12_01_coachspot_archive.html#110432646714330759">introspection</a> and some meditation, a very <a href="http://coachspot.blogspot.com/2005_05_01_coachspot_archive.html#111683692327332799">challenging coaching engagement</a>, and an exploration of the social constructionism themes underlying both <a href="http://cbae.nmsu.edu/~dboje/narrativetherapy.html">narrative therapy</a> and <a href="http://www.aradford.co.uk/Pagefiles/background.htm">appreciative inquiry</a>. The end result was a workshop focussed mainly on the ways that team dynamics can be understood through the thought processes of the team members themselves. (If you're interested then the <a href="http://www.primeeight.co.uk/XP2005.WhenTeamworkIsntWorking.Handouts.pdf">handouts from the workshop are available online</a>.) Thanks to those who expressed some interest in what was discussed after the workshop, and I hope that attending helps you in your work teams.<br />All in all it was a busy day, and I was glad that I had prepared for it by making the time for a refreshing early morning run along the nearby <a href="http://www.beenthere-donethat.org.uk/burbageedge.html">gritstone edge at Burbage</a>. If you attended either of the sessions and have some feedback on your experience, then I'd love to hear it.timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119780693662531962005-06-21T17:11:00.000-04:002005-06-26T07:47:08.260-04:00Agility - Coming of Age<a href="http://www.jeckstein.com/">Jutta Eckstein</a> gave one of the invited talks at XP2005, reflecting on the change in her consulting experiences as Agile software development reaches out <a href="http://en.wikipedia.org/wiki/Crossing_the_Chasm">across the chasm</a> to the <a href="http://www.quickmba.com/marketing/product/diffusion/">early majority</a>. She said that she is no longer coming in midway through "projects in crisis" (for whom an Agile approach is "a last hope") but is instead being invited in to the earliest stages of projects that have enthusiastically chosen to start with an Agile software development process. (She noted that the official German government methodology has changed to incorporate some Agile ideas, such as mandatory continuous customer involvement throughout the life of a project.) Jutta described some of the challenges of being a consultant involved in these different kinds of projects (e.g. how much experience / research did the customer have when deciding to use Agile? what are the Agile solutions appropriate to very large distributed teams, or those creating hardware as well as software?) and she stated that overcoming these is preferable to the ill health she suffered through her involvement with past unhealthy and suffering projects. <br />I can relate to that myself: I've seen good Agile consultants burn out on "rescue missions" that provided props for an organisational system whose actions created the need for a rescue in the first place. And Jutta addressed this topic of the organisational system directly, asking: <strong><em>is it possible to run a sustainable Agile project within an organisation whose values, expressed in words and deeds, are not aligned with the Agile manifesto?</em></strong> And I agree with her: using Agile is about more than applying a set of practices - the actual practices in use can (and should?) differ from one Agile project to another - it is about working within a value system. <br />Jutta finished with two provocative comments. Firstly she said that <a href="http://redsquirrel.com/cgi-bin/dave/2005/06/20#xp.2005.tuesday">Agile isn't "trendy" anymore</a>, so if you're looking for the cutting edge and the next big thing then now is the time to move on and find it. Then she finished by saying that any team not holding retrospectives isn't doing XP (yay! more retrospectives!! spontaneous applause from Diana Larsen!!!). All in all it was a stimulating talk, and it prompted a lot of conversation in the bar afterwards...timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119776855004106812005-06-21T17:04:00.000-04:002005-06-26T07:46:49.583-04:00My son has chicken poxAnd I'm at XP2005, unable to comfort him or offer support to my wife. The conference and all its attractions somehow seem less relevant right now, and my thoughts are elsewhere. Get well soon Lucien...timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119776628012546472005-06-21T16:32:00.000-04:002005-06-26T07:46:22.173-04:00XP2005 - the Toyota way<a href="http://www.nayima.be/">Pascal Van Cauwenberghe</a> and <a href="http://www.xs4all.nl/~mmmevers/blog/">Marc Evers</a> ran an interesting workshop based around the ideas in the book <a href="http://www.amazon.co.uk/exec/obidos/ASIN/0071392319/"><em>The Toyota Way</em></a> (Author Jeffrey Liker, <a href="http://isbn.nu/0071392319/">ISBN 0071392319</a>*). The attraction of studying Toyota is that the company's success in the mature car industry points to a tried and tested <a href="http://lean.org/">lean</a> approach that evidently scales up well, has lessons to teach other industries such as software, and that can easily be brought up in conversations with <strike>"men in ties"</strike> executives. <br />What I got most out of the workshop was an appreciation of how deeply long-term thinking is embedded in the Toyota culture, and a feeling for the very rich interrelationships between the <a href="http://www.si.umich.edu/ICOS/Liker04.pdf">14 principles</a> (much like the interrelationships between <em>barriers, attractors and probes</em> described in the <a href="http://www.cynefin.net/">Cynefin approach</a>). <br />Among the group the topic that probably generated the most discussion was the idea of a company's long-term philosophy: does your company have one, do people know what it is, and is it visible in the company's actions and intentions?<br />* <a href="http://poppendieck.com/">Tom Poppendieck</a> also recommended the book <a href="http://www.amazon.co.uk/exec/obidos/ASIN/1892538091/"><em>Product Development for the Lean Enterprise</em></a> to people who wanted to understand more how the lessons of Toyota might apply to the software industry.timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119272207007277342005-06-20T08:45:00.000-04:002005-06-26T04:32:35.040-04:00Must control raging fist of death (he says)<a href="http://blog.alancfrancis.com">Alan Francis</a> was in prime ranting form at the bar here at XP2005 last night. He raged variously about <strike>baseball</strike> cricket, mock objects, people who use words without defining them, the differences between v1 and v2 of the white XP book, and several other things besides. He meant it all in a nice way of course, and it mostly amused <a href="http://www.objectmentor.com/aboutUs/bios/Michael%20Feathers">Michael Feathers</a>, <a href="http://redsquirrel.com/cgi-bin/dave">Dave Hoover</a>, <a href="http://www.livejournal.com/users/sirenian/">Liz Keogh</a>, <a href="http://www.exoftware.com/PressRelease32.htm">Brian Swan</a>, and I. We miss working with you Alan: take care of yourself and your family, 'k?<br /><strong>PS:</strong> <a href="http://blog.alancfrancis.com/2005/06/the_raging_fist.html">apparently</a> it was me ranting about "practical" Agile (and what is "impractical" Agile anyway?!) It seems I need to control my own raging fist of death too ;-)timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119201091899896602005-06-19T13:11:00.000-04:002005-06-23T13:10:45.803-04:00"The Industrial Wilderness"noun: where students go to find paid programming jobs after they graduate from university (as defined by Werner Wild at XP2005)timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119201002203185802005-06-19T13:08:00.000-04:002005-06-26T15:49:26.530-04:00An inspirational coachOne man who certainly has courage and does communicate is Mike Hill (formerly at Anarchy Creek Software and now <a href="http://www.industriallogic.com/company/coaches/">working at Industrial Logic Inc.</a>) I overheard him speaking to his tutorial group while <a href="http://www.pst.informatik.uni-muenchen.de/~baumeist/xp2005/index24.html">they sat on the lawn</a>, and I really valued what he had to say and how he said it:<ul><li>XP is a set of values and practices designed to create an effective software development community</li><li>some programmers are still at the magical incantation stage of programming: they need effective teaching in their craft</li><li>I used to believe that some programmers really were dead wood but now I believe that the wood isn't dead, just waiting for spring to come</li></ul> That last phrase is especially evocative, and I can really imagine Mike bringing spring – light, life and growth – to the teams that he coaches.timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119200882716586632005-06-19T13:05:00.000-04:002005-06-24T16:52:21.543-04:00The courage to communicateDiana Larsen's <a href="http://www.xp2005.org/tutorials#T09">tutorial</a> at XP2005 focussed on three important aspects of teamwork that are often overlooked: listening, decision making, and personal feedback. People can be dismissive of the need to pay attention to these areas, but there is real value to be gained here:<ul><li>people who feel listened to are more likely to think creatively and are more likely to become fully involved in a team's activities and goals</li><li>finding occasions to use decision making mechanisms other than concensus (which is the default mechanism for many teams) saves time and effort</li><li>seeking and giving personal feedback influences personal behaviour and therefore directly affects a team's effectiveness</li></ul>timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119197634025572042005-06-19T12:07:00.000-04:002005-06-23T13:07:56.520-04:00Expressing Business RulesI arrived at <a href="http://www.xp2005.org/">XP2005</a> yesterday to take advantage of the tutorial track that takes place before the "proper" conference gets under way, and I'm glad I did. Rick Mugridge's tutorial on <em>Expressing business rules with story tests</em> was well worth getting out of bed for early on a Saturday morning. As well as covering the basics - what is a business rule? what is a story test? what is <a href="http://fit.c2.com/">Fit</a>? why use <a href="http://www.cs.auckland.ac.nz/~rick/FitLibrary">FitLibrary</a>? - Rick also passed on some observations on his experience of using story tests in Agile software development:<ul><li>Story tests are as much a communication mechanism as a test mechanism</li><li>It takes both <em>analysis</em> (formalising the business rules for the system) and <em>synthesis</em> (considering the impact on the business of the system) to create good story tests</li><li>The language used in story tests (close to <a href="http://domaindrivendesign.org">Eric Evans'</a> idea of a ubiquitous language) needs to be open to change, e.g. when understanding or business circumstances change</li><li>Copy and paste between story tests is the sign of a missed abstraction</li><li>Treat tests in the same way as you would code: pay attention to naming tests and refactoring them</li><li><a href="http://www.xp123.com/xplor/xp0503/index.shtml">Procedural story tests</a> can often be expressed more clearly and succinctly as a set of declarative tests</li><li>Testing a system through the UI is not the same as testing the UI or testing the system</li></ul>timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119197256190627572005-06-19T12:01:00.000-04:002005-06-24T16:55:18.880-04:00Three Human Imperatives / UniversalsDavid Cooperrider, the founder of Appreciative Inquiry, identifies these <a href="http://www.thinbook.com/name/E_Human_needs.html">three basic needs</a>:<ul><li>To have a voice and be heard</li><li>To be viewed as essential to the group</li><li>To be seen as unique and exceptional</li></ul>I believe that Agile software teams create an environment where these needs are more likely to be met. What do you think?timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1119647853827388282005-06-17T16:51:00.000-04:002005-06-24T17:31:00.880-04:00Appreciative Inquiry course, day threeThe first two days of <a href="http://coachspot.blogspot.com/2005_06_01_coachspot_archive.html#111835877373330960">the AI course I'm attending</a> were a <a href="http://en.wikipedia.org/wiki/Appreciative_Inquiry">whistle-stop tour through the field</a> using a mixture of practice and theory. This third day was different, much more of an examination of the values of AI and how they can be applied in everyday work situations to reframe "deficit-oriented" questions within this "strength-oriented" approach. (The theory behind why these reframings are so effective is <a href="http://www.psy.dmu.ac.uk/michael/soc_con_disc.htm">social constructionism</a>, which stresses that "we see what we describe rather than describing what we see".)<br />In one exercise we tried to write a pithy explanation of exactly what AI is. We came up with these words (my editing): <br /><em>Appreciative Inquiry is a process and philosophy for personal and organisational growth, underpinned by research in the fields of social and behavioural psychology. It allows us to understand more about what we do by asking about how things are when they go well, and what might be possible if we did more of those things, more often. What's special about AI is the way <br />it connects respectfully with peoples' hopes and dreams to unleash a positive and creative energy for change.</em>timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1118577204627452282005-06-12T07:22:00.000-04:002005-06-12T07:53:25.876-04:00Some provocative propositions for software development teamsI recently spent some time determining "provocative propositions" about software development teams as part of the <a href="http://coachspot.blogspot.com/2005_06_01_coachspot_archive.html#111835877373330960">Appreciative Inquiry course</a> that I am attending. These statements reflect the best aspects of all the teams I have experienced, described as if they are happening here and now. <ul><li>We celebrate what we create</li><li>We congratulate ourselves and each other</li><li>We work together</li><li>We know we can find solutions to our puzzles</li><li>We have fun</li><li>We taste the fruit of our labour</li><li>Our team has a shared heart</li><li>People want to use our great computer systems</li><li>Our great computer systems provide real benefit</li><li>We look forward to doing more of this work tomorrow</li></ul> Just writing that down feels very inspirational to me - how does it feel to read it?timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1118358773733309602005-06-09T18:07:00.000-04:002005-06-09T19:12:53.753-04:00Appreciating and InquiringAs I write this I'm sitting outside in the sunshine on the <a href="http://www.southbanklondon.com/map/map.asp">south bank of the Thames</a>. It's not one of my usual haunts, and this isn't one of my usual days: today I'm attending the first of five one-day workshops on Appreciative Inquiry run by <a href="http://www.aradford.co.uk/">Anne Radford</a>. The course was recommended to me by Diana Larsen and the subject is one that I'm becoming increasingly interested in. I first learnt about AI at the <a href="http://coachspot.blogspot.com/2005_06_01_coachspot_archive.html#111835255506488874">retrospectives gathering</a> in February, and I experienced the positive power of AI interviews in <a href="http://coachspot.blogspot.com/2005_06_01_coachspot_archive.html#111835805109880329">Boston last month</a>, so I'm excited to learn more about this technique and how it might be applied effectively with software development teams. Watch this space!timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0tag:blogger.com,1999:blog-5594538.post-1118098461165999772005-06-06T17:52:00.000-04:002005-06-06T18:55:44.160-04:00Excuse me while I feel about that for a momentDave Hoover is creating and collating <a href="http://redsquirrel.com/cgi-bin/dave/2005/06/04#public.patterns">Apprenticeship Patterns</a> for software development. I don't want to discount the material gathered so far, it's just that I feel that something is missing. The current set of patterns seem to emphasise developing abstract and logical thought over developing an ability to work collaboratively with people. This doesn't fit with my experience that most of the problems with software projects are in fact <a href="http://www.acs.org.au/nsw/articles/1999073.htm">people problems and not software problems</a>. (How many "masters" would point that out to their "apprentices" I wonder?) <br />At the <a href="http://www.ayeconference.com/">AYE conference</a> <a href="http://coachspot.blogspot.com/2004_11_01_coachspot_archive.html#110113524320467083">last year</a>, Dave and I found that we shared the same <a href="http://keirsey.com/personality/nf.html">NF temperament</a>, one that is quite different to the <a href="http://keirsey.com/personality/nt.html">NT temperament</a> more common in software developers. On the basis of this common ground I therefore proposed a "feeling" apprenticeship pattern, which I hope will find its way into the "thinking"-dominated pattern language that Dave is creating...<br /><strong>Feel your feelings:</strong> <em>Building software is a creative and therefore emotional act, especially when you're working together with other people. You will feel uncertainty, pressure, disappointment, relief, joy, and a host of other emotions. But when these feelings are stirred what do you do with them? If you try to hide them do they really stay hidden, or do they come out in other ways, e.g. rising to anger or goofing around? Staying aware of your feelings, becoming aware of other people's feelings, and learning to work with emotions instead of ignoring them, will amplify the effectiveness of any skills you learn.</em> <br />(I also wrote this a slightly different way. <em>Discover yourself while you learn your craft: the journey you take as an apprentice is as much about yourself as is it is about building software. If you have the courage to discover the person behind the personality - what drives your behaviour, how it is perceived by others, and why that might be - then you will amplify the effectiveness of any skills you learn</em>).timbaconhttp://www.blogger.com/profile/01876156948492933493noreply@blogger.com0