As has been made clear by a recent visit by Steve Hayes from Cogent, and our other attempts to learn more about agile, there is a thousand ways we can improve. This makes it easy to be stunned, like an animal caught in headlights, and instead do nothing.

So last week, Stephen and I worked out what the next level of low hanging fruit was, and have put together this plan to reach it.

Revisions to our iterations

Over the past couple of months we have been doing extremely frequent iterations of only 3 days coding, and 1 day testing. Whilst we have been able to deliver significant business value during these iterations we feel the time in each release is too tight so we are stretching our iterations out to two weeks.

We are also introducing a few new “events” to each iteration:

Planning Meeting

This meeting will be held on the Monday morning when a sprint starts. During this meeting we will be doing proper developer signups when the developers can choose which user story they wish to work on.

Brown Bags

We already have lunch delivered on Fridays, so the brown bags themselves will be unnecessary. But nevertheless each Friday at lunch we will be allowing time for our developers to share knowledge about code that they have written or investigated.

Show Cases

At the end of an iteration we will be more proactive about showing the new version off to everyone in the company.

Retrospectives

At the end of each iteration, and even more so, at the end of each major new version of our software we will be spending time to understand what we did well, and where we can improve.

A different testing structure

We are moving towards Test Driven Development (more on that later), but will still always need manual testing. We will be moving this forward a day so that we have more time to fix errors in the current iteration, and also to provide us with a proper “release day”.

Hierarchy of Environments

We are going to become more savvy about the level of access we provide to the regular releases of our software. Recently we have found that bugs that we missed during our test day quickly came up when we showed the software to clients, but by then the installer has already been available on the web.

We have previously adopted an approach where for each major release, versions x.0.x (i.e. 6.0.1) were strictly internal, x.1.x (i.e. 6.1.6) are public beta, and x.2.x (i.e. 6.2) is our “stable” version. Instead we will have 4 levels of access (or “environments”, and as a version proves itself it will be promoted between the levels.

As a company we lean towards pragmatism in the given situation rather than strict rules, but here is an example of how our hierarchy of environments may look:

• Developers - There are no limits on what developers have access to. As such, the most recent version they’ll use will come straight out of source control.
• Internal – Once a version has been given at least a day of manual testing by the developer team it’ll be cleared for use internally. We’ll put it on our display machines, and use it when we do visits and web conferencing to get client feedback or do marketing. This way, we’ll hopefully catch any huge errors before they get to our users.
• Beta – After a week of internal use, we’ll make the version available to install from our web site. But with the caveat that it is a beta and thus may not be suitable for organisations with lumbering IT juggernauts. It is still in development after all.
• Stable – After a month in the wild, if we find no problems, we may make the version our officially supported “stable” release.

Organising Jira

We use Atlassian’s Jira for our issue tracking. It has served us well over the years but recently we have noticed that it doesn’t quite fit the way we do software development.

So we are re-configuring our Jira installation (which is remarkably flexible) to fit our needs. Our new structure will support us all the way from when a client first makes a complaint or suggestion, right through the investigation of possible solutions, and down to the instructions we give our developers. There will be a more detailed post on this  later.

In fact, we have already spent the last few days setting this up, and will be testing it on the next release of NEM-Review.

Code Standards & Principals

We’ll be adopting a common set of code standards and principals, to help us work together and also motivate good code.

There are several different forms that this takes.

• Text Structure – Conventions about the naming of variables, and where {‘s sit in relation to function declarations.
• Code Standards – Stuff like using the EventHandler<T> delegate when creating events
• Project Structure – The way we organise projects on source gear to fit into our testing structure.
• Principles – Ideas like “don’t over-engineer” and “sustainable pace”.

At this stage we are more concerned with the items lower down the list.

Estimation

We’ll be assigning maximum and minimum estimates in “story points” to our user stories via estimation poker. Over time we will track our velocity and get a better understanding of how much we can do in each iteration.

Pair Programming

We are going to experiment with pair programming. At first we will just try it on the larger or tricker user stories and see how we go. We will make a determination of how well this works for us after trying it for a few weeks.

In fact, our first experiment with this was just last week.

Test Driven Development

We are moving to test driven development – starting with the next iteration of NEM-Review. After looking at the different versions we’ll be using NUnit for our automated tests, as it is the simplest tool that meets our needs.

Personal White Boards

Today Stephen went over to Office Works and bought us all personal white boards. There is nothing better to create designs and share ideas between developers.

But forget all that. Because I won a prize. I got given all his books. Here’s me with his books with the greatest cheesy smile I could pull:

Yes, I know, your high opinion of Global-Roam has been shattered. You’ll never look at NEM-Watch or NEM-Review the same way ever again. You’re wondering if our figures can be trusted or if we just have a super-computer running a random number generator. You only just noticed our fascination with hyphens when I put three just then in the same sentence…

I only wanted to photograph the books, but then the boss caught me, and next thing you know you have this image to think of every time you ring our support line (don’t worry, if you ring and I pick up, I wont be offended if you ask for Todd).

But really, I’m just trying to be melodramatic so that if Scott Ginsberg has google alerts set up he’ll see this and continue my 100% success rate on getting authors to comment on my blog posts. That’s “Scott Ginsberg” who, by the way, looks like this:

Yes, Scott is insane, and proud off it. He’s also a very good speaker, and wont bore.

Scott is an expert on “approachability.” Hence the name tag. His talk was mostly on creating a name for yourself, and getting people talking about you (basically, creating word of mouth).

There are a few key points that stuck out:

1. Fans are awesome

Rather than creating “customers” or “clients” we should be aiming to create “fans”. People who are fanatical about our company and our products. These people are a far better at advocating for us than anyone else. They also push the hardest to help us make our products and services as good as possible (thanks for the positive pressure).

Global-Roam has a few fans. You know who you are (post a comment to say hello). You are all very helpful in making us better than we could ever be on our own. We appreciate the help, and like to think we are in the struggle to “make the electricity market understandable” together.

As part of our ongoing business restructuring process (discussed here) I have had a promotion-of-sorts and it is now my job to turn our clients of NEM-Watch and NEM-Review into fans. Then it’s my job to manage the influx of input our fans provide. Scott’s talk made me think about my job a little differently.

2. We need to stand out

In order to get word-of-mouth you need to be worthy of it. The only way to be worthy is to be remarkable. This means being different to everybody else.

How can we make people remember our appearances at trade shows, the loading screen of NEM-Watch, or blog posts written by yours truly? How do we create differences, not just in our quality of service but also in our customer’s experience? What would make it fun for our fans to use our products or work with us?

These are key questions. What would make this blog remarkable enough that you’d forward it on to other people?

3. Identity is key

Ultimately, Scott Ginsberg’s talk wasn’t about name tags. It was about identity. As part of this Scott got us to image a world where everyone did what we said and use this to create a “personal philosophy.”

Scott’s philosophy includes:

• “People buy people first”
• “Make the mundane memorable”
• “Fans, not customers”
• “Don’t sell, enable people to buy”

We’re still trying to work out our identity. As you may know, we’ve been on the slow road of changing our company name for some time now (I promise the new one has no hyphens in it), our business cards are ugly, and our company slogan is impossible to remember (something involving 3 “C”s ?). We really need to decide who we are, and then present that image in everything we do.

Are we a bunch of computer geeks who can fix your electricity related issues with magic coding powers? Are we “glorified librarians”? Are we “the NEM-Watch people”?

In Ontario, perhaps we need to identify with our Australianness (yes, that is actually a word).

Whatever our identity is, we need to find it, and work with it in everything we do.

How do you think of us?

That’s all my thoughts about Scott’s talk right now. For more information, you can go to his site here.

Over the years a key part of our book reviews is the “binary review” – a 0 or 1 for if the book was good or bad (we are a bunch of nerds after all). We’re also keen to learn practical ways in which we can directly improve the processes in our business.

On this blog we’re going to post a few of these reviews to give you some insight into how we work. We also have a secret, sinister motive of helping us to think about what we will say before our meeting…

Over the last month (ok, the last 2 days), I’ve been reading A Practical Guide to Selling by Grant Hyman (sorry, no Amazon link but there is this at women’s network). Grant is a well accomplished, Australian marketing guru who learnt his skill the hard way at the “University of the Pavement” and wrote this book to supplement formal education with “a practical and realistic alternative.” (pg 7)

Unfortunately, Grant doesn’t do a good job. The book suffers from two significant barriers to getting a coveted “1” in the binary review stakes.

1. The book simply didn’t tell me anything new. I’d already learnt everything he had to say from other books like How I raised myself from Failure to Success in selling and How to make Friends and Influence people.
2. Even if the book did have compelling content, you’d be hard pressed to find it because Grant simply doesn’t know how to organise his thoughts. This is first revealed when reading the table of contents, the chapters (of which there are 79 chapters, ranging from Auctions to Health to Self-Esteem to Upselling) are arranged entirely in alphabetical order, rather than being packaged into sensible blocks. This leaves the reader lost, bouncing around between chapters trying to find the information they want rather than tidbits of wisdom gained over Grant’s hard life.

Grant simply can’t decide what he wants this book to be. Is it a book on selling, buying, ethics, depression, or on how to live a happy healthy life? The topics and tone change so quickly between chapters it leaves you as confused as trying to understand the allegiances of the characters in Pirates of the Caribbean: At World’s End. The book could have used some series editing and an author that actually knew what he wanted to say.

Ah, I love the internet. It gives us geeks an opportunity to express ourselves much more frankly than if we were talking to someone face-to-face.

So, A Practical Guide to Selling gets a firm Zero, and doesn’t give me anything to say at our meeting later today. Perhaps I could use it as a case study on “How not to order your chapters…”

(For the sake of transparency, we’re signed up to the Affiliates program at Amazon, and any books you buy using our links make us a little richer)