Agile Coaching

Distributed Agile in a Virtual World

The most thought-provoking session, I attended at Agile2009 was on the Distributed Agile stage entitled "Using Virtual Worlds for Distributed Agile".

Now, I'm not normally a fan of distributed working because communication between team members deteriorates with distance. Alistair Cockburn came up with the neat metaphor of erg-seconds as a way of captures the cost in both labor and time to get a question answered. These erg-seconds (and argh-minutes) are often a hidden cost when a distributed team attempts to apply Agile. However, sometimes you just can't avoid distributed working and I've certainly done my share of skype calls. In fact, when Liz and I wrote our book on "Agile Coaching" months would go by where we didn't meet and instead collaborated via Google Docs and Skype.

Most distributed teams need to brush up on their facilitation skills to make meetings via teleconference bearable (see earlier post). However, at State Farm Insurance, teams have been experimenting with virtual worlds. At Agile2009, Keith Voos and Ami Hileman demonstrated a virtual world used by an agile team to collaborate with team members in multiple locations. I was impressed by their findings; for example, conversations in the virtual world were better quality than a conference call and internet access was lower bandwidth than for webcams.

Keith and Ami showed us a virtual team room that a team has been using for activities like:

• Creating stories
• Estimating tasks
• Radiating information
• Tracking work
• Daily Scrum meetings
• Retrospectives

The space looks very much like a physical team room with colored sticky notes posted up to create a virtual story tracking wall. The developers have also used the virtual world for remote pair programming. There are typical team artifacts: a whiteboard, a burn-chart, a lava lamp showing build status, a calendar, a clock, even some Dilbert cartoons! I've pasted some photos below.

It hasn't been all roses, they have had experience of accidentally deleting walls and also removing avatar clothing. And, of course, virtual worlds don't solve timezone differences. However, the team finds this way of working is fun. On Fridays afternoons, they also play a bubble-shooting game in the virtual world which has helped team building.

I was impressed by the amazing potential of virtual worlds for distributed agile teams, so many people who work in software industry are gamers, it seems blindingly obvious that this is the way ahead for more teams. The tools shown were Qwaq and SecondLife but there are many others out there. And who knows, you may find the cost of these tools cancels out some of those dreaded erg-seconds.

Ever Considered Ditching Your Tests?

At Agile Open Holland, Rob Westgeest proposed a session called "Ditch Your Tests?" I love to challenge assumptions so I joined the conversation to find out if this can ever make sense. Rob kicked off the session by asking us whether, for a stable piece of code, there can ever be valid reasons for throwing away the tests? And if so, why? Rob captured all the reasons we could think of in this mindmap.

It seemed that these things fell into three categories so we annotated the branches with Q, O, and B where:

• Q indicates bad quality tests. These are fragile, hard to maintain or plain stupid tests.
• O indicates tests that are obsolete. These can be ditched because requirements have changed and tests can be deleted along with the code.
• B indicates tests that block us from doing the right thing.

One of our revelations was that once you absorb a TDD mindset, writing tests is your way of learning about what the code does. Reading someone else's tests isn't quite the same and creating that fresh learning. So for complex code, you might choose to go through the process of building the tests again purely to understand it. For example, you might write tests to understand how to use an API. The tests you write can be thrown away, in this instance, as you're not testing that the code that implements the API, these tests simply help you understand how the API can be used.

The conversation got more heated when we got into whether Mock Objects put developers off refactoring. I first started using mocks 10 years ago at Connextra, when there were no tools to support this way of working (see brief history). I recall cases where unpicking the mocks put us off refactoring the code and although there are much better tools nowadays, I'd say mocks do create a small barrier to refactoring. I've also noticed that Mock Objects can sometimes drive teams to write ravioli code where the code is milled down to neat little objects making the larger design harder to see.

So if we have acceptance/system tests that prove the system is working and unit tests are really a design tool then why do we feel nervous about deleting them? Well, the obvious answer is that a good set of unit tests helps us pinpoint bugs and that can save the whole team valuable time. So preserving your design thinking as unit tests has a more practical purpose as well.

Non-Functional Requirements: are user stories useful?

Here are my notes from the London Scrum User Group this week. LSUG meetings are run as a mini-openspace and so several topics were being discussed in parallel. I proposed the topic "Non-Functional Requirements: are user stories useful?" and joining me in this discussion was Sean Witter, Dave Hale, and Roman Pichler (author of upcoming book "Agile Product Management with Scrum").

I tried to take notes of our conversation on a single index card which got a bit messy! I've linked a scan of this card below but hopefully I've captured the main points of our conversation in this post.

We talked about "non-functional requirements" broadly encompassing both execution qualities, observable at run-time (such as security, performance, usability), and evolution qualities (such as maintainability and scalability) which relate to how the code is structured, see wikipedia. But we also agreed that "non-functional" is a pretty bad name. Roman has a friend who works for Audi and he has responsibility for a system property: weight. Perhaps scrum teams might be better off asking their product owner about what important system properties they need to think about.

We got started by talking about the types of developments that require attention to non-functional requirements. One example, we talked about was Google Chrome where performance was distinguishing feature for marketing and Google did explicit competitor analysis. Another example was a  stock broker, for whom seconds cost money, although functionality also has to be correct.

So what's tricky about non-functional requirements and user stories? The first challenge is that a Product Owner might not know that they need to talk to technical stakeholders to get their perspective on the product backlog. This leads to a product backlog which is solely comprised of functional user stories which makes it easy for the team to miss important non-functional aspects. Where a team releases early and often then they can get user feedback which can help reveal this. But if they only have a low number of friendly users then these early releases probably won't be stretching the system and it will only be once the system is under full-load that limitations are revealed.

You can flush out important non-functional aspects of the product at a vision workshop before the team starts sprinting. You can even frame this as a risk brainstorm and make sure key technical experts, such as software architects take part. Afterward, the whole team is aware of what non-functional qualities they need to aspire to. Of course, not every requirement will be anticipated so the team should still expect some aspects to emerge during development.

Another approach is to make sure that the product owner has on-going support from such specialists, you may even decide to pair a business product owner with a "technical product owner". Sean suggested that a BA might be a good "caretaker" for this responsibility.

Once you've flushed out some non-functional requirements, the next challenge is making sure that they get planned in. Non-functional requirements are often associated with more than one single product backlog item- like business rules. Attention may need to be paid to make sure they're checked every sprint. Roman suggested that you can make it explicit which constraints apply to each product backlog by building them in as extra columns in the Product Backlog and checking those which apply to specific item rows.

One obvious way to check that software doesn't slip through without non-functional qualities being checked, is for the team to build these checks into their Definition of Done. If it's hard to measure programatically then this turns into a review by someone.

A Scrum team can also establish a Done checklist which applies to the whole Product Increment. Although they will need to allow time at the end of the sprint to execute this and fix any problems. I've encountered instances where some types of testing is expensive or time-consuming and the team has chosen to defer this specialized testing to a subsequent sprint. Although introducing special polishing/consolidation/release sprints is risky because issues may be revealed that require significant rework.

As we wrapped up our conversation, Roman also suggested taking a look at what Tom Gilb says in his 1988 book "Principles of Software Engineering Management". Tom emphasizes the importance of establishing key metrics from the outset.

I'm interested in your comments on the above as I'll be giving a talk on this topic at DevOpsDays '09  on October 30-31.