Accuracy and Precision

Today I got asked what I thought was the difference between accuracy and precision as it pertains to relative estimation, I wasn’t ready for the question though and it’s been sitting on my mind bugging me so here are my thoughts:

I would think accuracy would be how close the estimation was to the truth and precision is how often you predict the same estimation given the same or similar complexity, in other words how repeatable you are. Accuracy is how right or wrong you are and precision is about how consistent you are (irrespective of right or wrong).

So, if you correctly estimate over and over, you’d be accurate and precise but if you estimate incorrectly, but are consistent about the “incorrectness” then you would be precise but not accurate. If you estimate correctly only every now and then for the same given complexity then you would be accurate but lack precision.

Interesting to hear what others think (like if I’ve lost my mind completely šŸ™‚ )…

 

Continuous Improvement

Thinking about continuous improvement the other day I tried to figure out what makes a continuous improvement process work and what makes it stick, these are my thoughts:

  • It should be a slow, gradual process of change, no “sudden movements”.
  • It should be a continuous flow of change, no settling down into a rut.
  • It should be a culture, not a bunch of individuals with ideas.
  • It should be unanimously accepted.
  • It should be measurable.
  • It should be celebrated.
  • It should be evangelized.
  • There should be room for failure, andĀ for success.
  • It should be rewarded.
  • It should be encouraged.
  • It should become defaultĀ behaviour.
  • It should be transparent.

What else?

 

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…

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?

Change is good

I’m often amazed at the number of dogmatic “prophets” out there when it comes to the latest fad’s of agile development. I myself am about getting productive and like to take the best of ALL worlds; change is not only inevitable but necessary, even changing of a process BUT, only if the change leads to improvement! I believe a process of continual introspection and change by a team, combined with a good way of measuring the effect of that change,Ā  is essential for good team performance.

That in mind we made the following changes to the way we practice scrum:

  1. We added a default story to cover recovering technical debt (or refactoring if you will) in that story. Essentially we assign a “story point cap” to this story (say 5 points) that’s based on our current velocity and duration of sprint. We then assign “technical debt recovery” tasks to this story until the team feels there are enough tasks to fill the story points. I know, sounds like the wagon pushing the horse but it’s something we’re trying that other teams have used effectively.
  2. We’ve started estimating (wait for it…) HOURS on tasks. Stories are still broken into story points but the tasks are estimated in “hour blocks” (2, 4, 8, 16) as they are put up. The purpose of this is to act as a type of “sanity check” for story point estimation. An added benefit I found was that the team members seemed to think a lot more about a task when they had to assign time to it.
  3. We’ve started using a round table instead of the tradition square meeting tables. I found this very effective in encouraging participation and collaboration.
  4. Story point estimation was done using a technique I learned on training that speeds up the estimation incredibly (works well with lots of stories). This is how it works (well, how we did it anyway):
    1. All the stories are explained to the team and placed in a pile on the table.
    2. A wall/board is divided into sections, each representing a story amount (we used 1, 3, 5, 8, 13, 20, 40, 100).
    3. Each team member takes a pile of cards and sticks them in the column(s) they believe it belongs, no-one talks or interacts other than with the product owner to understand the story further.
    4. If a team member disagrees with where a card is, he/she simply moves it to where he believes it SHOULD be.
    5. This carries on until all the tasks are done. Remember, the key is NO COMMUNICATION between team members during this process, this has the effect of forcing people to think about why someone made a decision to place something in a particular column, or why they’re moving it.
  5. We’ve started experimenting with TDD and Paired Programming, which seems to be going well.

One additional thing I’m toying with is moving to a more Kanban based board, the team has problems with taking on too much work and I think creating a way of limiting the pulling of work will work.

Finally on how to measure if these changes are effective, well, to be honest I’m not entirely sure. I think the best way is simply to see if the team becomes better at actually doing what they predict they can do while maintaining a sustainable pace and having fun; other than that I guess we wait and see…

I’d be interested to know what kind of changes you brought about in your team and the effect of them (both good and bad), let me know…

Performance appraisals, do we really care?

I often wonder why companies think the current way of doing Performance Appraisals are actually effective (you know, a few times a year, you sit with your manager and he tells you what a good/bad boy you were). For me they’re unnecessary and this is why: Firstly, “appraising” someones “performance” is something that should have the goal of INDIVIDUAL self improvement (for the appraised) in whatever areas he feels would improve his ability to deliver work, it shouldn’t be some blanket template applied to a group of employees (ok, you lot are “Developers” and you lot are “Senior Developers”) but rather a personal negotiated path to improvement. Secondly it should be something that occurs continuously, not a few times a year; self improvement doesn’t happen in leaps and bounds, it happens in tiny steps, learning from your mistakes and building on your successes.

I have a theory though as to why they still occur. Traditional “managers” exist to micromanage and ensure maximum productivity out of employees. Their focus is on creating the “perfect employee” that will obey orders and sacrifice all for “the company” without little or no concern for the employee as a person. What they’ve then done is pawned off the responsibilty of dealing with “human” issues (self improvement etc) to the dreaded Human Resources department, a set of people divorced from the actual work environment of the employee who apply templates to people in order to shape them into a perfect little workforce. What a crock of shit. How about managers step up to the plate and do what they should be doing: creating the environment for people to excel in, helping employees find paths to individual self improvement and backing off and letting people do what they were HIRED to do? Then we can finally get rid of the HR department and bring the responsibility back to where it should be, firmly in the hands of your leader.

But haven’t we always been working this way?

When I was a kid I had a Commodore 64 with a cassette player, awesome little machine with cool games! I decided I had to write my own game, this is where it all started some 25 odd years ago. I decided I would write a “maze-like” game where an “avatar” would navigate through a maze picking various “gems” and scoring points, that was my goal anyway.

I started by skilling myself up in the basics of, well, BASIC (from books and magazines I had), once I knew enough to do the basics I put code to screen and started churning out lines of code, every now and then I would take a checkpoint and verify that everything still matched my goal…

draw the sprite, done, run and check the results, looks cool, figure out how to move it, done, write to code to make it move, done, run the code and see if it moves as desired, bugs!, change the code to work properly, sweet!

Excellent… time for a break, have something to eat and think about if I could do anything better, nah, the results looked good, was working as well as I had hoped.

I repeated this process until I had a working “game” knocked out. Every time I had a problem I couldn’t overcome I would simply change what I wanted, as long as it matched what I ultimately wanted, a (cool?) game with an avatar moving around a maze and scoring points by picking up stuff…

Sound familiar?

My questions on agile processes

Something I have found very interesting in today’s “agile environments” is the adoption of processes.

I’m caught in an endless loop on my thoughts around the place of processes and how they should fit in a team.

Generally processes are put in place in order to protect the team, sort of like a safety net.Ā  Given this chain of thought people should be interested in following the process, and should try following processes as close as possible. At the end of the day, Its almost like wearing a safety belt.

This is where it gets tricky though, in many cases developers, testers or any other team members may not not see the need for this process, they may believe it is more of an impediment than anything else.

How should this be dealt with ?

Should the team be wholly responsible for the decision to keep or lose the process ?

Should the team be educated every time a process is put in place ? ( Its too often I have noticed that people simply follow processes mindlessly)

In true scrum nature it suggests that the team make these decisions. What if some of these processes have been put in place by parties outside of the team ? FurthermoreĀ  these parties that may have a good understanding for the need of the processes ?

So I go back to my safety belt analogy, sure its a pain to put it on, but if you are unlucky enough to be involved in an accident I can assure you that you will wish you had been wearing it. Unfortunately in scenarios like this it seems its only when its to late when one may value the process ?

Another questionĀ  I have is around how often should the necessity of a process be revisited ? Is agile not about constant improvement, about constantly looking at what went well and what could have been done better ?

Here is my take, but please add comments im really excited to hear other opinions on this…

I believe thatĀ  processes should be revisited constantly, possibly with each scrum retrospective, its important to remember when doing this to consider the impact of failing to implemt and follow the process.

If the process is enforced by external party, and you feel that you dont see the need for it, discuss this with the party responsible and try to understand why it is they deem the process necessary, it may turn out that you have already covered the risk that this very process is trying to prevent. After all is this not what scrum is all about ? COMMUNICATION ?

An (agile) environment…

Scrum often talks about “ideal development environments” (Mike Cohn has a nice blog post on this entitled The Ideal Agile Workspace, well worth the read) and this often excludes anything related to engineering (hardware, software etc.), for the obvious reason that Scrum does not profess to offer guidance on engineering practices (but clearly states they are important) but rather on “management” practices.

Anyway, to the point of this post. I have a challenge at my current job in designing a development environment (hardware/software, not physical environment) geared for agile development. I had some high level ideas:

  • Somewhere to play – I figure it’s important for team members to have an area to “play” in, experiment with ideas, test theories, do proof of concept, without it impacting other teams, especially in environments where multiple teams are building toward a common project.
  • Somewhere to build – teams need somewhere to actually construct things, typically this will be their own machine, together with a (decent) source repository to share and control versioning of code. Probably overlaps with their “play” environment.
  • Somewhere to share – Collaborating teams are good teams (if not great teams). Encourage teams to collaborate by not only co-locating members but giving them access to tools to share information (wiki’s, blogs etc).
  • Somewhere to test – Generally I believe there are four “kinds” of testing, integrated into the sprint at various points: developer testing (does my stuff work and have I broken anything), integration testing (does everything works nicely together), quality assurance testing (does everything performs at a predefined “quality” level, this should include, but not be limited to, security, performance, durability etc.) and user acceptance testing (does the product meet the requirements). Each level of testing adds an additional feeling of “warm and fuzzy” and, as such, I believe each of these environments should be clearly separated, demarcated and controlled.
  • Automation – everything that is repetitive should be automated, plain and (maybe not so) simple. There is, however, a small “addendum” to this, in my opinion: The degree of risk determines the degree or automation, the higher the risk, the less the automation. Take for example releasing a product into a production environment, a simple enough task to automate, but can you risk it going pear shaped? I don’t know, am I wrong here? Perhaps this is just a trust/quality thing and if you have enough quality (and confidence) checks in place, releasing to a production environment is a trivial task that CAN be automated?

In line with the above this is what I think would make a good environment:

  • Every team member has his own environment (machine) that is capable or running as much as possible of the required frameworks/tools/databases etc.
  • Where something cannot reasonably be run on a team members machine (think large databases), establish a common “development” environment where a reasonable copy of the system can be run on. Set rules for working on this common environment (typically a team can sort this out amongst themselves). The team has full control of this environment. Possibly virtualize this environment so that it can be backed up/restored/recreated/duplicated easily.
  • Create a shared environment where team members can collaborate ideas, a wiki and a blog are good ideas, hell, even a twitter like setup might be interesting, of course this should not be used by management to track progress!
  • Create a source control environment with a high degree of stability (backups etc) and control. Define solid rules for using this system, retroactively “fixing” a source control system is a nightmare. Some good ideas for versioning/branching can be found here (specifically for CVS, but the concepts can be applied to any decent version control
  • Create an integration environment that is a closer match to the production environment, automate the building of systems to this machine on a continuous basis, giving feedback to team members (via emails/web pages etc). This is the first “gate of quality” for the work being produced. This environment should be automated as much as possible (if not completely), again consider virtualizing for the same reasons as the development environment. Consider this a “sanity check” environment to make sure everyones contributions “play nicely” together. This environment can run all the testing frameworks (although consider also running on the development environment?):
    • Unit testing (and test coverage testing)
    • Code style checking etc.
  • Create a quality assurance environment that near perfectly matches your production environment. Work is automatically “promoted” to this environment if it has succesfully passed all the integration quality requirements. Consider doing functional and non-functional tests (performance, security etc) here (although the integration environment is also a good candidate for this, but the quality assurance environment should be a closer “replica” of production, so more than likely will behave similar to it). This is where team testers will “see” the results of the team, it should be treated similar to a production environment and accorded the same level of “respect”. Members of the team that are doing the physical development must consider this environment as “production”. Remember also to “automate what you repeat” at this point, tests that are run on the system should be automated as much as possible. This is the second “gate of quality” for the work being produced
  • Create a user acceptance environment where business will ultimately see and comment on work done. This is the final “gate of quality” for the work being produced. This environment should be treated EXACTLY like the production environment and code should only be “promoted” to this system, not built. After business accepts on here, the code is “release ready”. Consider automating the process of releasing code to this environment, if possible, however the types and degree of testing that needs to be run on QA in order to promote it to this environment may prevent it.
  • Finally, of course, production environment… but that’s a whole different kettle of fish and I’ll leave that up to more qualified people to build šŸ™‚

Ok, so those are my (perhaps random) thoughts on the subject. Have I left stuff out? Sure, I probably have. Will this work practically? Not sure, I think it should, I’m going to give it a try. Is it “agile enough”? Who cares, it can evolve, change. I think it can work though, with enough automation and enough discipline it should be a decent solution.

I welcome any (constructive) opinions.