Shouting is not an agile value

The Agile Manifesto is well known:

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Related, but perhaps less well known is the idea of Agile Values. Their origin lines in Extreme Programming, with there being five recognized values as of the second edition of Kent Beck’s Extreme Programming Explained.

In brief the five values are:

• Communication – amongst all on the team
• Simplicity – of design, emphasizing ideas such as implementing the simplest thing that will work and the acronym YAGNI (you ain’t gonna need it)
• Feedback – feedback from automated tests, from the customer and from the team
• Courage – to keep things simple, to implement only what is needed today, to refactor and throw away code that’s no longer needed
• Respect – for other team members, for the customer

The fuller definitions can be read on Wikipedia (or of course in Kent's book).

One blindingly obvious thing you’ll notice is that shouting is not an agile value. Never was, never will be.

Well duh!

So why do I mention this? Oh well, you know. It’s not like there aren’t some managers who use that as a “technique” for trying to get what they want. It doesn’t necessarily have anything to do with agile, although regrettably I’ve seen it (and once done it myself) in response to somebody just not getting our new technical practices that came along with the agile adoption.

In my case it was due to extreme frustration with somebody who seemed almost perversely reluctant to commit code to the source control system. He was passing around changes to other colleagues by emailing them Java source code. This wasn’t the first difference of opinion about developing software I’d had with the gentleman in question. He harbored some curious ideas and was not enjoying our change over to Scrum.

I confess I rather lost the plot as we were there in the office late at night desperately trying to make sure the team made their sprint commitment. I blurted out rather loudly “What the $#@! are you doing?” I did quickly apologize and later after we’d got the job done we went to dinner and made up. I’m not proud of that moment and it’s not a “technique” I ever intend to use again.

Nonetheless, there are folks out there of a more strident nature inclined to use it far more frequently. I don’t know if their threshold for frustration is lower than mine or if they just need an anger management class or what the deal is. Suffice to say though, as an approach to trying to coach staff into doing what you want it’s not a winner. Indeed it’s a completely toxic behavior. Even if Mr or Ms. Shoutypants has great ideas people are very unlikely to ever “hear” them because they’ve written him off as an aggressive belligerent asshole.

Patience. Now there’s an Agile Value. In fact it’s a key one I believe. Stimulating, inspiring, managing and maintaining the change to agile practices takes effort. It takes leadership. And it takes patience. And so I propose that we add to communication, simplicity, feedback, courage and respect the value of patience.

Measuring the hypotenuse

Consider the following right-angled triangle:



What is x? Not a trick question.

Well it’s 5. Obviously.

But how did you know that? Well maybe for this very simple example you happen to just remember that 3:4:5 are the proportions of a right-angled triangle. But given a non-trivial example with less straightforward lengths to the two known sides you would doubtlessly have employed Pythagoras’ Theorem. Certainly that’s what most people would expect to see if they presented you with such a problem.

There is of course another way. Assuming the diagram is to scale you could measure x.

But that’s not what people would expect; especially if they’d ask you to use math to solve the problem.

In previous blog posts I’ve described a programming problem I set interview candidates at my organization.

The coding exercise I set people is pretty simple. It draws its inspiration from the old text adventure games the likes of Infocom and Level 9 used to produce. If you’re not familiar with this genre the basic gist of them was that there was an unexplored territory that you could wander around with things to find and puzzle to solve. Players interacted with the game using simple text based instructions such as “go north, get axe and kill troll”.

The exercise requires the candidates to do nothing quite so complicated as that though. They simply get an XML file describing a simple collection of rooms connected in various ways and containing various objects plus a text file describing their starting location and objects they need to go find. Their task is to write a program to read the two files and then use some approach to wander through the maze and try and collect the items.

Just as you would expect something to use Pythagoras’ Theorem to find x in the problem above I would expect people to use some kind of algorithm to solve this programming exercise. I don’t care if the algorithm is as dumb as a stumbling drunk, randomly staggering from room to room until every item is found or if you’re using something like Djikstra’s shortest path, just so long as there’s some kind of intelligent solution for us to discuss.

Up until now nobody had disappointed with that expectation either. Just recently though I got a very novel submission. What the candidate had done, rather than algorithmically solve the problem was to simply issue a series of printed lines that simulated what the output might look like if they had done the exercise for real. In other words their “solution” basically was:

Console.Write("At Sculery: lamp\n At Dining Rome: plate\n At Pond: Fishing Rod\n At Library: book\n At Cave-Entrance: Pickaxe\n At pine Forest: Pine cone");

I hunted around for a bit in case there was more. Alas there was not. When I was trying to explain to the recruiter involved why there was no point proceeding further with the candidate I came up with the hypotenuse measuring analogy which he got completely.

Although I’ve never seen anyone else “solve” the programming exercise in quite this way, regrettably I have seen others who approach problems similarly, trying to find any and all obtuse approaches to avoid actually coding what’s really needed. A common variation on the theme is mangling unit tests in perverse ways to avoid actually testing what you should be.

Since this isn’t an isolated phenomenon I decided I’m coining a new term to describe it. Henceforth (for me at least) programming “solutions” that completely miss the point will be known as a “measuring the hypotenuse” approach.

Top ten tips for distributed scrum team teleconferences

Distributed software teams using scrum can spend a fair bit of time on the telephone. Even if you only talk for just sprint planning, daily stand-ups, reviews and retrospectives that could easily be 6+ hours in a two week sprint.

When the team is spread around geographically you inevitably have a mix of people: some feeling tired because it’s early, some feeling tired because it’s late and always some annoying peppy ones because it’s the middle of their morning and they’ve had 7 coffees so far.

Add in cultural differences and that English (or whatever your primary language for communicating is) might not be someone’s native tongue and you are sometimes going to have challenges.

Here then, after acting as scrum master for several months on a distributed team with people in six different locations, three different time zones and two different countries, are my top ten tips to help get past those inevitable awkward silences:

1. Use a lot of questions.
Sometimes it’s not clear where to go next. If you can think of lots of different ways to frame questions, that can help. A question that wasn’t clear posed one way may be more accessible put in different terms.

2. Ask specific people for their view.
Asking, “Hey Bob, what are your thoughts on this?” will usually trigger one of two things: either Bob is going to tell you he doesn’t really understand what’s going on, or he shares the thoughts he was sitting on. Sometimes you might do this several times in a row. So after Bob you could be following up with, “And what about you Sally?”

3. Ask the quiet people.
This is a variation on #2. When conversation is flowing well sometimes the quieter members of a team can be left without a chance to contribute. When conversation isn’t flowing at all it’s often tempting to prod the more vocal members of the team. Instead of starting with the “easy” targets seek out other team members to encourage their contribution.

4. Volunteer your own opinion.
Just because the Scrum Master is meant to be a facilitator doesn’t mean he or she can’t have a useful opinion. Myself I can often hardly keep my mouth shut. I don’t think it’s a bad thing to throw out what you see, what you think should be done and solicit feedback on that.

5. Volunteer a ridiculous opinion.
This may be a bit Machiavellian for some, but I confess I use it myself: “So how about we use to solve ?” If it’s daft enough, somebody will usually be unable to resist telling you why that won’t work…which is the perfect segue into “Well what could we do instead?”

6. Use some humor.
You don’t need to be a stand up comedian and you don’t need to aim for tears streaming down people’s faces and belly laughs. But a little comedy can help lighten the mood and reenergize a meeting. Self-deprecating humor is a good way to go. Especially easy when you’ve got a ton of things like me to laugh at about yourself.

7. Take a break.
Long meetings need breaks. When you’re all sat in a conference room together nobody thinks twice about nipping out to fetch a cup of water. Everyone else can obviously see who’s gone and carry on accordingly or wait for their return if it’s crucial. But when you’re “blind” at the end of a phone I find more structure helps. I either build in a 10-15 minute break midway through a longer meeting or, if I sense things are flagging, ask if people would like to stop for a bit.

8. Switch topics.
There is, as they say, no point flogging a dead horse. If you’re making no headway as team with something perhaps there’s some other useful topic you can pursue together. Something more interesting or less ambiguous than what you were struggling with.

9. Do a mini-retrospective.
You don’t have to save retrospectives for the end of a sprint. You can retrospect on a single meeting or even midway through: “Is this working OK? Should we go about this differently?”

10. Note when people are “done.”
Now I don’t mean “done-done” in the definition of done sense. I mean worn out and you’re not going to get anywhere. Sometimes it’s just time to stop. There’s always another day.

Do you have any more tips for keeping teleconference meetings for distributed teams going? If so please share in the comments.