Rick Tonoli

A great team

For me agile is about many things but first and foremost it is about people and dynamics between people, you get the right recipe going and anything is possible. I work with what I think is a great team, but what makes them a great team? I’m not entirely sure but here are some of my ideas of traits of a great team (in no particular order):

There’s a good level of respect not only for each other as people, but in each other’s ability to do stuff.
They trust each other.
The team has built in redundancy so anyone can take time off at any time, no silo’d experts.
There’s lots of laughter and healthy tomfoolery, they know when to work, but they also know when to play (at work!).
They allow failure and learn from it, focusing on the problem, not the person.
High levels of collaboration, both at work and at play. They help each other out constantly, no-one is ever “too busy” to help.
They’re cross functional, there’s a good mix of skills amongst the team, helping with redundancy.
Everyone feels they can talk openly about issues and problems.
There is no fear (of failure, of specific people), they take chances and enjoy challenges.
They self organize, there is no one leader, they all lead, they all follow.

There’s more I’m sure, but those are the ones I can think of right now. At the core of it I think people must feel like they belong, that they are respected for their skills and trusted with responsibility and above all treated like people, not resources.

Thoughts?

Velocity for the layman

WARNING:This is a brain dump of an idea I’ve been playing around with, some confusion may occur!

As a ScrumMaster I often struggle to explain the concept of velocity to people, a critical concept to grasp to understand how to report on progress and capability. I often get these questions thrown at me:

How many features can we complete in X weeks? or…
How many bugs can one developer fix per day ?

The danger of these questions, for me, is not so much in the question (which doesn’t make sense) but in what happens afterwards:

1 developer = 1 story per sprint so 2 developers = 2 stories per sprint, right?
1 developer can fix one bug in 1 day, we could double our rate by doubling our people!! or…

So, to the challenge: how to explain the danger is making all pieces of work equal and how to explain the benefits and logical sense of measuring in velocity.

Let’s start with the analogy: You’re going on holiday, you need to travel from city A to city B (your goal) with 5 stops between.

Doing it wrong would be to assume that you multiply the time to the first stop by the number of remaining stops and that would be your final travelling time.

Doing it right would be to look at the distance between each stop, calculate the average speed you can maintain, and then add up the travel time between each stop. Even better would be to:

Adapt your average speed based on environmental conditions. Bad weather, day/night travelling, fatigue, additional rest stops, travelling through mountains? These all affect your average speed.
Keep track of your average speed as you travel, this should give you an indicator of exactly what average you can maintain.
Check what affects the distance between towns like road closures, alternate routes.
Be ready to adapt to changing conditions, like accidents and sudden road closures.

Given the above you should be able to accurately predict when you will arrive at your goal. As a bonus you can also work backwards. Given your need to arrive at a particular time, you can sum up the total distance and divide it by the time you have and this should give you the speed you should try to average.

So, to bring it back to velocity, you average travel time can be equated to the teams average velocity (or capability). Stops are user stories/bugs and distance between cities is the effort of doing the story. Conditions of road, road closures, mountain travelling, predicted bad weather etc is your complexity.

Here’s hoping this analogy makes sense, if it doesn’t please let me know. I still think it’s missing something though so I may add to it at some point…

When will we be finished?

I’m a firm believer that all work should have an agreed end date, but end dates are always a bone of contention and cause endless confusion and wasted arguments and disagreements. These usually hover around the “when will we be finished?” question and, more to the point, no properly defined (empirical) way of working it out.

That in mind I thought I’d lay down the process we use to arrive at our end date. I will also attempt to do this without using the word scrum or agile, not because I don’t like or agree with them, but because those words tend to create predefined thoughts and have a life of their own (unfortunately).

So first the basics: In a nutshell we work in iterations, releasing something (hopefully of value) every 2 weeks based on a prioritized backlog. The backlog is constantly updated as stories are added / removed / completed.

Now for the fun. In order to calculate an end date with reasonable empirical accuracy you need the following: remaining effort and an average effort per sprint / day the team is capable of.

Effort Scale

Effort is difficult to define but key to the entire process. Everyone should agree and understand what is meant when we say “X amount of effort”. What you must realize is that it does not matter what unit of measure you use to define your “effort” as long as:

it is consistently used across all stories
it is understood by everyone
something of effort X closely matches another thing of effort X, for small values of X.
the units should increase roughly exponentially. This is to allow for indication of greater uncertainty with significantly higher numbers. Some people use the Fibonacci sequence (1, 2, 3, 5, 8, 13 …). Also remember to allow for zero effort.

We struggled to settle on our effort scale but eventually had to settle on a time relative scale (for various reasons):

Very Easy (1 point) – roughly a day to complete
Easy (2 points) – between a day and 2
Medium (4 points) – roughly half a sprint
Hard (7 points) – roughly a full sprint
Epic (20 points) – unknown or way more than a sprint

and of course 0 points for quickies.

Effort per story

Assigning effort to stories is an exercise the entire team should do but failing that at least the majority of the team. Stories should also be continuously rechecked to see if the effort is still correct, especially stories with high effort assigned to them.

The process we use is as follows:

Discuss the story
Vote on an effort, if there’s dispute, use the highest of the choices, if there’s huge uncertainty, assign the highest effort.
Rinse and repeat

Remember also to compare stories of similar effort. Another way or form of checksumming is to, during planning, assign tasks to the story (as in what you’re going to do to achieve the story) and then assign a rough hour estimate to do the tasks. Sum up the hours for the story and an equivalent effort story should probably have a similar amount of hours, although this is only really useful for well understood stories.

Average Effort Per Iteration

Calculating the effort per iteration (sometimes called the velocity) is a matter of adding all effort units (points in our case) for all completed stories for a sprint. It’s important to only tally up completed stories or the whole process is pointless. Average effort is just the sum of the effort for X number of iterations divided by X. Obviously the more data you have the better. What we also do is remove the highest and lowest values (as anomalies) from the calculation, to account for those strange iterations (over Christmas, Easter etc.)

Remaining Effort

Remaining effort is simply the sum of all effort that has not been completed.

The Formula

Calculating the end date then becomes the following:

By Day: date today + (remaining effort / average velocity / number of work days in iteration) divided by 5 and then multiplied 7 to account for weekends = your end date

By Iteration: current iteration number + (remaining effort / average velocity) rounded up to whole number = final iteration of work, end of iteration is end date

and that’s it, you’ve predicted a future date based on historical data using a reasonably empirical method. You can improve the accuracy of this estimation by doing the following on a regular basis:

Re-evaluate the backlog from an effort point of view, focusing particularly on high effort stories.
Recalculate your average velocity at the end of each sprint and factor it in.
Factor in holidays and leave into your calculation.

Comments or suggestions welcome

gSouthAfrica 2.0 Day 1

Ok, so gSouthAfrica Day 1 didn’t really grab my interest in the slightest, perhaps the coolest thing I saw was some of the features around Google+ that are either just released (Google Ripples) or planned soon (like the integration with YouTube to add music play lists and share and control these from Plus, although can’t really see a use case for a built in music player in Plus?). Anyway, so besides the funky Plus things coming the rest of Day 1 was pretty much a rehash of last year. The keynote again focused on Google’s plans for expanding into Africa revolving around solving some of the key problems to introducing wide scale technology to the continent. I must admit they are making some nice strides to solving this but are a far way from making Google an everyday name in the dark reaches of Africa.

All in all for me the day was boring, but then all the technologies they spoke about I know on a deeper level already so I expected that. Day 2 (Developer Day) sounds like it could be good though (at least I hope so) and I’m actually looking forward to it…

gSouthAfrica 2.0 Hackathon

Attended the 1st day of gSouthAfrica 2.0 (https://sites.google.com/site/gsouthafrica20/), the second incantation of the Google South Africa conference. The first day was a Hackathon focused on the Google+ API (https://developers.google.com/+/api/) in its current incantation. For me the day was a bit of a let down, the Plus API is severely limited with only the basic ability to read data and even that is limited. There was a bit of a competition with the Hackathon but for me it could’ve been organized better. The turnout for me was also surprisingly low, in the end I did a bit of experimentation with the API and that was ok, didn’t really get to build anything constructive, in fact I couldn’t even think of something constructive TOO build with the API, although this could be partly due to the fact that I’m knee deep in Android development.

In closing a nice idea the Hackathon, next time though, and especially if you’re going to make a competition of it, create a common goal for everyone to do, like a build a particular app that will use a lot of the API. Also, Google need pull their thumbs out of their butts and seriously ramp up the deployment of the Google+ API’s full functionality if they’re hoping to get any kind of value out of it, in fact, I’m almost thinking if they don’t then Plus is at risk of running down the same track as Blackberry… a dead horse looking for a place to fall over.

Let’s see what tomorrow holds, it’s the official Day 1 of the conference, all about Marketing and other such interesting topics 😉 Lets hope they don’t dumb it down too much.

My initial experience of the Viewsonic gtablet

I recently purchased a Viewsonic gtablet (or gtab) and I thought I’d dump some thoughts I had on it for future buyers. Firstly I’m based in South Africa so access to technology like this is, well, lacking. The only “tablet” officially available as of this post, is the Samsung Galaxy Tab (I say “tablet” because it’s more like a rather large phone). I picked up the gtab at a local online distributor and had it shipped as a grey import. The price I paid put it in at half the price of the Samsung tablet.

The specs for the gtab can be viewed on the Viewsonic Site, some of the things that stuck out were:

1GHz NVIDIA Tegra 2 – Dual-core ARM Cortex-A9 CPU – dual core is cool, ready for Honeycomb release of Android. The NVIDIA Tegra 2 chipset is awesome, read up on it at NVidia (Angry Birds flies on this tablet, pardon the pun).
8-10 hour battery life (confirmed), only need to charge this thing every few days.
USB Host, plug in your external drive and away you go, also, plug in a keyboard / mouse and it just works!
Unfortunately (or fortunately?) it comes with only Wireless and Bluetooth (no data or GPS) but, to be honest, I think I prefer it that way, plus you can tether your android phone to it and share it’s GPS and data connectivity (I use an app called Wireless Tether) if needed.

The gtab ships standard with a charger (US plug, luckily I had a converter), USB cable, some (very basic) instructions and a cloth, which doesn’t work so great, buy yourself a microfibre cloth if you’re anal about the screen or invest in a screen protector (I believe there are a few available), although the screen is pretty durable and a good wipe now and then is more than sufficient.

The first thing that struck me as I unboxed it was its wide format (10in x 6.5in) as opposed to the IPad (7.5in x 9.5in) which seemed strange at first but quickly grew on me. It’s designed to be a landscape device, controls at the top right corner. It’s also slightly thicker than the IPad giving the impression it’s significantly heavier (which it isn’t, weighing in at only .05 lbs more). For me the extra thickness gave it a better feeling when holding it and I could grip it better (forgive the porno connotations but maybe this site will get more hits now 😉 ).

Out of the box it requires a 3-4hr charge to full before you can use it, prepare for the annoying wait. Also, the standard ROM is a dog. It’s slow and apps crashed continuously. I strongly suggest you redo the ROM on it straight after charging, I went with the CyanogenMod using these instructions and I was up and running within an hour with a vastly improved experience. Remember to do the Market Fix as well to give you access to the Android Market. After that go crazy and install all your favorite apps, first thing I installed was Angry Birds, simply to see the performance, and it rocked.

There are, however, one or two things I had issues with that still need to be sorted out:

I cannot get the onboard speakers to work (headphones work great)
Battling to get all the supposed supported movie formats to work, not sure why but will give feedback once sorted.
Occasionally the tablet gets “jerky” but I suspect it’s all the rubbish I installed.

Other than that it’s a great device, I’m enjoying using it and would highly recommend it, especially for the price.

I’d be interested to know other peoples experiences with the gtab, and if you know how to fix the sound, please let me know…

Velvet Intimidation and Thuggery

In South Africa you hear stories about people brushing against the corruption of the Police but it doesn’t sink in until you actually experience it. Today I was stopped by a pointless roadblock doing nothing more than harassing innocent citizens, checking for expired licenses, expired roadworthy certificates and the likes.

Unfortunately my car’s roadworthy certificate had expired some months ago (forgot to check it, didn’t receive an update notice) and I was pulled over. Oh crap, I thought, what have I done wrong now?! What happened next was a series of exchanges that can be summed up as velvet gloved intimidation tactic aimed at loosening my grip on the cash in my wallet.

They jokingly threatened to “moer me” (slang for beat up), threatened to impound my car and leave me on the side of the road, threatened me with a massive fine. What the hell? Luckily I had the sense of mind to “just act meek and friendly”, you know, like a beaten dog?

Here’s a (rough) playback of the conversation:

Police (smiling): “Happy New Year sir, how are you today?”

Me: “Good thanks, is there a problem?”

Police: (still smiling): “Yes, your license disc has expired, come look!”

Me (looking): “Geez, I had no idea, I never received the reminder”

Police: “Oh, we’re going to have to impound the car sir (pointing at the tow truck conveniently parked on the side of the road), we’ll have to tow it”

Me: (trying the sympathy card) “What? But I’m on my way to work, I have to work on New Years Eve, all I want to do is get it over with and get home”

Police: “You know the fine is R2500 for this infringement, and we’re going to have to tow the vehicle”

Me: “Come on, do you really have to tow the vehicle? It’s only 3 months expired”

Police (talking to his 2 buddies now, laughing): “Maybe we should moer him? You think we should moer him?”

Me: “Why do you want to moer me? I’m just going to work, want to get the day over”

Police: “Can I see your drivers license”

Me (giving license): “Sure, I think that expires 2013”

Police: “Yes, 2013, I think we should moer you”

Me (realizing what he’s actually after): “Listen, I know what you want, you know what you want, why don’t you just ask me”

Police (to his buddies again): “Maybe he’ll buy us lunch, or maybe we should just moer him…(laughing)”

Anyway, this diatribe went on and on for several minutes, eventually, realizing I think that he wasn’t getting a bribe out of me and not wanting to do the paper work, he waved me on.

So that’s my experience of the corruption in this Banana Republic I call the country I live in and I’m now more determined than ever to get the hell out of Dodge. This country has no future, not when the very people that are supposed to protect it are the same people destroying it…

Star Trek, a model for Agility

As a Trekkie I’m prone to watching reruns of old Star Trek episodes from time to time and I started seeing many similarities between an agile approach to “getting things done” and the way the crew of the Enterprise work. Yes, granted, it’s a militaristic structure but that’s not to say you can’t still be agile:

Crew members exhibit a general knowledge of most fields, with expertise in a particular field (see how well the bridge crew interchange roles during disaster situations where members go down).
Away teams are generally cross functional based on the task at hand, and usually range in size from 3 to 7.
The Captain issues orders (“what”) but relies on the crew member(s) to execute them (“how”), and does not interfere unless further clarity is needed.
There is a deep level of trust and respect between crew members.
There is constant collaboration, communication channels are constantly open from anywhere on the ship (and off).
They celebrate their victories and learn from their mistakes, and adapt as needed.
At any point in time, the crew is working on whatever will add the most “value” to the mission (work is prioritized).
There is an understanding that collaborative teamwork is the way to success.
There is a good work/life balance, even on a Starship.
The crew are passionate about their roles.
Mission planning sessions only plan enough to get the mission going, and are then adapted on the way.

Any other Trekkies out there see similarities I’ve missed?

Google South Africa conference (day 2)

I’m back in Joburg and I figured I better get around to writing a Day 2 post. Day 2 was, for me anyway, not as interesting as Day 1, but nevertheless worth it (it’s a fault of mine that I’m way too technical and not focused enough on “the other stuff”).

It’s focus was mostly around monetizing (Adsense / Adwords / YouTube for Business) and optimizing (Webmaster Tools), and some useful tips came out of the sessions. There was also a rehash of the first days strategy talks (what Google are doing in Africa), compressed and optimized for more business orientated people, as well as a demo on Voice, Goggles and Maps(with a monetization/marketing slant).

One of the things that stuck out for me was the YouTube talk, the stats on video usage is phenomenal, with predictions that up to 80 or so percent of internet traffic will be video within the foreseeable future. Is the internet as we know it dead? I think that as it stands now, and based on those figures, it may not be dead, but will most certainly change in a significant way. Something else I wasn’t aware of was that YouTube had a South African branch, which is awesome, means all those videos are now local traffic for us.

One more thing that stuck in my head was the somewhat corporate way in which Google dealt with the complaints from two people regarding being blocked from Adsense. I’ve personally experienced the automated messages warning against “unsavory behavior” and realize the frustration of trying to find out exactly what the Google checking algorithms consider as “unsavory”, and not being able to communicate with a “human” on the other side, so I know how the must feel. I think people need to realize that Google is a listed company with shareholders, they need to protect their interests and with large volume obviously there’s no feasible way they can treat everyone equally, so they give special treatment to large account holders, it’s just a fact of business. One thing I don’t agree with is the lack of information when you do query a threatening letter, not sure what the Google strategy is here but it’s not really very, well, “warm”.

The conference closed (for me anyway) with a “website clinic” where Google went through some guest websites giving suggestions on what was and wasn’t good practice, an interesting exercise and I got some interesting tips from the session. Unfortunately I had to leave for the airport at that point so missed the last few sessions and, other than dodging a few thunderstorms, had an uneventful flight back.

All in all the 2 days were worth it, connected to a few people, got to meet some Googlers and hear them talk about the interesting technologies I’ve been using. The food was nice, the venue was awesome and Cape Town is still beautiful (wouldn’t mind moving back there). Hopefully they will be back next year, although I think then it should be up in Johannesburg so that they guys up here can experience it as well.

Interestingly enough, the word “cool” was not used at all in this post…

Google South Africa conference (day 1)

Geeks, coffee, sweets and cool music, add that to a lineup of interesting speakers talking about cool technology and you have a recipe for an awesome event. Day 1 of the Google South Africa (g|southafrica) Conference finished a couple of hours ago and it was a pretty cool day. I’ve worked with most of the Google technologies before but still found the conference a wealth of knowledge. It’s always refreshing to see a group of dedicated people speak about something they’re passionate about, and the Googlers are quite passionate about their products.

Day 1 of the conference made it quite clear that Google has big plans for Africa. They’re on a mission to bring the Internet to everyone, making it an integral part of every African’s life, and I think they have a good grasp of the potential pitfalls and problems of dealing with this continent; things like the multitude of languages, lack of Internet access and decent localized content.

What are they doing about it? Lots of cool stuff it seems, like Google Voice, a speech to text recognition tied in with Googles’ search engine, now you can just say what you want and it delivers it to your device and, believe me, what they’ve done with voice recognition technology is awesome. Oh, did I mention it’s in Afrikaans and Zulu as well? Then of course there’s the heavy focus on us (the developers of cool apps), trying to get us entrenched in all the cool API’s they have available, building relevant content for local customers. What’s refreshing is that they recognize that they’re not the specialists on localized content, they’re merely the tool providers, WE’RE the specialists.

Some other cool things at the conference (for me anyway) was Google Goggles (still in beta I believe), let’s you scan just about anything and recognizes and returns information on it (except pet’s and accessories, but they promise they’re hard at work getting that sorted 😉 ), pretty awesome technology (it’s not often you get a room full of techies to applaud spontaneously during a demo!). Another cool technology was the entire Map / Location base suite of API’s ; I’m working on a project currently using these technologies so I am biased towards it’s coolness but what they showed was mind altering to say the least, lots of cool technology to play with.

All in all the conference was awesome, lots of useful tips from the Googlers on getting the technology out there (especially in the mobile arena) and using it in an optimal way (like search optimization), together with lots of cool demo’s of cool technologies.

Looking forward to Day 2 tomorrow… more coffee, more sweets, more awesome…

Oh, in case you’re wondering, I used the word “cool” 12 times in this post…