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

Just back from Vacation

August 30, 2010 in Uncategorized by Mark Levison

Waste-paperMy inbox has over 600 threads (not just messages, but threads), I’ve a a couple of writing obligations and I don’t yet have a desk in our new house. Please appreciate it may take the rest of September to catch up.

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.

    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.

    Learning Article Finally Finished

    July 14, 2010 in Brain, Science by Mark Levison

    image For the past year every time I give my “Learning Best Approaches for Your Brain Talk”, I’ve promised there would be an article on InfoQ. Well I kept to much work in progress and this week I took care of that problem and we’re live: The Science of Learning: Best Approaches for Your Brain

    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.

    Agile Quick Links #15

    June 29, 2010 in Uncategorized by Mark Levison

    Its been a busy few months since I last did one of these.

    Whenever I collaborate on a presentation, article or some other activity where I can’t see the person I’m working with I use an online post it note tool (i.e. lino.it). Every tool I’ve used so far has some small annoying limitation so I was recently happily surprised to discover Edistorm via @GerryKirk and Hillary Johnson.

    In “Mechanical Agile” Daryl Kulak tells five fictional (I hope) stories of teams went from be Agile to Fragile. Very funny as long as these are not your problems.

    With “Agile: Not Just for Software Development Anymore” April B. (no last name) described the transition of the DAXKO Association marketing team to Agile.

    James Carr describes his experience “Using Innovation Games as Retrospective Activities”. Interesting, I’m currently exploring Innovation Games so this comes at a timely juncture.

    Roger Brown has two items this week: “Adventures in Accelerated Learning” which provides a couple of interesting and timely challenges. “Multitasking Gets You There Later”.

    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.

    Confidentiality, Yours and Mine

    May 31, 2010 in Business, Other by Mark Levison

    -Blank Notes-A recent challenge has made me realize that some things I thought were implicit need to be made explicit.

    Yours

    If you hire me to do some coaching, training or any other work you can be assured that your name and company name will never appear in my blog, twitter or any other public place. The most I will do is mention your name in private conversation. I will only violate this with your explicit permission i.e. we write an Experience Report for a conference. I will occasionally discuss issues that I see at a specific client in a general fashion, but you should find no specific mentions of your business. If you feel I’ve made a mistake contact me and I will correct it as quickly as possible.

    Mine

    If I hire you do some work on behalf of me or my business, I expect the same courtesy. I expect that all discussions whether over email, Campfire, IM, … are private and are between the originally agreed on parties. I don’t expect to see our discussions played out on your blog.

    In general if we have a discussion privately over email (whether or not we have a business relationship) to be kept in the strictest of confidence.

    If I discuss something on this blog or a mailing list, Yahoo/Google/LinkedIn groups then feel free to quote me. If you’re feeling generous please tell (so I can respond) and link to this site.

    The only gray area is twitter, while its fun, all the ideas I and anyone else express are context free. 140 chars is cute, but no more. If you want to quote or think my ramblings unclear please take the time to contact me, I will be delighted to clarify.

    The Problem

    I employed foliovision early this year to help:

    • Port my old typepad blog to Wordpress
    • Make some small changes to my WooTuits theme two support two domains (the original notesfromatooluser.com and the new agilepainrelief.com)

    So far so good. They did that very well and made some other small changes as well. As it happens foliovision is also a design firm and they offered to design a logo for me. Naively I didn’t ask about price up front. Very quickly the price of the logo jumped to be approximately half as much again as the originally quoted price for the job. I asked them to stop work on the logo and on reflection realized that the pill they showed in front of the logo didn’t reflect my ethos. My approach to coaching and consulting isn’t swallow a pill and it isn’t one size fits all. I work in an adaptive, iterative fashion in keeping with the “Inspect and Adapt” principle of Agile. Instead I created my current logo: a person carrying a doctor’s bag because its closer to reflecting me.

    I also promised the people at foliovision that I would eventually write a followup post to thank them for time and to recommend them to others. Unfortunately I haven’t gotten around to that.

    Imagine my surprise when I noticed a blog post that mentioned me by name, discussed my business choices and denigrated my own logo. I contacted folivision to raise my concerns but they were dismissed. I would quote Alec’s remarks to me in private, but that would violate my promise above. Suffice it to say I can no longer recommend foliovision since you don’t know whether they will treat your discussions with any confidentiality.

    To be clear I acknowledge that this site needs some design work, its on my backlog. At the end of the day I put more time and effort into helping clients, personal contact and writing. Less into the site itself.

    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.

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