Keeping standups smelling nice

My team has recently grown much bigger. I decided we needed to make sure our daily standup stays productive and happy and smell-free.

 

Actually I quite like the smell of stinky cheese. Mmm, cheese.

There’s loads of reading to be done on how to do this – just google “scrum smells”. Here’s my advice. I’m pleased to say my team is doing most of this pretty well. I’ve been in some horrific standups in my day, so I’m pleased to see it working well, and I’d like to keep it that way.

 

My top points for avoiding a smelly standup:

 

1) Don’t talk to the Scrum Master!

 

He doesn’t care. Well, he does, but this isn’t a report to Sir. It’s an update to the team. If only the Scrum Master is interested, tell him afterwards. If what you’re saying isn’t of interest to the team, stop talking.

 

Practice making eye contact with team members. They’re nice people! Probably.

 

2) Listen.

 

Following on from the above – when someone’s talking, it’s for your benefit. Make an effort to understand how it fits in with your work.

If it’s about “server stuff”, this is a great time to learn about server stuff; you might be working on it next week.

 

3) Stay concise.

 

My team is good at this, actually. But it’s easy to ramble off the track. We have to remember that it’s an update, not a problem-solving session. We’re lucky enough to be co-located, so we can easily carry on a technical conversation after the standup’s done.

 

4) Be prepared.

 

If nothing else, check the scrum board five minutes beforehand and make sure you know which tasks you’ve been working on, and what you could pick up next.

 

If the tasks don’t match reality, change them, either before or after the standup. Adjust estimates. Add new tasks. Check with someone before making big changes, but the board should update reality as far as possible.

 

If you’re going to miss a standup, tell someone on the team what you’ve been doing, so they can speak in your stead.

 

5) Everything else.

 

Here’s some links with more words on, some of them are interesting:

 

http://martinfowler.com/articles/itsNotJustStandingUp.html

http://www.mountaingoatsoftware.com/agile/scrum/daily-scrum

http://techportal.inviqa.com/2012/04/02/agile-smells/

Firefighting no more

There comes a point in a software project where the developers swap their keyboards for hoses, their chairs for fire engines, and their scruffy shirts for full-on protective gear and a nice shiny yellow helmet. Yes, it’s time to go firefighting.

It doesn’t always happen, but I bet pretty much every programmer has experienced it. Usually, it’s just before the first big release of something. Your product’s been specced out and dev tested, incrementally developed, and the product owner is delighted. Then, a week before it goes live, someone notices something nasty. They look in more detail – it doesn’t meet the requirements. They notice some bugs, and a security flaw nobody’d thought of.

Back to the team, interrupt the current sprint. Each bug is urgent, some are really complicated. People start talking in low, urgent voices. The fix to the first problem has raised some others – functionality needs altering. The team probably switches to Kanban for a few days, or a few weeks, or a month. Each one coming in is triaged, assessed, and
jumped upon.

This is firefighting – not developing, just stopping it all falling apart. Any fix will do if it works (the smarter teams will at least log Technical Debt tasks, I hope) but we have to get this out the door, so man the hoses and get firefighting.

Not cool

So, what’s the problem? It’s that this type of work is not good. We joke that for every fire we put out, we make two more – dark humour, because it’s actually true. We’re making technical debt. We know very well that this situation was avoidable (exercise for the reader: ten ways to avoid firefighting).

Real life firefighting, however, is brilliant. It’s done by brave women and men who put their lives on the line, usually because of someone else’s problem. Firefighters are cool. They’re fit, and sexy. We all want to be firefighters.

But we’re not firefighters. What we’re doing isn’t saving kittens from car wrecks or toddlers from house fires. We’re doing something monotonous, pointless, wasteful, avoidable, and ultimately, if we don’t get out of it soon, futile.

Mole-whacking

From now on, the term “firefighting” is banned. What we are doing is *mole-whacking*.

Whack those moles all you like, there will be more. And nobody will be impressed.

Yeah! This is fun!

There’s no such thing as …

I’ve just flown home from an excellent holiday in Austria. It is always a wonder to me that we can pump a steel tube full of people and highly combustible fuel and fling it into the air, landing safely (almost) every time. What an amazing feat of engineering and human endeavour!

It was particularly surprising given all the odd things that happened along the way.

It started at the check-in desk. “Are you open for check-in?” I asked, in standard Tourist English. “Yes,” the man smiled, “we’re open now.”

I heaved my suitcase onto the scales, put my passports down on the desk, and waited. The man typed something on his computer. I coughed. He made a quick phone call.

“I’m sorry,” I said, “but you said you were open?”

“Oh,” he replied, “yes, but we’re not OPEN open.”

Ten minutes later, our bags have disappeared and armed with boarding cards we walked to security.

“The trays are just under the desk,” said the security guard.

I looked. “Um, they’re not there. I can see the guy bringing them over.”

“Well, they’re there. They’re not THERE there. But they are there. Now take off your belt.”

This is difficult to decipher from a burly guard in an Austrian accent, but I managed it. We boarded without incident, but as we were taxiing to the runway, the hair on my neck began to stand up.

“Flight deck to cabin crew,” came the voice over the intercom. “The runway is clear, repeat, our runway is clear. Stand by.”

There was a shuffling behind me, and I turned to see one of the cabin crew leaning over to peer anxiously out of the window. Her face was a perfect professional mask, carefully hiding a high degree of panic. She grabbed the intercom.

“Cabin crew to flight deck, there’s a flight coming in to land! The runway is not clear, repeat, the runway is not clear!”

“Ah, it is clear,” came the voice from the flight deck. “It just isn’t CLEAR clear.”

Well, we survived the flight, and on Monday morning, I was of course delighted to return to work after the dreary monotony of the beautiful Austrian Alps under an unbroken azure sky.

I quickly got myself up to speed on our latest projects. Within an hour I’d been called into a progress meeting with my boss.

“So, Al,” he asked. “The latest feature the team’s been working on. Is it done?”

“Of course it’s done!” I say confidently.

“… but it’s not DONE done.”

The Scrumweasel

Rules of the Scrumweasel

• The Scrumweasel sniffs out Weasel Words.
• The Scrumweasel says nothing – just looks at you with its beady little eyes.
• Only you know if the Scrumweasel is looking at you.
• No team members should acknowledge the Scrumweasel.
• The Scrumweasel is not interested in your excuses – even if they’re perfectly valid.
• Keep the Scrumweasel happy – just don’t make eye contact!

Beware the Scrumweasel!
Nobody knows, in truth, where the Scrumweasels comes from. Some say they are drawn to the positive energy created by a team trying to succeed in the turbulent world of Agile development. Others believe they feed on the remains of abandoned Post-It notes.

Imprinted in the Scrumweasel’s brain are the Rules of the Daily Scrum. Just as a pig can hunt for truffles and a chicken lays eggs, a Scrumweasel understands the three questions that each team member must answer:

1. What did you do yesterday which advanced the project?
2. What will you achieve today?
3. What hurdles stand in your way?

Their highly developed noses sniff out Weasel Words in the Daily Scrum. Words such as:

• “Nearly done” (which means “not done”)
• “soon”, or “probably later today” (which means “tomorrow”)
• “I’ll see what’s on the board” (which means “I haven’t looked at the backlog for a while”)

Upon hearing Weasel Words, the Scrumweasel does not react – at most, it will glare at you for a while. It’s not interested in your excuses, of course – even if they’re valid.

But if the Scrumweasel turns its eyes on you, then you – and you alone – will know.

It’s difficult – nay impossible – to avoid the Scrumweasel’s gaze entirely. But you can keep it placated. Try some of these:

• “This task is not yet done. I still have to do the unit tests. It’ll be done by lunchtime.”
• “This task is not yet done. I’m stumped. Can anyone help me?”
• “By the end of the day I will have finished the coding, but not the testing.”
• “I’ll pick up the logging bug, if it’s still available.”

There’s always room for improvement – the Scrumweasel understands this – and it visits good teams as well as bad. Ultimately, just like a little whiskered Avatar of Agile, it hopes to inspire us all to be just a little bit better than we were before.

See sharp learning curve

Working with a new company presents a million subjects which would be great material for a blog post. From the trivial (when to go for a coffee, and how often) through the important (differing implementations of agile development) to the absolutely vital (what’s the least ironing I can get away with without seeming scruffy?).

For now, I’ll stick with uncontroversial. I’m largely worrying about learning a brand new language. I’ve finally made the jump from C++ to C#.

Our new project gave us the opportunity to start a fresh code base; using C# was an obvious and clever move. Despite being much younger than C++ it’s more of a “grown-up” language; still providing flexibility whilst removing some of the painful tedium.

It’s been barely a week since I hit the coal face. Here are just some of the things I’m getting to grips with:

• “internal” keyword. It smells nasty … but it sounds so useful! I’ve used it, but it makes me feel dirty. Sure, it’s better than “friend”, but does that make it OK? Rabbit poo is better than cow poo, but they’re both still poo. When is it acceptable, and when does it just break patterns?
• Unassigned objects are still null. OK, the compiler will catch it, but “MyObject object;” will not be useable without either assignment or a null check. Why? Do I really have to type “MyObject object = new MyObject()” every time? Isn’t this the common case?
• … although the whole concept of null in C# is pretty handy. Gets you 90% of the useful functionality of having a null pointer in C++ with a fraction of the pain.
• System.CollectionsGeneric, and specifically List<>. For better or worse I’ve been in the habit of habitually using std::vector for everything under the sun in C++. Is List<> better? I guess so, but I don’t yet understand the differences with any real subtlety.
• “using”. Namespaces bring back bad memories of Python. I suppose they have a purpose, but I’m not yet familiar with them. What do I need to be “using”? It’s never clear; with “include”, you can be confident that if you want to use the Starbuck class you just need “#include starbuck.h”.

None of these things are criticisms of the language – more an expression of exasperation. I think I’m coping well though – I’m pleased to finally be making the transition, and it shouldn’t be hard to get up to speed.

Ask me in a year’s time and I’m sure I’ll understand more – and also some of the many Rumsfeldian “Unknown Unknowns”. I lack the knowledge to even ask some of the questions.

But that’s good. Like a scarred, leather-clad Carthaginian warlord, turning up to the first ever Atlantean Annual, I’ve got a lot to learn – but half the fun is in finding out just what it all actually is.

There’s things I can do to be more confident in my learning. An emphasis on unit testing, for example, or encouraging more functional and automated testing in all aspects of our new project. I could go on to talk about the advantages of comprehensive code tests & reviews for a new starter, or for fluid development roles within a team more generally … but maybe that argument can wait for a week or two.

Enduring Change

“Nothing endures but change”, wrote Heraclitus in around 500 BC. I doubt he anticipated modern software engineering practices, but the man had a point. Teams change, requirements change, products change. Our process as software engineers must also change. We talk of “Agile development”, which conjures images of responding to outside change – but our practices themselves must also be constantly reviewed, to cope with external changes as well as to strive towards perfection.

Heraclitus also wrote: “You cannot step twice into the same river; for other waters are ever flowing in”. In my case, I’m stepping out of one river and into another. Tomorrow is my last day with my current employer.

I’ve been here for 11 years, which at the same time seems like forever and no time at all. It’s been a real pleasure working with my excellent colleagues. I’m proud of what we’ve achieved together – we’ve made some really cutting-edge software. I’ve played a small part in the process of revolutionising scientific discovery (and made some pretty pictures along the way).

I’ve been writing this blog in order to put my own opinion out for discussion, and I see no reason to stop now. Talking about stuff is the first step towards changing; discussing the last river can help us anticipate the next.

So, what do I hope my colleagues will do after I’ve left?

• Communicate. Talk more, consider everything, let nothing be so sacred that it can’t be discussed. I don’t mean argue (although a good argument, well managed, can be a good thing). I mean, challenge current behaviour. Talk about it in chatrooms, in blog posts, in the kitchens, in the pub. Come up with new ideas and write them down. Get people invested in a product and its processes.

“Opposition brings concord. Out of discord comes the fairest harmony.”

• Be adventurous. We’ve done our best work when we’ve stuck our necks out. Talk about it first … then do it.

Nobody gets excited by blandness. Choose not to do things because they are easy, but because they are hard (and I bet Heraclitus never anticipated the moon landings).

• Don’t be good enough. That’s not good enough. Be good.

Writing software to a list of specifications is not sufficient. Do you have a list of checkboxes, features which your software must have? Don’t do that. It leads to software which is described as “functional”. The stuff that gets given away free with hardware.

Think instead: Is this good? Will the user be pleased? Will they laugh at their colleagues when they complain about inferior software? Will they barely notice all your hard work, because your software just does it right? That’s good software.

Well, if nothing endures but change, then all art is transient. My own opinions are just a voice from the past to my colleagues, so ignore them or consider them as you will (I’m sure you were going to anyway).

It just remains for me to thank everyone who’s been reading this blog, and listening to my meanderings, for your time and attention. It’s been great having a platform, and I encourage you all to do the same.

Talk; take risks; be amazing. Cheerio!

 

Jenga Methods

Jenga has its time and place. It makes a great drinking game; we’ve played it (dry) at a recent Company Mandated Funtime day outside the office. I’ve played a brilliant variant involving improvised storytelling and poetry (better than it sounds).

But it’s a rubbish game to play in conjunction with computer programming.

The fun of Jenga is the anticipation. It’s going to end in disaster (especially the drinking variant, natch). With each turn we hope our brick will balance perfectly, and that another player’s will not. There’s some skill involved, but ultimately it’s about waiting for someone to make a mess of it. Then follows laughing, pointing, and occasional appearances of that “Loser” hand-on-forehead thing (depending on company).

Working with old, legacy code brings with it the spectre of Jenga Methods. This concept has been around in the programming community for literally hours (at time of writing), and we came across one such Jenga Method during our Bugs Postmortem session this morning.

The method is old, long, and complicated. It’s also vital. It’s responsible for displaying almost all of our images, in dozens of key customer-facing parts of our software. It’s called many times a second and without it our application wouldn’t function.

This weight of expectation is felt by every developer who has touched it over the past ten years. It’s grown more complicated, full of comments and convoluted logic paths. Each developer has made the minimum changes to fix the problem, then held their breath, waiting for the wooden blocks to fall.

A logic path contained an error that was uncovered in our last sprint. The developer fixing the problem fixed the error, but didn’t touch the rest of the method – a Jenga player touches one brick at a time.

This isn’t great in the short term, and it’s terrible in the long term. The method needs refactoring, rewriting and redesigning. This is a difficult task that’s always made easier with a comprehensive suite of unit tests, covering all the expected functionality in all circumstances.

You can probably see where I’m going here – we don’t have that suite. The method isn’t covered. Just typing that sentence makes me nervous. Why not? There’s some complications, of course. The method deals with rendering images, although that’s not the killer – the objects are such that we could pass in dummy images and render them to a dummy context.

Rather, the unit test framework just doesn’t exist for that part of the software. It’s something we just “haven’t got round to”.

So … no happy ending, not yet. The best we can do is accelerate our unit test coverage; add the mechanisms for unit testing this bit of code; and add tasks to our feature tracking system to make sure we refactor this code when we can feel confident to do so.

Today, it’s just one more brick on top of the tower. Careful, now.

 

Bugs and Unit Tests

We’ve started running a “bugs postmortem” on some of the bugs we’re finding in our software. The aim is to stop similar situations arising again, and identify any weaknesses in our process which are allowing these bugs to slip through the net.

We talked about one earlier today when we were returning an incorrect statistic from certain types of analysis. I think this started failing when we changed a defined method in an obscure and distant header.

When discussing what could have been done to prevent this bug, I said that proper unit tests covering this number would have spotted the problem as soon as it arose. This is quite true.

However, I then started talking about the test infrastructure we’d need. We would need mock images, I said, and a library of customer data to draw upon. Then we could run the  whole analysis and spot the problem. Building up this infrastructure would take time, I said.

Shortly afterwards, it occurred to me that I was missing the point. The problem wasn’t in the whole software module; and our software is not one massive black box to be tested.

The problem lay within one very specific method in one file. We could (should!) have had unit tests to cover this method. It’s much easier to do; we can create a dummy object, then pass in a selection of inputs, and check the resultant output. No need for images, or anything more complicated, because we’re testing on the level of a single unit of code.

That’s the big difference we must get our head around – automatic testing of a whole module is difficult, but adding a unit test to cover a single, simple, clean method is pretty easy.

With a comprehensive set of unit tests, problems like this would rarely arise, and be quickly fixed, leading to better software, and less frustrated developers.

Epic Win

Our recent release is still ringing in our ears – and I must say it still seems like a good ‘un. Everything went smoothly, before, during and after. We’ve had a load of positive feedback, and seen a record low number of bugs and complaints. All in all, well done us.

Now that’s out of the way, we’re trying again with Story Points. To do this, we need to have a good idea of what a Story is, and why we should use it for planning and estimating future work. Here, I ramble on in an attempt to make sense of the concept, with the help of spreadsheets and Battlestar Galactica.

What is a User Story?

A Story describes an enhancement in functionality, from the perspective of the user.

So is a Story like a functional specification? Not quite. We’ve built up our own way of writing specifications over the past few years. A spec should be concise; it should describe a problem, and outline a solution; it should be clear and descriptive, as well as being a living document.

A Story sounds like it should be too vague to be of use, but I think the opposite should be true.

It should start from the perspective of the user. Fill in the blanks:

•  – “As a user, I want to … so that I can …”

This keeps us focused on tasks that actually add value – if we can’t finish the question, we shouldn’t be doing the work.

A Story might describe a tool, perhaps, or a one-trick dialog. Let’s take an example:

•  – “As a user, I want to change the colour of numbers in my spreadsheet, so I can visually identify important columns and totals”.

This sentence doesn’t say anything about the implementation. Should we have a dialog? Toolbar? Brain-computer bluetooth interface, as seen in the Dr Who episode Bad Wolf? These are important design decisions, and should be considered and written down:

• – There will be an item in the Tools menu, labelled “Change Colour of Selected Numbers”
• – This will bring up a dialog which looks like this:

… and so on. Here we define behaviour at a carefully defined level. Not too much detail, but enough to convey the spirit in which the story is written.

Epics and Themes

Stories should be small, and so multiple, independent Stories come together to make an Epic. There’s no reason to assume an Epic should be completed in a single sprint. For example, we might want to consider the Implement Llama Font Story to be part of the Look Pretty Epic, which reads;

•  – “As a user, I wish to manipulate the look of the numbers in my spreadsheet in order to clearly convey statistical anomalies to third parties.”

And similarly, multiple Epics come together to make an overriding Theme:

•  – “As a user, I wish to visualise my data in innovative ways in order to clearly and effectively convince prosecutors of my innocence for the fraud of which I have been convicted.”

This hierarchy keeps our mind on the ball. If a decision needs to be made, and it’s not clear from the Story’s description what we should do, we can consider the dilemma in terms of the Epic framework, or even the overriding Theme, all of which are descriptions of how we can help the end user – the customer.

The terminology is a powerful metaphor; one with legs, I think. Let’s consider a Story, Theme and Epic from a rather different source:

• Story: Starbuck shoots down a Cylon Raider, salvages its systems, and flies it back to Galactica.
• Epic: The Battlestar Galactica protects a civilian fleet from multiple Cylon attacks.
• Theme: Stranded humans seek Earth.

How does the Story impact upon the Theme? Well, it’s not clear at first; but it certainly advances the Epic, and when considering the details it becomes clear – without the Raider, Starbuck could never have retrieved the Arrow of Apollo. Obvious.

In the same way, changing the colour of a few numbers can never clear an accused spreadsheet-fiddler of fraud, but together with a whole bunch of other stories, it gets us in the right direction.

All Is Not Lost

We can implement a last-minute approach to mapping out Stories; it’s clear that Number Colour is more important than Llama Font, so the details of that story can wait for a week or two, Similarly, we decide the most important Epic, and fully define the most important Stories within it.

And here is the fundamental difference between Lost, and the far superior Battlestar Galactica remake – BSG was an Agile development, whilst Lost was not.

On the face of it, the production of both had Agile features. They both engaged in last-minute script writing, responded quickly to user feedback, and each episode provided more value (entertainment) to the customer in an incremental way.

But while Lost (arguably) had an overriding Theme or two, it lacked anything at the Epic level. The producers have recently (finally) agreed they were making up the Stories as they went along. Black smoke? Yeah, cool! Magic numbers? Great idea. But this is the televisual equivalent of developers adding the features they want to write. Add sound effects when your spreadsheet updates? Great, but where’s the value to the customer?

If we can get a grip on why we’re writing user stories, we can keep in our mind what we need to implement; when we need to do it; and how everything we do is advancing the user’s experience of our software.

And, just maybe, defend humanity from Cylon raiders, while we’re at it. (Next time: How Agile methodologies can help a Cylon Centurion buy a pint of milk from the corner shop.)

Floored Thinking

Like many others around the country, I spent the recent bank holiday weekend attempting a spot of DIY. And as I knelt on Monday afternoon, cradling the still-warm corpse of yet another terminally mis-jigsawed section of wooden flooring, I calmed my sobs and began to consider how I could turn around my DIY failures.

In my head, I took chalk to the still-unpainted wall and drew a scrum board. Post-it notes fluttered across; user stories popped into my head: “A visitor wishes to walk across the floor without spraining her ankle …”

Of course, I didn’t do this. I didn’t need a sophisticated engineering methodology – I just needed to be much better at DIY.

Step away from the power tools

Back at work, I’m a much better software engineer than I am a carpenter. That’s not saying a lot, but I have a dozen years of experience under my belt, and I’ve poured some of my best work into our products. And there’s plenty of room for improvement.

Developing our implementation of Scrum and Agile matters not a jot if our programming skills slide. One way the two might work well together is code reviews. We’ve talked about implementing a team-wide formal code review system, but never actually tried it. And unlike many of our recent innovations, I have been far from enthusiastic about attempting it.

A great idea

Why? After all, on paper, it’s a great idea. There’s a bunch of tools available to make it easy – we can put our code up for review by the whole team, who can add comments and spot any potential problems. The less experienced can learn from the more; while the more experienced can spot opportunities for improvement in our own code as well as each others’.

Our progress in other aspects can be reviewed, too. As we try to clean up and refactor our code, we can consider best practices amongst the team, and look for more opportunities to simplify and improve our code base. As time goes on, we’ll leave behind a trail of improved code, as well as developing important skills now and for the future.

As I say, on paper, it looks great. So why have I been so reluctant to try it?

Back to the floor

Let’s go back to my new flooring. I know I’m no great DIYer, but I put a lot of sweat, tears and blood into my hallway (the stains will come out with time). It’s mostly flat, runs almost parallel with the skirting boards, and hardly creaks at all. I’m proud of it, and when someone comes to visit, I want them to say, “Gosh, what an excellent new floor! You can hardly see the hammer dents!”. The last thing I want is a professional builder to come round and snigger at the edging.

And with the code I write, more so. I should be writing perfect code all the time – I certainly shouldn’t be introducing bugs, smelly hacks, or unnecessary complexity. My ego can just about handle the fact that my flooring is on public view, but it would prefer, at work, to be pouring its output, safe from prying eyes, into a thick, black, sealed box containing only my code.

My code?

And there’s the key point – my code. A key facet of agile development – indeed, any good software development environment – is that the code is not my code, it is our code. At a simplistic level, the company owns all my output, but more importantly, what I produce is something that we as a team have committed to.

Communal code ownership, and its sister, horizontal feature assignment, are things we have been striving to achieve in our Agile aspirations. It remains, however, difficult to assign ownership of my code – perfections as well as flaws – to the team. And yet, if I want to get the most out of code reviews, be they formal or informal, it’s one power tool I’ll just have to learn to master.