AGILE IN ACTION

Pirate Rob on Grails Selenium RC

2009-11-21T11:50:00.003Z

Pirate Rob gave a talk last night at London Groovy & Grails User Group about testing Grails applications with the Selenium RC plugin.

Backstage at Boffoonery

2009-11-04T19:07:00.011Z

Finally Boffoonery happened last night and it was absolutely spiffing fun. I'm so glad we sponsored it. It was a triumph and a wonderful tribute to Bletchley Park and to those who worked there. Congratulations to the cast, especially Johnny Ball for his performance during the quiz and for reminding me of the fun I had as a child watching his TV shows. Jason, you can be proud of what you've done here and you thoroughly deserve that big cigar! Clive Flint was a superstar and came to the rescue at the last minute to take some wicked photos on the night. It was cool to go backstage beforehand and impose as the stars chilled out. And it was great to talk with Simon Greenish at the bar afterwards. Thank you again for your invitation to Bletchley Park. We'll be up there pronto.

Backstage with the girls
Originally uploaded by clive.flint

Robin Ince and Johnny Ball
Originally uploaded by clive.flint

Maggie Philbin and Jason Gorman
Originally uploaded by clive.flint

Some of the cast
Originally uploaded by clive.flint

Thanks Jason for the Commutineer coverage especially the centre-spread in the programme (below). We're continuing to improve the Web site and we'll continue to do so beyond the official launch later this month. So don't wait until then! If you're dallying with the daily commute please share your experiences, observations, encounters at commutineer.com. Be naughty. Or nice. What you say may be useful to other commuters. And we'd love more feedback. We plan to hook it up to Twitter too. So if you're tweeting about your commute please tag it #commutineer.

How we use stories

2009-11-02T13:15:00.010Z

All our work items, both user-focused and technical, are stories framed in the context of a user interacting with the product. Each story represents a distinct, visible and testable piece of work that can be delivered independently to realize some value. Stories exist at many levels of specificity and never convey solutions. For example, at a point in time it's sufficient to use an ambiguous story to describe an interaction as simply an activity a user engages in using the product. At some time later, typically when detail starts to matter, smaller stories are written to describe that activity in terms of more specific tasks the user performs with the product.

Stories are written on index cards measuring 6 by 4 inches. A description of the user interaction is written in as few words as possible on the front of a card to provide a brief outline. This provokes conversations to reveal and understand the details, which are captured as acceptance criteria on the reverse side in the language of the user. The physical card serves as a token, exchanged amongst the team when different people work on the story. It also acts as a physical flag that shows others what's in progress and a story's history in terms of the feedback obtained so far from testing, user experience, etc. Different colored index cards are used for different types of user:

1. Business and end users

White cards describe stories written for business and end users.

Green cards describe user experience stories that need to be completed ahead of time and in just enough detail, e.g. using low fidelity prototypes or design mock-ups, to facilitate an iterative approach and provide useful input to the corresponding white cards.

Pink cards describe defects from the users' perspective and include the steps to reproduce on the back. We never debate whether something is a defect or not, we just ask the product owner.

2. System and technical users

Yellow cards describe stories written for technical users, e.g. a system administrator operating and supporting the product, or for discrete system engineering work such as scalability and resilience.

3. Technical debt

Blue cards describe stories written for developers, who are considered users of the system at an engineering level. They describe technical debt in system and software terms and include acceptance criteria on the back so the developers know when they're done.

The size of a story isn't important until it's planned and prepared, ready to be implemented.

Developing the product iteratively

Using iterative development we progressively refine and extend functionality already delivered. Over time a user task is sometimes revisited by any number of stories. Whenever possible we use a green card to build a paper prototype that allows us to evaluate interaction designs with users before developing any software. The first white card typically delivers very basic functionality that allows users to perform the task using the product. Feedback from users validates our assumptions and often initiates a new story to enhance the functionality or improve its performance and ease of use. Every story aims to improve the experience for the user based on their feedback to enable them to perform the task more efficiently or effectively.

By delivering a minimal version of functionality early and then evolving it in response to user feedback, we remain receptive to discovery and keep our options open rather than committing prematurely to a specific user experience. This way we invest more wisely to deliver exactly what the users wants, and no more.

Timeouts and retrospectives

2009-10-22T00:11:00.003+01:00

We use timeouts and a couple of different retrospectives to drive improvement. Stop-the-line events like Pomodoro timeouts and Pomodoro retrospectives happen spontaneously within the team to solve problems immediately and produce small continual improvements. We also use a monthly retrospective for the product stream to reflect on how it's working and conceive bigger, more strategic improvements.

Pomodoro timeout

One of our norms is that anyone can call a timeout. The team calls timeouts frequently, usually more than 1 a day; they seldom last 25 minutes and if they need longer they just run another Pomodoro. People huddle in the bullpen, sometimes around a whiteboard, to discuss something within the remit of the team and collectively decide what to do. Whether the purpose is to discuss a technical issue and define a set of spikes to prove the way forward, explore options to get around an obstacle, or investigate a process issue, the timeout often creates opportunities to make improvements.

On-demand Pomodoro retrospective

When something extraordinary happens the team runs a Pomodoro retrospective in 25 minutes, as soon as possible after the event, to find the root cause and agree 1 specific and clearly defined action that can be taken immediately to prevent it reoccurring. We like to use the 5-whys technique but we also use other activities (within the format - brainstorming, affinity mapping, dot voting, decide what to do) depending on what had happened. The retrospective is always done standing up to keep people focused and energetic. Most of the time the retrospective concentrates on events that the team could have controlled or avoided. However, sometimes it investigates problems in the product stream that were outside the team but nevertheless impacted them, in which case appropriate people from the stream also participate.

Monthly retrospective

Once a month the facilitator runs a structured retrospective for the product stream (that involves setting the stage, gathering data, generating insights, and deciding what to do, close). Everyone in the team attends, including the technical mentor, as does the business sponsor, product owner, team leaders from the business users plus a handful of their staff, and other people from the various business disciplines within the stream. The purpose of this retrospective is to step back and look at the big picture, including any external factors that have affected the stream, and identify any trends. We challenge how we currently work and try to get beyond the obvious to discover transforming ideas that would make the product stream more effective.

Product stream

2009-10-21T23:19:00.037+01:00

A description

Think of a product stream as a small company working exclusively on a product and delivering features that excite users to maximize profit and growth. The stream invests in its relationship with users and is set up to compete on the basis of speed. It has everything it needs to conduct business, from concept to production to operational support, and unlike a project it persists as long as the product is in service. It includes a dedicated and diverse technical team that is actually part of the business and helps them use software more effectively. It self-organizes for optimum delivery and minimum risk, and produces flexible software that responds as the business learns from user and market feedback.

Everyone in a stream is located together in the same place and works full-time to develop a common understanding of what users value, and to achieve a shared vision for the product against which success is measured. People in the stream collectively own the product and share responsibility for achieving results. Cash flow is key. Everyone understands the financial consequences of decisions and actions, or lack thereof, so people think in terms of delivering value to users as quickly as possible and cost effectively. Only people in the stream work on the product; in a transparent environment they collaborate intensively, communicate honestly and keep the right information visible so that informed decisions can be made at the right time.

A stream has 4 key roles that together provide entrepreneurial leadership and unified direction:

The business sponsor is a product champion and a visionary. He owns the budget and is ultimately responsible to the company for the overall product stream and is accountable for its results. With empathy for users, a deep knowledge of the market and an understanding of the stream's capabilities, he defines the strategy and makes business decisions quickly.

The product owner is the sponsor's right-hand man and also a product champion. Synthesizing the needs of different users (and stakeholders), he focuses delivery on evolving features in response to their feedback and changing market conditions to facilitate business agility.

The technical mentor is a master craftsman with business acumen, extensive knowledge and vast experience in delivering high-quality software products to market. He coaches the technical team on a journey that they cannot take on their own, using earned trust to show them new skills, techniques and thinking processes.

The facilitator actually leads the technical team with passionate support and faith in their work; he manages the budget and is responsible for results. Facilitating without detailed or coercive direction, he lets people self-organize, steering with a light touch. He helps the team function effectively by providing everything it needs, driving consensus decisions, removing obstacles that impede delivery and creating an environment in which peoples' potential is developed based upon mutual respect and cooperation.

The technical team comprises all the technical skills it needs to develop software for production and operational use. There are specialists such as testers, system administrators and designers, however everyone works to acquire more general skills to build resilience into the team. A stream is always learning. It works continuously to eliminate waste and improve through reflection and experimentation. Creative energy flows, existing knowledge is shared and new knowledge is created as everyone works with shared responsibility to improve quality, remove causes of failure and find better ways of working.

Over time the composition of a stream varies to suit the needs of the product. However, it retains the skills and expertise it needs to deliver the highest possible quality and service to users. The business sponsor, product owner, technical mentor and facilitator are always present.

Shorten the value stream by bringing it inside

Our goal, starting and ending with the user, is to shorten the value stream and encapsulate it within the product stream. We aim to seize a crisis and initiate kaikaku events to eliminate some of the more obvious non-value adding steps. We collocate and remove dependencies to eliminate handoffs between teams, co-ordination overheads with other teams; waiting around for information, approval, access to business people or shared resources; chasing people in different locations for responses. We favor open-source software rather than relying on core teams producing platforms and infrastructure systems, and we remove all other dependencies by absorbing skills and responsibilities into the product stream. For example, in a recent stream we had established a cooperative partnership with the company managing the datacenter where our production environments were hosted and they agreed to implant a system administrator into the stream to work as a member of our technical team.

Within the product stream, the necessary conditions are nurtured to enable frequent delivery of features to users, at a predictable and reliable rate. Work in progress is limited to the capacity of the technical team (minus some slack) to avoid people burning out and they always stop to fix problems before continuing. Working at a sustainable pace, they even out the arrival of work by making stories approximately the same size, use pull scheduling and release every week to create flow.

The technical team operates all the environments, including production. They automate as much as possible and manage the monitoring, alerting and capacity planning. Consequently they develop expertise in how the product runs, which enables them to diagnose problems more effectively. They also get to innovate in the 'system space' to meet business and user needs. They select the technology stack, deploy the product to the production environments, and they operate and support it, 24/7. If they do something to break production, they feel the pain straight away. They work hard to prevent that happening by delivering high-quality, well-tested software and, with end-to-end knowledge and full access, the team works continuously to eliminate complexity and duplication across the system, and to reduce the overall maintenance and support effort.

Rolling ownership of stories through the team

2009-10-20T14:50:00.004+01:00

We added rolling ownership to our pair-programming back in April 2008 and we've been using it since.

Rolling ownership enables as many people as possible to get involved in delivering a story. When a new story is started, someone volunteers to own it and another person volunteers to pair in. They work on the story until lunchtime. After lunch, the pairs swap. For each story in progress, the owner moves off the story passing ownership to his morning partner and a new volunteer steps in to pair. This rolling effect allows tacit knowledge of the story to be retained across pair-swaps. When each person owns a story they add their initials to the right-hand side of the card. Repeated everyday, most, if not all, of the team play a part in delivering each story. We've found that rolling ownership facilitates shared learning and decision-making, helps spread knowledge of the product around the team, and the pair-swaps and shifting ownership keeps people communicating.

Two stand-ups a day

2009-10-20T14:01:00.003+01:00

For a long time now we have run 2 stand-ups every day, first thing in the morning and first thing after lunch, always at the same times and always around the board.

The morning stand-up discusses the work-in-progress and allows the team to co-ordinate their efforts to get stuff done. It usually lasts no longer than 10 to 15 minutes and starts from the top of the board and works downwards to cover any defects followed by the user stories, debt and design work. People stand in a semicircle and face the board. Each story owner steps out front, faces everyone, and speaks about progress on their card. In terms of the acceptance criteria on the reverse side they describe the current focus and the next steps. They also share what they've learned and what has consequently changed in the story. When progress on a story is obstructed a pink Post-it note is stuck to the card, which says BLOCKED and includes a brief description of the impediment. When all the stories and impediments have been discussed the team forms pairs to work on the cards.

The afternoon stand-up is usually done in less than 5 minutes and focuses on rolling the ownership of stories and arranging new pairs. It's also an opportunity for people to provide updates on anything significant that had occurred during the morning.

Using the Gordon Pask Award to share with people

2009-10-12T22:54:00.000+01:00

We've got some ideas on how we can give back to the software community but we'd like to hear your ideas.

What would you like to hear more about?

Where do you want it delivered?

Conferences are an obvious choice. I'm interested in usergroups.

Please write your suggestions as comments to this blog post.

Concept to cash every week at JAOO

2009-10-07T11:30:00.030+01:00

Yesterday at JAOO, Gus and Kris talked about going from concept to cash every week. It's describes how we're currently working at Energized Work and some of the experiments we're running to find new and innovative ways we can improve and be more effective.

Here's a zip file with the slides and narrative.

It's great to get feedback and it seems the session was well received. 166 people attended with 26 leaving before the end. 74 said it exceeded expectations, 65 said it met expectations and 11 said it didn't meet expectations. Here are some of the tweets:

sejacobsen: The "Concept to Cash" talk is fast-paced and unrelentingly delivered by @guspower and Kris Lander - much like their core message #jaoo

christerdk: "Ensure change is cheap", "Care about the software", "Don't get bogged down by technical debt","find and fix immediately"

christerdk: Doing pomodoros (and break) in the middle of a session! :-)

jakobfaerch: Listening to The EnergizedWork people. Are work habits like the ones they describe really possible? #jaoo

jduchess: Lander & Power #jaoo: keep it moving, keep it working, keep it together, keep it real!

tjementum: "Turing on a sixpence" by Gus Power and Kris Lander at #JAOO was the best. They are pushing agile to the limit. Got lots of ideas.

alradk: #jaoo, just saw Gus Power in Turning on a 6 pence. Damn, this was a powerful prensentation! From now on i'm working wednesday - tuesday!!!

Outside, in

2009-09-26T14:04:00.003+01:00

We create software by working inwards from the users' experience. Maintaining focus on the users' perception of 'the system', we do just enough to satisfy the needs of the user rather than what we think is necessary or cool. On a regular basis, we come up for air to check context and avoid getting lost in the weeds. We decide which direction to go next based on where our client sees value and consider how we're going to demonstrate what we've created so far. We don't jump into unit land because trying to connect all the pieces at the end doesn't produce a good solution.

Focus On Intent!

2009-09-08T12:54:00.001+01:00

I frequently use the term 'focus on intent', especially with respect to the writing of story cards and acceptance criteria. When I'm focused on intent:

I understand, with absolute clarity, the goal my customer is trying to achieve and it's NOT expressed in terms of how I am going to get there.

I have distilled the context of the situation by identifying the most significant or important contributing factors.

My clarity of understanding allows me to convey meaning, describing these factors clearly with a high signal-to-noise ratio.

My state of mind is determined and concentrated on a central point while I focus on achieving only one thing at a time without ambiguity on the outcome.

I have identified a clear, unambiguous measurement that will tell me when I am done.

I am conscious of the essence of design and so I maintain consistency at different levels of detail so that everything makes sense separately and in context of the whole.

For me, focusing on intent conceptually represents a cognitive state required to be effective. However, achieving this state of mind isn't easy, especially in a busy environment. Personally, I find the Pomodoro technique useful in staying focused.

We don't need no stinkin' process

2009-09-02T20:39:00.027+01:00

We're enjoying ourselves so much I'm wondering if it's illegal. We're working in a 4-man team with a new client (who consult for the Lean Enterprise Academy) and we're experimenting with some new techniques. Our goal is to create a product that is very kind to its users, so we're trying to stay as close as possible to the users' conceptual model and stop thinking like programmers all the bloody time. When we catch one another 'flipping' to techie mode we quickly 'flop' them back to user mode.

Keeping the interaction design simple, so that it can be easily learned by users, is difficult. We've used paper prototypes to explore options and we're also iterating the interaction design as part of developing the user stories. This approach is working well. We do, however, need more ready-access to users to help reduce rework. (When does iterating, and the learning that comes from it, become wasteful rework? A subject worthy of it's own post.)

Another thing is ... we don't need no stinkin' process. I reckon it's because our team is small, has only generalising specialists who have worked together for ages, we trust one another implicitly, and our environment is extremely collaborative and fun-packed. Ok, it's not entirely accurate that we have no process. I just wanted to use the Blazing Saddles clip. There is some semblance of a process but, honestly, it really, really doesn't feel like it. It just feels like the natural flow a conversation takes. Perhaps it's that the interactions are so second nature to us it just seems like everything is a conversation triggered by something that's happened or has been discovered:

Discuss a story in a pomodoro.
Pair up and pull its card into play.
Start slicing - working inwards from behaviour-driven Selenium acceptance tests, incorporating any non-functional and sysadmin work, while iterating the interaction design work.
Call a timeout and talk in a pomodoro when something important happens.
Deploy the accepted story to production.
Go again.

I guess it's essentially Kanban and one piece flow, perhaps with a few twists we've introduced over the years. We just say keep it moving - keep it working - keep it together - keep it real - and keep it coming. (We evolved to our kanban-like thing independent of the Kanban movement. Hopefully David Anderson will corroborate that claim. I think this is interesting because a mulitude of separated parties, working independently, have concurrently evolved their process, given their own interpretations of the Toyota systems, to arrive at something with similar properties. It may be plausible to argue that this was predictable given the specifics of the Toyota systems.)

Anyhoo, some people will say we're lucky to be able to work with such freedom. And we are lucky. Others say you make you're own luck. We choose to work freely and we choose our clients. :)

We won the Gordon Pask Award

2009-08-28T23:53:00.001+01:00

We're very pleased to receive one of this year's Gordon Pask Awards.

We'd like to thank the people who are part of our adventure: The crew at Energized Work who continue to inspire and challenge us; our clients, who have been courageous enough to try something different; and our friends in the agile community who have supported our endeavors. This award is for them all.

A few years ago we said companies valued the wrong things; businesspeople weren't accountable for their decisions; software development lacked craftsmanship; and people weren't empowered to do the right thing. Our 'No Compromise-No Excuses' approach gained us a reputation as zealots. Yet to us, it was just a decision not to compromise on the stuff we think is important.

Craftsmanship, personal discipline and rigor are important to us. But software is much more than code. We wanted to work with companies who recognized their software as assets and were prepared to push the boundaries, to change their organization and culture, to achieve greater effectiveness.

We're excited by the future - working with new companies, evolving our use of pomodoros, product streams and lean accounting to maximize client profit, and testing our ideas for user-driven development. Rest assured, we'll continue to challenge the status quo and we'll continue to learn and improve.

Thank you all very much.

New Energized Work website is coming soon

2009-08-26T10:16:00.009+01:00

We'll finaly get around to finishing the Energized Work web site in September. In the meantime I wanted to share a glimpse of the design. It's been a great journey with Tim Nicholls at Electric Light Box, as we captured our attitude and ethos in this 'comic book' feel.

A new dawn, a new day. As they say. And every day we continue to experiment and improve The Energized Way.

Thinking out loud about users, behaviour and acceptance tests

2009-08-13T23:58:00.000+01:00

I want to play more with the combination of behaviour-driven development and Selenium IDE. Stuff isn't clear in my head yet and I'm not entirely sure what I'm aiming for. Maybe it's that, given my interest in usability and interaction design, I want greater emphasis on the user in our acceptance tests.

Am I seeing a Selenium test demonstrate the achievement of a user's goal, broken down into the user's actions expressed in plain English that map, under-the-hood, to Selenium commands?

Questions I'm asking myself: How do these tests relate to the acceptance tests on the back of the story cards? Are they the only tests on the back of the card? If they're not user-focused their 'internal', right? Are there other kinds of Selenium-based acceptance tests, perhaps within a hierarchy, which don't focus on the user? Are these aceptance tests?

Um ...

Scrum Mastering isn't a part-time endeavour

2009-08-04T17:58:00.003+01:00

Don't be a part-time scrum master because 'you can't see the picture when you're in the frame'.

Focus focus focus!

2009-07-24T17:51:00.003+01:00

Time isn't the problem. How you use time is.

Don't bother managing your time. Manage your focus. We use pomodoros to sharply focus on achieving a goal every 25 minutes. If you focus on the activity you'll just wheel-spin and dig a hole. So focus on the goal - what you want to achieve.

To really focus you need clarity about what you're aiming to achieve. So have a really concise and expressive way to define the successful outcome (be it an acceptance test, a vertical slice, or whatever).

Finally, getting stuff done is one thing. Getting the right stuff done is even better. So figure out what's important and focus only on that. Duh!

Get beyond the Now and into the Potential

2009-07-24T11:34:00.007+01:00

Nido Qubein said something like: The trouble with many plans is that they are based on the way things are now. To be successful, your plan must focus on what you want, not what you have.

Many times I've witnessed vision and ambition constrained by a plan confined to how things are done now. It's almost like there's an invisible bubble defining how one 'can' and 'cannot' get stuff done (or not get stuff done :). Although, in reality it's more like what people 'will' and 'will not' do given their perception of what's permitted. "Oh that won't work here".

Providing your aims are to do the right thing I think challenging the status quo is right and proper and, in my experience, the consequences are seldom bad. It's nearly always all in your head and when people see results they usually join in. Personally I enjoy challenging the status quo and I consider it to be a healthy and necessary exercise to drive continuous improvement. And dare I say it, a little construction subversion, if that's what's called for, can be fun.

So, don't allow yourself to be held back by the Now. Look beyond into the Potential where anything can be achieved. Then go after it with courage, persistence and integrity.

First cut of commutineer.com is now live

2009-07-04T20:29:00.011+01:00

We put a new Web site live recently. It's called commutineer.com and it's a bit of an escape from the drudgery of UK commuting. Commuters can have conversations, share news, rant, be cool, flirt, and stand out in the crowd. They can form tribes around topics, stations, rail lines and networks. And earn vitality points, compete for top spots in the day and the chance to become the top commutineer. While on the move, commuters can do most of this with text messages from their mobile phones (standard mobile rates apply :).

It's got some ways to go and we've got lots more ideas but we wanted to push an early cut live to get some feedback from real users. We've been developing the functionality iteratively so there are some 'cheap' features on the site that we'll be enriching and improving over time.

If you commute in the uk, please join the mutiny and register to become a commutineer.

We'll be handing out freebies around London in the coming weeks and we're also sponsoring Boffoonery, a comedy event to help raise money for Bletchley Park, but we'd really appreciate your help to spread the word. Tweet about it. Put it on your Facebook profile. Please tell your friends about commutineer and ask them to tell their friends too. Many thanks.

You can also follow our progress on twitter as we continue to improve the site.

Don't remove failing tests from the build

2009-05-15T14:12:00.000+01:00

Extreme Pair-programming

2009-05-15T13:13:00.006+01:00

The 'trailer-park boys' at Energized Work have started extreme pairing. First up .. The Jerry Springer Show. Let me tell you, trying to fix the build with guys fighting in the background ain't easy.

Pairing on the Jerry Springer Show
Originally uploaded by sjb140470

Extreme Pair-programming
Originally uploaded by sjb140470

Pomodoro galore

2009-05-14T22:17:00.015+01:00

Almost everything for us is now a pomodoro. Some time ago we replaced the per-iteration planning game with on-demand planning pomodoros and the end-of-iteration retrospective with a pomodoro retrospective.

Every Wednesday, the first day of our weekly iteration, we kick off with a 25-minute planning pomodoro to give us just enough stories to make a start. It uses a modified fishbowl format to stimulate the right level of technical discussion and keep energy levels surging. When the board gets short of stories (and the team is in danger of stalling) we run another planning pomodoro to top up the 'waiting' column. We keep doing this until the showcase on Tuesday but we're careful not to end with loads of stories still in progress.

Our estimation is simply: "Is this story less than 2 days?" and the team shows thumbs up or down. If it's not, the story is split there and then. A pre-planning pomodoro run in advance of Wednesday, looking ahead into the next iteration, helps to size stories appropriately and get the acceptance criteria on the back of the cards. Our velocity is the average-to-date, over all the iterations, of the number of cards that made it to done. This gives us a steadier velocity than summing the estimates of the stories that made it to done in that iteration. We're not really using the velocity for planning purposes though. We use it to calculate a per-story cost, in £, derived from what was delivered in the iteration and the overall capacity cost for the iteration. From this we can then calculate the cost of any inventory and outstanding technical debt. It's sobering to see these things in money terms. I'll blog separately about the simple profit-and-loss sheet we use based on lean accounting and the metrics we watch.

The pomodoro retrospective is conducted standing up. This keeps things moving and keeps people focused. 25 minutes doesn't provide a lot of scope for variation of activities but we can easily cover our standard format: brainstorming - affinity mapping - dot voting - and agree one action that will improve things. I expect this will eventually get boring so I'm thinking of ways to do pomodoro 'lets improve this, here-and-now' sessions that are triggered by a problem just encountered. I guess these are similar to timeouts. Ultimately, the challenge I've set myself is to focus these continuous improvement pomodoros on making an improvement that is not borne out of (and therefore constrained by) solving a specific problem. They just focus on making an improvement to get better.

We're also experimenting with a new board layout that helps us integrate iterative collaboration with designers. There's some serious thinking to be done here and, to be honest, we could do with a fresh project to try it out on.

What is it about technical discussions and weeds?

2009-04-07T12:16:00.002+01:00

It's tough to prevent technical discussions getting lost in the weeds. Actually, it's the people involved who get lost in the weeds.

What usually starts out as objective and constructive often slides into a protracted subjective and opinionated 'jousting' event. Some people end up focusing on what's personally valuable to them (or motivating for them) rather than on the goal. Some people disengage because they can't get a word in, they've been shouted down, or they've become bored. Everyone walks away frustrated that consensus wasn't reached. Or worse they leave with the illusion of consensus.

Here are some tips for keeping technical discussions out of the weeds:

First and foremost, ensure people with the right skills and experience are involved.

Avoid subjectivity by putting personal code and architecture design styles aside.

Leave egos at home. (Easier said than done!)

Use simple words and aim for clarity, i.e. avoid jargon, including pattern names. Try to develop a language, and maintain a glossary on a wiki, so that effective conversations can be had without resorting to detailed and time consuming UML and documentation (a simple UML diagram can help in many circumstances).

Articulate proposals in terms of simplicity, testability, and technical debt.

Maintain engagement with props to avoid hand waving, e.g. use a whiteboard and draw pictures.

Be patient, stay focused, and keep listening to get through the groan zone and converge at consensus. To truly understand the points other people are making, work hard to hear what they are saying from their perspective.

It's one thing to talk passionately with the courage of your convictions, but consensus cannot be reached through force of argument. Remember, you must persuade people through reason not volume.

Keep assessing the discussion. Dont argue about whether X might do Y - pull-up the code on a projector and show that X does Y. If it has become speculation stop and run a spike to gather some facts. Then reconvene.

Focus on intent. Keep asking whether the discussion is still valuable.

If you've got a facilitator handy insist they sit in on the discussion.

Jumbo Wii Night

2009-04-07T08:49:00.001+01:00

Photos from Jumbo Wii Night at The Energy Lab:

Dan and Jeff
Originally uploaded by sjb140470

Snowboarding
Originally uploaded by sjb140470

Riding rail
Originally uploaded by sjb140470

Steve on Lead
Originally uploaded by sjb140470

Ash riffing it up with Rob
Originally uploaded by sjb140470

Action packed room
Originally uploaded by sjb140470

Guitar Hero III
Originally uploaded by sjb140470

Guitar Hero III .. playoff
Originally uploaded by sjb140470

Zsolt and Roberta on Mario Karting
Originally uploaded by sjb140470

Guitar Hero III .. loading
Originally uploaded by sjb140470

Toby karting
Originally uploaded by sjb140470

Mario karting
Originally uploaded by sjb140470

Playing Numer of the Beast
Originally uploaded by sjb140470

Gus and Jeff
Originally uploaded by sjb140470

Steve and Gus
Originally uploaded by sjb140470

Carving it up
Originally uploaded by sjb140470

Gus pulling a stalefish
Originally uploaded by sjb140470

Zsolt snowboarding
Originally uploaded by sjb140470

Rob Riffs
Originally uploaded by sjb140470

Reflecting at the Fun Day

2009-04-03T10:09:00.024+01:00

We said there was a whole lotta fun to be had at our end of project retrospective fun day and that's exactly what we had - fun! And the various retrospective activities interspersed throughout the day produced a lots useful information and ideas. I plan to blog about these separately because we'll be running some experiments based on our ideas to simplify and improve the way we work as a team. In the meantime, here's some photos from the day:

Goldfish bowl
Originally uploaded by sjb140470

Discussion in the Goldfish bowl
Originally uploaded by sjb140470

My Old Dutch Pancakes
Originally uploaded by sjb140470

Mulling the tulip
Originally uploaded by sjb140470

Mapping 'Technical Discussions'
Originally uploaded by sjb140470

Thought provoking
Originally uploaded by sjb140470

Gus bowling
Originally uploaded by sjb140470

Kev gets ready to fire
Originally uploaded by sjb140470

Si bowling
Originally uploaded by sjb140470

Gordon bowling
Originally uploaded by sjb140470

Mike the bowling shark
Originally uploaded by sjb140470

Toby bowling
Originally uploaded by sjb140470

Discussing the fundamentals
Originally uploaded by sjb140470

Steve presents ideas
Originally uploaded by sjb140470

Pool hustler Paul
Originally uploaded by sjb140470

Watch this guy play!
Originally uploaded by sjb140470

Steve on the 'Killer' Scoreboard
Originally uploaded by sjb140470