The Importance of Nurturing Community

September 1, 2010 in Agile, Agile 2010 by Mark Levison

Community According to Dictionary.com, a community is:

1. a social group of any size whose members reside in a specific locality, share government, and often have a common cultural and historical heritage.

2. a locality inhabited by such a group.

3. a social, religious, occupational, or other group sharing common characteristics or interests and perceived or perceiving itself as distinct in some respect from the larger society within which it exists (usually prec. by the ): the business community; the community of scholars.

The 3rd definition applies to the Agile Community. From my point of view a community is really the network of relationships between the people who are its members. The more relationships we have and the stronger the individual bonds the stronger the overall community will be.

After Agile2010 I made a suggested over twitter that the Agile Community is Fragile and needs nurturing. Unsurprisingly I got a number of reactions and created some confusion which wasn’t my intent. My key point was that as the community continues to grow and create new conferences: LSSC, XP Universe revived[1], SCNA, XP 2010 (ok this one has been around for a while), we’re at risk of breaking into camps and cliques. Groups of people who spend their time inside one community and who don’t spend enough time listening to each other and the outside world. This trend has been going on for years after all who aside from Ron Jeffries and George Dinwiddie have the time and energy to spend on every mailing list [2].

Towards my goal of strengthening the community I suggest we all commit three actions this year:

  1. Seek people from outside your regular circle i.e. if your non-technical meet some new technical people; Scrummies meet Kanbanners. Whoever you meet, pause, listen (don’t spout) and learn.
  2. Strengthen bonds with people you already know, especially outside of your regular circle
  3. When you introduce someone to Agile, introduce to more than the ideas and approaches you favor today. I.E. Kanban folk mention Scrum or XP; BDDer’s mention TDD – help new people discover the full spectrum of ideas.
  4. Through these connections have your ideas about at least one thing changed (cribbed from Brian Marick).

As our community grows ever bigger lets remember that have much in common even when there are major differences.

Related Ideas: A Community of Thinkers (Jean Tabaka, Liz Keogh and Eric Willeke) and Oath of Non-Allegiance (Alistair Cockburn).

[1] As an aside I still think that Agile Technical Practices would be a better name for this one, emphasizing the practices are important whichever methodology you subscribe to.

[2] see: Agile Mailing Lists for an attempt at listing them all

0 Comments

Read More

Speaking at Agile 2010

July 20, 2010 in Agile, Agile 2010 by Mark Levison

image Several people have asked if I’ve fallen off the face of the earth recently, well not quite. However along with being busy with client work I’ve been preparing my two Agile 2010 sessions with Roger Brown:

Wednesday, August 11, 1:30 – 3:00pm

Learning Best Approaches for your Brain

Do you mentor, coach, teach or just help other people? Do you wonder why, after what feels like your greatest teaching moments, some people still don’t get it? Neuroscience has started to provide us with insights into what happens in the learner’s brain when we’re teaching. Learning is really about building and reinforcing existing neural networks. Instead of providing a lot of new ideas out of the blue, we need to understand the learners existing context and work with that. Instead of focusing on mistakes and errors, we need to focus on what good solutions look, sound and feel like.

See the recent article on InfoQ: The Science of Learning: Best Approaches for Your Brain, for a taste of the session.  Since its after lunch again, please consider avoiding High Fructose Corn Syrup (i.e. most desserts in North America). See: Diet-induced insulin resistance impairs hippocampal synaptic plasticity and cognition in middle-aged rats.

    Thursday, August 12, 9:00 – 10:30am

    Continuous Creativity for Agile Teams

    Creativity can manifest in several ways including creation of something new, refinement of something that exists and problem solving. How do we support, enable and enhance the creative abilities of Agile teams? There are many ways to shape the work environment for greater creativity. We will present a summary of the literature that describes how creativity can be enhanced by providing a safe, nurturing environment, enhancing group interactions, pacing activities that utilize different sensory modes and trusting in the power of subconscious integration.

    I know this will be a tough morning after the Wednesday night parties (i.e. Rally, VersionOne and Cyrus Innovations), I promise this will be worth waking up for.

    0 Comments

    Read More

    Agile Quick Links #16

    July 19, 2010 in Agile, Links by Mark Levison

    Courtesy of a few hours delay from Ottawa to LaGuardia, I have some unexpected time to write a Quick Links.

    I’m always explaining to clients the problems with traditional Test Automation approaches. With Why Test Automation Costs Too Much Elisabeth Hendrickson explains why Test Last will always fail. Now she just leaves the job of explaining what to do instead.

    Derek Huether found an awesome Scrum Intro Video (by Hamid Shojaee, Founder and CEO of Axosoft) – its only 8 minutes long.

    Odopod is an online sketch pad, I’ve not spent enough time playing yet but it has support for animation. Might be a great tool for users of Dan Roam’s “Unfolding the Napkin” and Dave Gray’s  “Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers” (Caveat Emptor I only just discovered Dave’s book today and so haven’t read it yet).

    Hiring for a Collaborative Team from Esther Derby has a great set of ideas. I would only add one I recently hear from Pascal Van Cauwenberghe in an email to the agile games list where he describes introducing a potential hire to his company by playing the XP game with them.

    Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

    0 Comments

    Read More

    Agile Metrics

    July 2, 2010 in .NET, Agile, Agile FAQ, Java by Mark Levison

    Business Graph I’m frequently getting requests for good Agile Metrics and I’m never quite sure how to respond. Courtesy of some time waiting at LGA, I’ve been giving this some more thought. For many organizations metrics are irrelevant, don’t bother collecting them as they will just waste your time (and money).

    If you must collect metrics, here is what I would consider.

    Running Tested Purchased Features – Ron Jeffries is famous the metric Running Tested Features (RTF). I suggest that you consider taking it one step further until you’ve sold the feature to the customer you don’t know if they value it or not. For most product organizations this is a bit of stretch to measure in which case stick with Ron’s advice.

    Questions to ask:

    • What would you like to change?
    • If you had the information the metric provided what action would you take? Can you take that action now without the proof of the metric?
    • Your key measure (i.e. RTF), should measure your widest span of control – Sold Features > Deployed > Automated Acceptance Tests > …
    • Measure Cycle Time – i.e. how long it takes to get something done and not people.
    • Other measures can be used: i.e. test coverage from Unit Tests, but be careful they might measure what you think they mean.
    • Measures can be gamed/fooled (intentionally or otherwise): For example test coverage measures whether or not a line of code has been visited. It doesn’t measure if there its meaningfully tested. If you must use a measure like this pay attention to the trend and not the absolute number. In this case a large jump might indicate someone having written a not very useful test of the outside api of your application.
    • Metrics have best before dates. Eventually you will stop getting real value from them. At that stage throw them away.
    • Ask can I get this information by walking around, observing and asking questions.

    Alright you made it this far you deserve some options:

    Martin Fowler says: CannotMeasureProductivity. Dave Nicolette presented on this at Agile 2009 (this article links to heaps of others). I wrote this for InfoQ last year:  What is a Good Agile Metric?. InfoQ also has: Metrics in an Agile World.

    The following tools will help you measure, but please remember they often have many bad measures (comments?) turned with the good ones. Think carefully when choosing your rulesets:

    • Sonar – has a bunch of interesting measures: Cyclomatic Complexity, Duplicated code, … . While there are other plugins, its of most use in the Java world.
    • JDepend – helps you spot good vs. bad dependencies.
    • PMD, FindBugs, JLint – see a comparison of all three (pdf). Some of these tools check some pointless things: method name too short or too long? missing Javadoc comments? Please configure these with the help of a grown adult. But they can also be configured to spot methods (> 30-40 lines) and classes (>300-400 lines) that are too long.
    • NDepend like JDepend and heaps more measures. Again please be careful configure only with an adults help :-) Caveat Emptor I’ve been given a free copy of NDepend (that I’ve never had a chance to use).
    • Sonar for C# – yes according to StackOverflow.

    When paying attention to measures of the code, what matters is the trend and not the absolute numbers. Finally just because a tool can measure it doesn’t mean its worth measuring, conversely some of the best measures don’t have tools to measure them. In this case note that none of the above tools measure cycle time.

    Updated to make clear the point that you shouldn’t measure people and the limitations of tools.

    6 Comments

    Read More

    New People on Your Project

    June 3, 2010 in Agile, People by Mark Levison

    A man standingYour project schedule says that you will get 2 more team members this week and 3 more next month. How do you integrate them into the team? How do you bring them on board? How do you avoid slowdowns? In a word you can’t avoid the slowdown – adding new people to the project will slow the existing team down.

    On any project it will take from 2-4 months for the team to integrate a new person and recover from the slowdown:

    • The person will need to be trained: In your code base, how your application works, what coding style is, how you application works, …
    • This person will disrupt the Teams Formation (see Tuckman’s model of team formation) – this is an especially important cost when the team has already reached the performing stage. This happens because the new person alters communication paths and will force people to renegotiate relationships around the entire team.
    • The person will be a drag on the team requiring support to learn new tasks.
    • The person will increase the communication complexity (i.e. the number of communication paths) within the team.

    All of this leads us to discover Brook’s law: “adding manpower to a late software project makes it later” (from the Mythical Man Month 1975, reprinted in 1995). The physics of people hasn’t changed in 35 years.

    So what can you do to solve this problem?

    • Say no – if its too late in the project – in many cases 4-5 months before release is too late.
    • Can’t say no consider what Project Udall (Surviving Object-Oriented Projects Alistair Cockburn, p20) did: Halt the big project, start a small project and add only the people who can contribute to its success to the new project. While its expensive to have people sitting idle, it may be cheaper than having them slow the project down.
    • Bring on all the new people at once so at least you pay the costs once in the life of the project as opposed one person at a time.
    • Create a new team staffed by the new people with one or two old timers. They won’t get very much done for a while, but at least they get in the way of the others.
    • Get them to help with the exploratory testing, with the focus being the stories that are being written in that Sprint of iteration.
    • Ask them to write or refactor some automated acceptance tests.
    • Get them to read and write Unit tests – start by reading existing Unit tests, after all these should explain the code. If they’re not already Good Unit Tests then take the time to improve. If they’re good then do some small refactorings in the main code base – after you can trust your tests can’t you :-)
    • Ask them to pair with another developer

    Just remember adding more people to a project is a way of slowing your project down.

    8 Comments

    Read More

    Agile Retrospectives

    May 27, 2010 in Agile, Agile FAQ by Mark Levison

    teamwork 2 Continuous Improvement and Short Feedback loops (think: Test Driven Development; Sprint Demo/Review; …) are at the core of any Agile process. Without a structured improvement process it can be difficult for teams to improve and without improvement we stagnate. For methods like Scrum, XP and et al Retrospectives are that tool.

    What is a Retrospective? It is a moment for the team to stop, breathe and take a break from the day to day grind. Its a chance to step back and reflect on the past iteration. To find things that worked well, things that need improvement and what the team has the energy to improve.

    How do Retrospectives differ from Post Mortems (see CIO Update and PragmaticSW)?

    • Post Mortems occur after the project is done (or even dead), when it’s too late to improve that project.
    • Post Mortems are long feedback loops, once per project might mean every 6-18 months
    • Post Mortems often generate nice reports that are placed on a shelf and ignored (also called write only documentation).
    • Post Mortems sometimes turn into blame and shame events.

    Well run retrospectives provide an opportunity for small improvements. The keys to a well run Retrospective:

    • Retrospective Prime Directive (Norman Kerth): “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” The key here is to remind participants at the start of every retrospective this is not a blame and shame. Its about understanding what happened in the course of the last iteration. The focus is on events and not the people.
    • A clear agenda – a simple one:
      • What happened in the last iteration (including what SMART goals did we achieve?)
      • What would like to celebrate/remember/…
      • What areas need improvement?
      • What do we have the energy to improve in the next two weeks?
    • Clear Ground Rules see: Meeting Ground Rules Updated
    • An Open Mind from all team members with the focus on solutions and not the problems.
    • Appreciations – just take a few minutes to share something that you really appreciate that someone else on the team did. Interesting twist I just noticed that Ellen Gottesdiener puts appreciations at the beginning of her Retrospective. That’s very interesting, that will help put people in a positive frame of mind and make it easier to tackle the problems later. Elegant.
    • Once you decide what you have the energy to tackle, set SMART Goals (Specific, Measurable, Attainable, Realistic/Relevant, Timely). See: SMART Goal Setting. In the context of an Agile/Scrum team I would always make timely less than two weeks, so that you check back in the next retrospective.
    • A great facilitator who is able to stay out of the conversation and maintain the flow. Bring an outsider in occasionally, just to see a different approach.
    • Mix-up your retrospective activities to maintain the energy and interest

    Follow-up:

    • Post your SMART goals on the team’s Information Radiator and check up on them in the Daily Scrum.
    • If you don’t make the improvements that people choose then Retrospectives will quickly lose their value as people say: “Nothing ever happens from these”.

    When: At the end of every iteration or sprint. Allow one hour for every week of iteration. So a 1 week sprint would have 1 hr, 2 weeks a 2 hour retrospective. 3 weeks a 3 hour retrospective, 4 weeks – no one does those anymore right?

    Who: The whole team – I like to see (or hear) the Product Owner and the Scrum Master. Some people will tell you that the PO isn’t necessary. Fine, but if they’re not there they can’t help make things better.

    1 Comments

    Read More

    Thanks to XPToronto, Agile Quebec and an Apology

    May 19, 2010 in Agile, Brain, Science by Mark Levison

    Header

    In the past two days I’ve presented “Learning Best Approaches for Your Brain” to two audiences. First in Toronto for XPToronto and then Quebec City for AgileQuebec. We got fair sized audiences for each and both groups seemed to have a lot of fun. Given my lack of French I’m truly amazed about how engaged the Quebec audience was – neuroscience doesn’t transcend language barriers easily.

    I would to thank  the organizers of XPToronto (Lawrence Ludlow, Michael Sahota, and anyone else I missed) you created a great evening. I would especially like to thank Lawrence for picking me up from the airport and bringing me into Intelliware for the day.

    I would like to thank Karl Metivier for remembering me from Agile2009, inviting me to Quebec City and driving to pick me up. I would to thank Louis-Phillippe Carignan, Alex and George (sorry I didn’t get last names), for organizing Agile Quebec and growing it, to its current size.

    I was asked for my current slides, even with the notes they’re not very helpful. Nonetheless here they are: Learning Best Approaches for Your Brain.

    Finally after the presentation I was made aware that I hurt (emotionally) one of my attendees. During my survey he said that he “wanted to learn about Agile”, I wanted to say that this presentation wouldn’t help, but that isn’t what he understood. He felt attacked. Later on I made use of his example again, I can’t remember what I said. He felt attacked again. I apologized in person and he said he didn’t buy it. I accept that. This is my public apology. I pride myself on being a ‘human focused’ Agile coach and obviously didn’t live up to my own standards. For that I’m truly sorry.

    1 Comments

    Read More

    Speaking in Toronto and Quebec City

    May 14, 2010 in Agile, Agile 2010, Brain, Science by Mark Levison

    Promouvoir l'agilité à Québec

    I will speaking at XPToronto on Tuesday May 18th at 7pm and Quebec City on the following evening at 6pm. Hopefully I can visit Montreal and Waterloo another time.

    Learning Best Approaches for Your Brain

    Do you wonder why people don’t understand the idea you’re trying to get across in a meeting? Are you mentoring another developer and struggling to understand why the still don’t get it? Do you run training courses and wonder why the attendees only learn 10% of the material. All of us are teachers whether as informal mentors, coaches, trainers or parents. Yet only professional educators receive training in this area.

    Only Twenty years ago most people in the world of neuroscience believed that the connections between the neurons in your brain were fixed by the time you were a teenager (or even younger)[1]. Now we understand that our wiring continues to change (even new neurons can grow) as we grow older. It’s just the rate of change that slows down. This is called Neuroplasticity, the discoveries around it are what make this presentation possible.

    To find out more come attend the sessions. Can’t make it? Join me at Agile2010.

    0 Comments

    Read More

    Agile Quick Links #14

    May 5, 2010 in Agile, Links by Mark Levison

    shovel bucket and sand I started this week’s Quick Links last week at home in Canada. This week I’m at a client in the States and seem to have even less time in the evenings to write. How does that happen?

    In People, Processes then (Maybe) Technology, Elliot Ross finds another angle one of my favorite thoughts. Tools are just enablers of process. When someone says which Agile tool (i.e. Rally, VersionOne, Danube/CollabNet, ………………) should I use, I reply “wait until you understand how you do agile, then you can decide which if any tool you need”.

    Nigel Shaw writes: No Wonder Agile Guys Shun Tools in it he lists some of the many ways that agile tools fail in their attempt to mimic whiteboards. I add to his list: “As good as you make a tool displayed on a screen, it will still suffer from the problem that no one looks at the webpage very often. People walk past a physical story board many times a day, during standup they can touch the stories they worked on. Finally when someone comes up with a bright new idea for the board you implement it minutes with tape, PostIt Notes and white board marker.”

    Steven “Doc” List talks about “A Culture of Heroism” and its ill effects on a team.

    How I Learned to Let My Workers Lead – the story of Ralph Stayer the CEO of Johnsonville Foods. A great story of he completely changed the way his family Sausage company worked.

    0 Comments

    Read More

    Agile Quick Links #13

    April 20, 2010 in Agile, Agile 2010, Links by Mark Levison

    imageMichael Spayd has written a brilliant distillation of Scrum, as The Tao of Scrum. It boils Scrum down to its soul and essence. (Yes Sandy Scrum does have a soul).

    George Dinwiddie reminds us that estimates really are just estimates: The Importance of Precise Estimates.

    I love seeing the application of Agile outside of software, John Cass writes: Thinking Iteratively With Agile Marketing.

    In Effective exercises for teaching TDD Gojko Adzic writes about a problem I’ve had a few times.

    If your presenting at Agile2010, you owe to you audience to read: Three Steps to Make Your Next Speech Your Best by Nick Morgan.

    0 Comments

    Read More

    Page 1 of 612345Last »
    If you enjoyed this post, subscribe to my RSS Feed