Waste Snakes and Investment Ladders

I have a confession to make. For the last year I have had an obsession with waste. My study of waste has occupied a large portion of my time and I have even been roping others in to help with that study. Fortunately this is not as unhealthy as it sounds as waste in this context refers to the wasteful activities that my team engage in.

Specifically my obsession relates to identifying where we are wasteful and how we can continuously reduce the waste we identify. The end goal of this waste reduction is to allow the team to become more productive by allowing them to focus more time on productive activities like completing user stories.

So what exactly is waste? One definition describes waste as:

An act or instance of using or expending something carelessly, extravagantly, or to no purpose: “it’s a waste of time”.

In the team context my definition of waste is a little different. Here waste is all the things that the team have to do that are not user stories. Customers have not asked for these things to happen but we have to spend time on them anyway.

However, most wasteful activities do have to happen or no sane team would spend time doing them at all. For example, my definition of waste would label release activities as waste. How are we to get the functionality described in stories into production if we don’t fill out forms for Change Management or actually execute the release steps? Alternatively, the same would apply to essential build maintenance. How can we do continuous integration if we don’t maintain all of the changing moving parts of the build and associated tests?

In my opinion just because we have to do these things does not mean that we can’t question how we do them in attempt to cut down the time we consume doing them. In essence when I talk about waste I am really talking about Opportunity for Waste Reduction. Following my “all non-story work is waste” idea gives the following generalised waste examples for my current team:

• Defect resolution
• Support
• Release activities
• Test maintenance
• Working for other projects
• Miscellaneous (everything else)

(When I discuss this idea the most controversial waste example is defects. Some people I talk to don’t think defects are waste and that time spent fixing them should be ranked alongside story implementation time as being productive. However, I believe that if stories are implemented correctly then we don’t have defect fixes to do in the first place. If we strive to reduce defects then we have more time for new functionality. This makes defects wasteful).

The idea is not to eliminate these activities because we cannot – at least not completely. Instead we should strive to reduce the time we spend on them as much as possible.

A Scrum Master will hear about waste all the time in stand ups, retrospectives and general team chat. Such feedback will identify specific wasteful activities. The retrospectives will even furnish you with corrective actions. This is a good start but I wanted to go further and quantify how much time we spent on specific wasteful activities.

I wanted to do this because I did not want to rely wholly on feedback from stand-ups and retrospectives on waste as it may not be the whole story. I suspected that the waste that team members complain about the most may be the waste that is frustrating them the most but may not represent the biggest cost to the team as a whole. For example, one person may be complaining of spending thirty minutes a day fixing broken builds. However, we may also be losing a total of two days a week across the team to bug fixes which nobody is specifically highlighting because it is not frustrating them. Both sources of waste should be addressed in time but the latter is more costly and should be addressed first. If all waste is highlighted on a level footing then we can see where our corrective actions can be most productively applied.

So to quantify the waste we introduced the concept of a Waste Snake.

The Waste Snake

A Waste Snake is a visual representation of a team’s total wasteful activities for a given period of time. The idea is to set aside some wall space and to form a chain of stickies. Every time the team has to do something they consider to be wasteful they write up a sticky and add it to the chain. The longer the snake gets the more of an issue the team can see they have with waste.

Rather then have one long elongated snake I decided to fit our Waste Snake onto a white board and make it more of a block. It loses the snake effect but the team can still see the waste grow over the course of a sprint so it makes a great information radiator. The Waste Snake can also act as a memorandum which can be used to prepare for retrospectives or even as the focus of the retrospective itself.

Click to Enlarge

The advantage of the Waste Snake is that each waste item is represented by a sticky. This means that various items of metadata can be included. For our Waste Snake stickies we include:

• Team member’s initials
• Short description
• Approximate time spent on waste activity

Here is an example following this format:

Click to Enlarge

Metrics

While the stickies take a very short time to write up and place on the Waste Snake their content provides very useful metrics. Each sprint I enter all waste items into a custom spreadsheet including all of the details from stickies. For the waste description I derive a waste category such as “release activity”, “defect”, or “support” and where relevant sub-divide by environment. For example, “UAT Defects” go in a separate category from “Production Defects”. Note that different teams will have different sets of waste categories.

The spreadsheet automatically calculates total waste for the sprint as well as a breakdown by category. It also charts the waste trends across all available sprints. Using this information I and the team can see our top waste areas as well as the ongoing impact on waste of previously implemented retrospective actions.

Looking back at the retrospective notes for the first sprint in which we collected figures I can see that they had an immediate impact. We noted that in that sprint SIT defects were consuming a disproportionate amount of time at forty plus hours and that we were losing ten hours to assist other projects. In response we beefed up our testing standards and instituted knowledge transfer exercises to the other projects.

This process of tackling the biggest sources of waste based on actual metrics has carried on ever since. For example, we have reduced defects through more stringent requirements, speeded up release activities through tooling and our ability to produce new functionality quickly through refactoring as well as dozens of other improvements in all areas. These actions were all driven and targeted by real waste data.

The historical waste figures are also useful as a component in calculating velocity. In fact because waste can potentially consume so much time I believe it is as important a factor in velocity calculations as historical velocity and planned resourcing figures are.

Waste Changes Over Time

At the outset of the Waste Snake exercise I had an expectation that we would be able to drive down waste to a low level and keep it there. This does not happen in practice. I have found that it is possible to drive waste down in one area but it soon starts to grow again somewhere else. This is not due to neglect as one might expect but due to the constantly changing environment that teams work in. For example, the team’s make up can change, the characteristics of their workflow can change and their external environment can change bringing in new corporate and regulatory requirements which must be obeyed.

That is not to say that driving down on waste is futile. It simply means that you are never done with it. Just as agile teams should continuously improve they must continuously drive down on waste in its many new and varied forms.

Waste Snake Alternative

Note that there are other ways to collect waste metrics. For instance, I know of several teams that collect lego bricks in a box to represent waste. For example a single brick could represent an hour and each colour represent a different waste category. As teams carry out wasteful activities they add bricks of the appropriate colour to the box. At the end of the sprint the Scrum Master can count up the bricks of each colour in the box to get waste metrics. They can even build a lego wall of the submitted bricks to take to the retrospective to demonstrate the magnitude of waste and provide a talking point.

Using lego bricks is a good lightweight way to collect waste metrics if you don’t need the extra detail that can go on a sticky. However, for me the Waste Snake is the way to go because of the detail it provides for just a little more overhead.

The Investment Ladder

I have spoken about Waste Snakes but the title of this post also includes the term Investment Ladder. A few sprints after introducing the Waste Snake idea we hit a problem. Team members were doing non story tasks which were actually beneficial. For example, refactoring, attending relevant training and carrying out retrospective actions. These were not stories so the rule was that they should go into waste. This did not seem right as these were positive behaviors.

In fact they were investments that were being implemented to either drive down on waste or to make us more productive. They should not therefore be lumped in with waste. I decided to break the Waste Snake in two and introduce an “Investment Snake”. A team member had a better idea and suggested “Investment Ladder” as the combination of the two mirrors the name of the board game Snakes and Ladders:

Click to Enlarge

Investment is now tracked to the same degree as waste with similar stickies and its own categories (“Release Streamlining”, “Relevant Training”, “Refactoring”, etc) and it also has its part to play in velocity calculations. However, whereas we actively try and reduce waste we actively encourage managed investment.

More importantly team members not only see a growing Waste Snake reflecting their opportunity for improvement but also a growing Investment Ladder that demonstrates all the good things they are doing to improve.

Sprint Retrospective Techniques 2

A year ago I published a post on Sprint Retrospective Techniques that I employ to help my team to continuously improve. Since then I have tried out many other techniques to keep things fresh for the team. In this post I present three more simple techniques I have found to be especially effective.

Technique 1 – The Cool Wall

The Cool Wall is my favourite retrospective technique at the moment as it is not only very effective but also a lot of fun. I discovered it while browsing blog posts on the web looking for new retrospective techniques to try out.  I am a fan of the UK motoring show Top Gear and this technique is based on an occasional segment from the show, “The Cool Wall“.

In the show the presenters Jeremy Clarkson and Richard Hammond decide how cool various cars are by placing pictures of them in various categories labelled: “Seriously Uncool”, “Uncool”, “Cool”, and “Sub Zero”. The show involves audience participation but ultimately the presenters (especially Clarkson) decide how cool each car is (usually overriding the audience).

For the retrospective version of The Cool Wall the cars are replaced by cards that represent positive practices or behaviours that the team engage in. For example, ‘Continuous Improvement’, ‘TDD’, ‘Listening to Customer Feedback’, etc.

The Scrum Master plays the part of the presenter while the team take on the role of the studio audience. For each card the Scrum Master asks the team:

“How cool are we at…<thing written on card>”

The better the team decides they are at the thing written on the card the cooler the category they agree to place it in. The Scrum Master then places the card on the board in the agreed “coolness category”. The most important difference between the retro technique and the TV show (and the reason it works as a retro technique as opposed to as entertainment) is that the audience/team decide on “coolness” not the presenter/Scrum Master.

The technique requires a little preparation. Beforehand the Scrum Master should prepare the behaviour/practice cards. The content should be topical to the particular team and their current circumstances. I also create small voting cards for each “coolness” category to allow the team to efficiently vote rather through the yelling and shouting that happens in the TV show. This also prevents the team from aligning themselves with the first vote that is shouted out.

Click to Enlarge

The next step is to draw the cool wall on a large whiteboard complete with the headings  ”Seriously Uncool”, “Uncool”, “Cool”, and “Sub Zero”:

Click to Enlarge

The session proper can now begin. The Scrum Master produces each card in turn and asks the team how cool they think they are at what is written on it. The team use their voting cards to display their choice. If there are wildly differing opinions on “coolness” then discussion can ensue until some consensus is reached. At this point the Scrum Master places the card on the board in the appropriate “coolness” category and moves onto the next card. Just like in the show it is permissible to place a card between two categories where agreement cannot be reached. This voting and discussion process proceeds until all cards have been placed on the Cool wall:

Click to Enlarge

With all of the cards on the board it is time to move onto the next step. One card at a time the team discuss the things they are “Seriously Uncool” and “Uncool” at doing and identify corrective actions to improve their “coolness” at doing the thing on the card. I tend to write the key points of the discussion and any corrective actions onto the board as we go for future reference:

Click to Enlarge

Technique 2 – Lean Coffee

I have written about Lean Coffee before in reference to the  Lean Agile Glasgow meetups. Lean Coffee is a great technique for democratising meetings which is also suitable for retrospectives. The democracy comes from the team providing the topics and prioritising them for discussion.

While I allow an hour for most retrospective sessions I run I find that a Lean Coffee retrospective session requires up to two hours for a full discussion of the most important topics to take place. It is also the only type of retrospective that I run with the team sitting down as it does not require the use of a board.

The session follows this format:

1. Everyone takes a few minutes to write up one or more stickies with topics they would like the team to discuss in the retrospective.
2. Go through the stickies one by one with the author briefly explaining their question or topic (one minute should suffice for each).
3. Everyone dot votes on the topics they most want to discuss. Each attendee gets three votes to spend – they can put multiple votes on any one topic and can vote for their own topics if they so wish.
4. A Personal Kanban is created with three columns: To Do, In Progress, Done. The In Progress column is WIP limited to 1. Stickies are used to create the headings (see picture below).
5. All topics are placed under the To Do column in priority order according to the number of votes they have received.
6. The top topic is moved from To Do to In Progress.
7. A 15 minute discussion ensues around the topic. A smart phone is handy to do the timing. If discussion around the topic dries up before the 15 minutes are up then progression to the next step comes early. Any corrective actions that are raised during the discussion should be noted down for agreement at the end of the session.
8. The topic is moved to the Done column and the next To Do topic is moved to In Progress.
9. Repeat from step 6 until the session time or topics are exhausted.

Click to Enlarge

Technique 3 – Questions Retrospective

The final technique is the Questions Retrospective. The format involves posing a series of question to the team about how things have gone from their perspective. For example, here are some questions which I have gleaned from various sources and that I think make for a good generalised set:

• What Worked Well?
• What Should We Do Differently Next Time?
• What Did We Learn?
• What Don’t We Understand That Needs To Be Clarified for Future?
• What Made You Mad?
• What Made You Laugh?

You can target specific topics by introducing specific questions to address them, for example, to explore an event, good or bad, that has occurred in the preceding sprint.

Note that while this technique works well for sprint retrospectives I find it to be especially powerful for project retrospectives where a longer period of time is being considered. All of the pictures below were from a recent project retrospective I ran hence the sheer number of answers that were given.

In preparation for the session I send out the questions to the team in advance to encourage as much feedback as possible. In the case of a project retrospective I do this several weeks in advance. I also encourage the team to bring any answers they have pre-written on stickies so that ideas they have before the session are not lost and to speed the session up a bit.

Immediately before the session starts I write all of the questions onto a large white board:

Click to Enlarge

When the team members have all arrived the session can proceed:

1. Explain the meaning of the questions to the team and provide any necessary clarifications so that everyone is on the same page
2. Encourage the team to place stickies with their answers under each question
3. Wait until everyone has posted all of their answers. Team members can post as many answers to each question as they like
4. Go through each question one at a time
5. Have the team group similar answers to the particular question together into common themes
6. Discuss each grouping one at a time identifying and recording any corrective actions

Click to Enlarge

You Can Never Have Too Many Techniques

Keeping retrospectives engaging, and therefore effective, requires constant work on the part of the Scrum Master. Having a static set of techniques, however tried and tested they may be, is not enough and we have to keep innovating. I find I have to constantly seek out new techniques to accomplish this. Fortunately Agile practitioners are a generous bunch and new techniques are constantly being published on their blogs.

I have not been taken with every technique I have read about or gone on to try out and frequently make my own small adaptations to those I do use to increase their effectiveness for my team’s particular circumstances. This amounts to quite a lot of work but the rewards in the form of continuous improvement are worth it.

Perhaps in another year’s time we’ll see the publication of Sprint Retrospective Techniques 3.

Managing Retrospective Actions

In my previous post on Sprint Retrospective Techniques I outlined several approaches teams can use to identify corrective actions to drive continuous improvement. However, I have learned from experience that identifying corrective actions in a retrospective is only part of the battle.

To ensure that the team get the full benefit from their proposed actions they must be appropriately managed. Without such management valuable corrective actions can get lost or unnecessarily delayed and the team can lose faith in the retrospective process. The end result can be a stalling of continuous improvement which is a disaster for an agile team. This post outlines a couple of measures I take to effectively Manage Retrospective Actions.

Agreeing the Actions

The starting point for retrospective action management is in the retrospective itself. If the session has been successful then at the end there will be a set of corrective actions that have been identified by one or more team members. The Scrum Master should go through each action in turn to confirm that the entire team agrees that it is valid. A valid action is one that will improve the team’s productivity without incurring undue cost. Reviewing the actions reinforces their importance and gets everyone in the team in agreement that they are worth implementing.

You may find that the team cannot agree on which actions are worth doing. If the debate hits an impasse then dot voting can be used to break the deadlock. Dot voting can also be useful if there are too many corrective actions for a team to handle. The team can use dot voting to prioritise the most important actions for short term implementation. Lower priority actions that the team does not have the bandwidth for can be dropped for now. Do not worry about losing them as, if they have value, they will crop up again in future retrospectives when they may be more viable for implemention.

Retrospective Actions Board

At this point I have seen teams create stories for each of their actions that then go into the product backlog. I don’t do this because the actions are not stories at all. They are instead things that the team can do to make the business of implementing stories quicker or easier. They can represent documentation, changes to process, improved tooling and so on. What they are not is functionality for the end user. They should not therefore be prioritised with stories.

However, the corrective actions need to go somewhere or they may be forgotten and never implemented. As I believe that retrospective actions are so important and their implementation can be so crucial to a project’s success I make them as visible as possible using a Retrospective Actions Board:

Click to Enlarge

A retrospective actions board is just like a physical task board except the cards on it hold the agreed retrospective actions rather than stories. Actions that have not been implemented reside in the To Do column, those in flight are in the In Progress column and those that the team have actioned sit in the Implemented column. As the unimplemented actions sit right in front of the team every day they cannot be forgotten. In addition everyone can see what actions have been done. This means that the team can see real progress towards their own continuous improvement.

It is one thing to make the actions visible but how do we ensure that they actually get picked up? It is up to the Scrum Master to reinforce the message that any team member can pick up a retrospective action for implementation. After all the team agreed on the actions because they all believed that the actions would make the business of implementing stories quicker, easier, simpler, would result in less bugs, etc. There is therefore nothing wrong with a team member improving the team’s ability to do work by implementing actions while at the same time others carrying that work out by implementing stories. Initially the Scrum Master may have to get involved to ensure that the balance between actions and stories remains optimal. Having a WIP limit on the In Progress column is one way of doing this. However, a self organising team will find a productive balance very quickly and such intervention will rarely be necessary.

Electronic Retrospective Actions Tracking

The Retrospective Actions board is a powerful information radiator for continuous improvement but it is not the whole story. In addition to the physical board I find it informative to keep an electronic history of the actions a team agrees. I do this because with a steady stream of implemented actions the Implemented column on the board will quickly fill up and need to be cleared down. The history of what the team has achieved is then lost. In addition the history can record meta data about actions such as when they are identified, when they were implemented. I call this Retrospective Actions Tracking and it is represented by a page in the team’s wiki:

Click to Enlarge

The tracking page is a permanent record of every retrospective action that has been agreed and its current state. The colour coding indicates actions that are waiting to be implemented (red) or have been implemented (green). I also record the sprint retrospective in which the action was agreed and the sprint in which it was actioned (if applicable). As you can see all of the team’s sprints are named after (good) beers. It is also interesting to record in sprints how long it takes the team to make good on the actions (Sprint Lag). If a successful team ever needs a reminder of the importance of retrospectives and of their progress towards improvement a quick review of this page will reassure them.

The tracking page is also useful for identifying actions that are not being carried out. If an actions sits unimplemented for many sprints after it has been agreed it is worth asking why. It could be that the action is blocked. A blocked action is no less an impediment to the success of the project than a blocked story and may require the Scrum Master’s intervention to facilitate its removal. Alternatively you may find that the action is simply obsolete and that the team no longer believes it its implementation to be worthwhile. In this case, and with the team’s agreement, the action can be removed from the tracking page and the physical actions board.

Action Post-Implementation

Finally it is important to come full circle at the next retrospective. The Scrum Master should review the Retrospective Actions Tracking page prior to the retrospective to see what actions have been implemented in the last sprint. They should use this information in the retrospective to celebrate the team’s continuous improvement success at the same time that completed stories are celebrated. This reinforces to the team that they are making good on the agreed actions just before they identify another set. This helps keep the flow of actions coming.

Summing Up

Retrospective actions can sometimes be neglected. I’ve done it myself with a previously held and incorrect belief that actions would just get done because they were obviously important. However, it is not as simple as that. The actions need to be thoroughly agreed, made visible, their completion actively encouraged and their successful implementation celebrated. Only with these steps in place can a team make the most of the great ideas they have in retrospectives.

My Agile Kit

Over time practising Scrum Masters tend to accrue a kit of stuff that helps them carry out their role. When it comes to planning, estimation, retrospectives and creating and maintaining information radiators such as physical task boards then having a stock of certain props and consumables makes life much easier. I call this collection of useful stuff an “Agile Kit”.

The items that any particular Scrum Master possesses in their Agile Kit will differ but the core items will probably be the same for most: whiteboard pens, markers and stickies. Effective utilisation of these items depends on having an appropriate amount of accessible wall space usually in the form of one or more whiteboards. In my opinion those who attempt to perform as a Scrum Master using electronic aids alone is missing out on the advantages of a tactile and highly visible work environment. Nothing creates more of a buzz within a team then seeing stories move from left to right through the task board.

Most of the items in my Agile Kit take the form of the contents of the drawer of my office desk. It was only recently I collected it all together in this one single easily accessible place. I was surprised by how much stuff I use, much of it every day, to carry out my role. However, use it I do so I thought it would be of interest to others to present the contents of my Agile Kit here.

This is basically a post about stationary which may not seem like an important Agile topic. However, I find that when Scrum Masters get together and the discussion turns towards how we do our jobs we talk about the little details including the raw materials we use to build our boards and run our retrospectives. I have picked up more than one tip or trick that has added to my Agile Kit and assisted me in my role as a result of such discussions.

Here is a picture of my Agile Kit:

Click to Enlarge

Each item pictured and its purpose within my kit is described below.

Top row, left to right

Click to Enlarge

Planning Poker Cards – I have several decks of these including the set I made myself. The others were picked up during conferences and training. I find the cards to be a very useful prop for sprint planning despite the current wave of “estimation is a waste”.

(The planning poker process is an excellent structure within which the team and Product Owner can have a conversation about a story to get on the same page while getting a swift estimate for the customer. Estimation is not a waste if you know why you are doing it and can do it quickly. Either extreme, be it lengthy estimation or no estimation at all, should be questioned).

Electrical Tape - I use electrical tape to create swim lanes on task boards. In minimal time I can use the tape and some scissors to create clearly defined, relatively straight and durable swim lanes on a whiteboard. If you have a magnetic board and want to be really fancy then do as one of my colleagues does and use magnetic tape for swim lanes for guaranteed straight but moveable lines.

Masking Tape - Masking tape can be useful when board space is at a premium. For example, to temporarily attach flip board paper over a task board to create a quick and dirty retrospective space.

Stapler – The stapler comes in handy for permanently attaching extra pages to the back of story cards. I use these extra pages to add details to a story that do not fit on the front of the card. I predominantly do this to attach hand drawn wire frames of the screen that a story is to implement. I find that this is much quicker to do and more convenient to access than an electronic equivalent.

Magnets – I have an abundance of large magnetic whiteboards at my disposal at the moment and make extensive use of them in concert with magnets. I tend to prefer to use magnets rather than stickies for anything that may be in place for more than a few days or needs to be moved around a lot. For example, story cards on a task board.

Middle row, right to left

Click to Enlarge

Stickies and Super Stickies – Stickies are an obvious addition to any Agile Kit due to their flexibility and high availability in most workplaces. I use them predominantly for our Waste Snake and retrospective actions boards and in retrospective sessions. They come in many colours and sizes which can be used to discriminate between different types of “thing”. I tend to stick with standard yellow and resort to making marks on the stickies themselves to discriminate between them. The only problem with stickies is that they tend to fall off surfaces after a limited amount of time. This is okay when they are used in a short retrospective session but unsuitable for a more permanent Waste Snake or retrospective actions board. This is where Super Stickies come in. They cost a bit more but will stay stuck to a whiteboard indefinitely even after being moved repeatedly.

Scissors – If you get creative with your boards then scissors are essential for cutting tape or paper to size.

Story Cards (6″x4″) – I prefer to use white 6″ x 4″ sized card for story cards rather than smaller stickies. The cards are attached to the board using magnets. These are big enough to easily fit several detail in in large legible writing which can be read at a distance. Our story cards typically display the story name, release name, tracking number and, if the story is being worked, the appropriate team member’s avatar is pinned to it.

Envelopes – As releases are completed I collect up the story cards and keep them in separate envelopes labelled with the relevant release name. This is not simple hoarding as the cards and their stapled attachments contain many useful details on the original requirement. Myself and the team will infrequently delve into the envelopes to refer to these details after the stories have been implemented and released to production. For example, when investigating related defects or customer queries.

Blue Tack – I occasionally end up in meeting rooms with non-magnetic white boards and want to be able to attach story cards to them. Having blue tack is handy for these instances.

Paper Clips – We recently adopted a Kanban practice of having small avatars for each team member (we used South Park characters). As team members pick up stories they pin their avatar to them with a paper clip. This is a great visual identifier that adds to the status information conveyed by the task board.

Highlighters – Highlighters are useful for identifying important pieces of information on story cards and their attachments and for adding status marks to the front of story cards.

Sharpies – I find that permanent sharpie pens are excellent for writing clearly and legibly on story cards and on stickies in retrospectives.

Whiteboard Markers, Eraser – As you will have gathered by now my role revolves around the various whiteboards at my disposal. As such I have a large stock of white board markers and an eraser handy to make full use of this resource for retrospectives, the various information radiator boards and for the frequent spontaneous brain storming sessions members the team engage in.

Bottom Row

Click to Enlarge

Magic Whiteboard – This is great stuff for creating a small whiteboard using unused wall space. It attaches by static so causes no damage to walls. It is useful for quick brainstorming or retrospective sessions but not as a permanent whiteboard replacement as it only sticks reliably for a day or so.

Not Pictured

Smart Phone – This is not pictured but I find that having a Smart Phone is convenient. I use it to take pictures of the retrospective board after the retrospective session is complete. The pictures then form the basis of the post retrospective communication including any corrective actions agreed by the team. This is more convenient than a regular digital camera because I can mail the images directly to my work email making images available for use immediately.

So that’s my Agile Kit. What do you have in yours?

WMR200 Weather Station

Towards the end of last year I wrote a three part post about my new Oregon Scientific WMR88 weather station (part 1, part 2, part 3). While the installation was successful the setup was not completely reliable. I concluded the final post stating:

“If I am serious about logging and publishing my weather station’s data I will have to invest in some better kit to minimise gaps in the data. I have my eye on the WMR200 and may purchase one next year. The WMR200 has a built in data logger and a hefty looking external antenna which unlike the WMR88′s internal antenna I can, if necessary, modify. Also it should be possible to use the same suite of sensors simultaneously for the WMR200 and my existing WMR88 base station. This means that I can have two operational weather consoles and a set of spare sensors.”

Six months ago I did exactly that and purchased an Oregon Scientific WMR200. The idea was to compliment, rather than replace, my existing setup. This post details my experiences with this new weather station. Note that in this post I tend to compare the WMR200 with the WMR88 so you may want to read my original posts on that first.

Buying

The WMR200 currently retails for £400. However, Amazon, Weather Shop UK and Oregon Scientific themselves tend to offer the unit at up to £120 cheaper from time to time. It pays to be patient and wait for such a deal rather than pay full whack. I ordered directly from Oregon as they had the cheapest price at the time.

Unboxing

When the WMR200 arrived the most striking thing about it was how much bigger it was boxed than the WMR88:

Click to Enlarge

Then again you get a lot more with the WMR200 to help justify the extra cost. Pictured below are most of the package’s contents:

• PCR800 Rain Gauge with rain filter
• THGN801 Temperature and Humidity Sensor
• WGR800 Wind Sensor (Anemometer & Wind Vane)
• STC800 Solar Panel
• USB Cable for connecting the base station to a PC
• Batteries for all sensors and the base station
• A mounting pole in three sections, base, rope, fasteners and stakes for ground mounting
• Cable ties
• Various brackets U-bolts and screws to allow for other mounting options

Click to Enlarge

The remaining contents are the WMR200 base station itself and its power adapter which are shown below:

Click to Enlarge

The included kit allows for a lot of flexibility as to how the sensors are installed, more so than the cheaper WMR88. All sensors bar the rain sensor can be placed together in a single array using either the supplied pole or an pre-existing one. Alternatively sensors can be distributed across separate locations using the supplied brackets. For example, attached to fences or buildings. The supplied pole which, in combination with the supplied ropes, fasteners and stakes allow for the option of a ground mounting which  gives substantial height to the sensors.

Sensor Installation

I had already installed a mounting pole for the WMR88′s wind sensor so used it and the supplied brackets to install the wind sensor (pictured top), solar panel (pictured bottom right) and temperature/humidity sensor (pictured bottom left) together in the same location:

Click to Enlarge

The WGR800 wind sensor supplied with the WMR200 is the same as the one that comes with the WMR88. The curious thing is that the WMR88 manual states that its wind sensor transmits a signal every 56 seconds while the WMR200 manual says signal transmission occurs every 14 seconds. Certainly each station updates their displayed wind readings at the stated intervals. Clearly the longer display interval on the WMR88 base station is a limitation of the base station rather than the wind sensor which transmits more frequently.

The THGN801 temperature/humidity sensor that comes with the WMR200 is shielded unlike the THGN800 that came with the WMR88 (I had built a shielded housing for the THGN800 which I can now decommission). While the THGN800 had clearly been superseded it was not completely obsolete. I simply changed its broadcast channel from 1 to 3 and moved it into a room in the house so I could see readings from there (as detailed here I had already installed a THGR810 sensor on channel 2).

The STC800 solar panel is a nice addition as it helps to power the WGR800 and THGN801 and will hopefully save on replacement batteries. It has two cables attached to it which can be plugged into each of the aforementioned sensors. The connections look to be well insulated and the supplied cable ties can be used to attach the power cables firmly to the sensor brackets.

I had no cause to replace or move the existing rain gauge as the same rain sensor is supplied with the WMR88 and WMR200: the PCR800. The bonus with the WMR200 is that you get a rain filter in the form of a fine metal grille to place in the gauge to catch debris. I have placed this in my existing PCR800. See my previous post for details of the PCR800′s mounting on the side of my shed.

In summary my current sensor setup now comprises:

• THGN801 for outside temperature/humidity
• WGR800 anemometer & wind vane
• STC800 solar panel to help power the THGN810 and WGR800
• PCR800 rain gauge
• THGR810 for temperature/humidity in the garage
• THGN800 for temperature/humidity in the house (placed in a different room from either base station to compliment their readings)

All of the sensors now in place are compatible with both the WMR88 and WMR200 base stations. As the sensors simply broadcast both base stations can receive data from all of the sensors.

This hybrid setup has also provided me with unused backup sensors for both wind (WGR800) and rain (PCR800). Given the extortionate cost of replacement sensors these are handy items to have in case of failure in one of the original sensors.

Base Station Installation

The WMR200 base station is a super-charged version of the WMR88 capable of doing everything the cheaper unit can do and more. First I will cover the similarities between the two before looking at the differences.

Like the WMR88 the WMR200 functions as an internal temperature and humidity sensor and as an air pressure sensor. The WMR200 has an optionally backlit LCD display similar to the WMR88. The WMR200 also features the same clock synchronisation feature as the WMR88. Both units can be powered from the mains and be loaded with backup batteries.

The WMR200 displays the same information as the WMR88 (temperature, dew point, humidity, wind, rain, pressure, UV, historical highs and lows, forecast, moon phase and current time) but its larger screen means that it can display more of this information at the same time. For example, the WMR88 can only display one set of temperature and humidity readings at a time while the WMR200 can display the internal base station readings and the readings from a selected channel simultaneously. The WMR200 can also display rain, UV and atmospheric pressure readings at the same time while with the WMR88 you have to cycle between the values. This makes it possible to review the current conditions at a single glance.

The WMR200′s screen features a resistive touch screen rather than the physical buttons of the WMR88. This makes the operations of cycling between sensors, checking highs and lows, etc far more intuitive. Unfortunately the WMR200 has preserved the WMR88′s annoying feature of beeping whenever the touch screen is pressed. This again cannot be switched off.

The WMR200 also functions as a data logger. However, Oregon Scientific’s included software remains as useless as ever so accessing the stored data is nigh on impossible. This is not an issue for me as I now use an external data logger connected via USB (more on that in a future post).

The WMR200 supports up to 10 channels and therefore up to that number of temperature/humidity sensors while WMR88 only supports 3 channels.

Below is a picture of the base station mounted to a wall (easily accomplished as there are mount points on the back):

Click to Enlarge

The final advantage of the WMR200 over the WMR88 is the external antenna. Oregon Scientific’s wireless weather stations are famously awful at reliably picking up remote sensors. I did not expect a great improvement with the WMR200′s rather tiny antenna but at least it gave me scope to apply simple modifications to improve performance which I could not hope to accomplish with the WMR88′s internal antenna.

So is the WMR200′s external antenna more reliable than the WMR88′s internal antenna? That is difficult to say. What I can say is that it is far from perfect. My first site for the WMR200 was less than 10 meters from all sensors with an internal wall and brick wall inbetween. This location gave intermittent signal issues. A complicating factor was that this location was also my office and contains my laptop and router. I suspect that these may have been responsible for some interference with the signal.

After a few weeks of experimenting I had moved the base station into the upstairs hall which gave it almost line of sight to the sensors via a window. This took the interior wall out the equation and eliminated any interference from electronic devices. The new location experienced less signal drop-outs but did not cure them completely. I then implemented a simple modification by attaching a metal radio aerial to the existing antenna using a bulldog clip:

Click to Enlarge

Since the base station move and my simple modification I have experienced minimal signal drop outs. Specifically, a few weeks apart and lasting no more than 5 minutes. This is more than acceptable for my purposes. Getting the best from the WMR200 appears to be a combination of closest location to sensors, line of sight to sensors or minimal obstacles, minimal electronic interference and putting more metal in the air.

I have attached my data logger via the supplied USB cable to the WMR200 through the wall. The WMR88 has been relocated to the living room downstairs for display purposes. Handily this means that I can now check the current conditions without changing floor.

On the subject of the data logger I have installed a SheevaPlug running Meteohub weather server software. I will detail my experiences with the data logger in an upcoming post. For now it will suffice to say the SheevaPlug/Meteohub combo is a nice piece of kit that is easy to set up and is feature packed.

Summing Up

I am happy with the WMR200 now that I have it working reliably. The antenna issues make it far from plug and play and any prospective buyers should be prepared to put a lot of effort into minimising signal drop outs. In hindsight I would have bought a WMR200 in the first place rather than the more basic WMR88. On the other hand, I find the flexibility of having two base stations to be the perfect setup and an advantage of having a wireless as opposed to a wired weather station.

Incremental Release Planning

Release planning for a Scrum project can be a tricky proposition. The project’s stakeholders justifiably want some early predictability as to when individual releases are likely to be delivered. I frequently see teams attempt to accommodate this by tackling their project’s release planning in one big up-front meeting. Having one release planning session for a whole project’s deliverables can leave the team feeling that they have offered up no more than a very rough guess based on scant effort and consideration. The result can be a release plan that the team do not believe in.

For the last six months I have taken a different approach. Rather than having one big release planning session I have spread the exercise over several short sessions using a visual technique. I did not come up with the technique. A team member briefly described it to me in passing after attending a Scrum course with Martine Devos. I have added my own refinements over time to evolve those initial rough details into an effective working practise, the details of which I present in this post. In lieu of a better title I will refer to the technique as Incremental Release Planning (IRP).

The idea of IRP is to have several sessions, each of which plans out one release. This allows the team to concentrate on estimating one batch of (probably) related requirements at a time. The individual IRP sessions are short meaning that the overall time spent on release planning should be roughly the same as for a single monolithic meeting.

However, there is a gain in that the estimates should be of higher quality provided certain prerequisites are met. The good thing about these prerequisites is that the responsibility for fulfilling them falls, for the most part, with the Scrum Master and Product Owner and not with the team members. This leaves the team free to get on with the business of producing working software.

Crucially many IRP sessions can be held over a short space of time. In my experience planning 4-6 weeks of work can be planned comfortably every 2 weeks or so. Before long these sessions cumulatively provide a complete release plan made up by informed, considered estimates. Estimates the team believe in.

Prerequisities

Listed below are the prerequisites I find are required for IRP to operate effectively:

1 – Quality Requirements. The requirements must be fleshed out. It is impossible to provide accurate estimates to one-line stories whatever technique you use for planning. The Scrum Master should work with the Product Owner and/or Business Analysts to get each Story’s requirements into a suitable state for planning.

2 – Stories Grouped into Releases. The project’s stories should already have been grouped roughly into releases and an implementation order for the releases should have been decided. It is the Product Owner’s responsibility to do this (with the Scrum Master’s support) as the exercise represents a form of prioritisation. Depending on the outcome of any particular IRP session stories can, of course, be moved between releases.

3 – The Team’s Velocity. It is difficult to have an up-front release planning session without an idea of the team’s velocity. The same is true of any individual IRP session. Before the first IRP session the team should ideally have carried out several iterations of work and the Scrum Master should have an idea of their velocity. As the IRP sessions proceed so will the sprints. This will lead to a more accurate idea of the team’s velocity over time.

4 – Team Review Time. The team should spent some up-front time reviewing the stories before each IRP session. The Scrum Master can organise this by sending out the list of stories to be planned prior to each IRP session (perhaps a week beforehand). This step is crucial if the session is to proceed quickly. As a process gate I ask immediately prior to an IRP session if everyone has reviewed the requirements. If any person has not then I terminate the session and request that they do so before we reconvene a short time later. Unsurprisingly I have only had to do this once at our first session.

5 – Availability of Product Owner. The team will inevitably have questions around the requirements. The Product Owner and/or Business Analyst must be available to answer these questions quickly for the session to proceed smoothly. The Product Owner must also be available to make decisions around prioritisation changes.

6 – Availability of the Scrum Master. The Scrum Master runs the IRP session moving the team through the steps, keeps the session flowing and, where necessary, stops the team and Product Owner from getting bogged down in the details.

The Steps

With all the prerequisites fulfilled the IRP session can start. For materials you will require a whiteboard and cards filled out to represent each story.

I have illustrated this post with pictures taken at during one of our typical IRP sessions which proposed 12 stories for a release.

Step 1

The first step if to divide the board horizontally into three sections: Small, Medium and Large. The core mechanic of IRP is in the relative sizing of stories. Note that at this stage of the session that there is no mention of story points or velocity. These concepts feature towards the end of the session.

Click to Enlarge

Step 2

Next request that the team place each of the cards into one of the Small, Medium or Large columns depending on their perceived relative size to each other. What the Scrum Master wants to encourage here, and throughout the session, is for the team to collaboratively decide where each card should be placed.

Click to Enlarge

I tell the team to get stuck in at this point and make it clear that all team members have free access to the board. This tends to get the cards placed quickly and also provokes discussion between individual team members and between the team and the Product Owner. Do not move to the next step until some level of consensus is reached on the placement of the cards. However, make it clear that the placement is not final should any intractable disagreements take place.

Click to Enlarge

Step 3

Next the board is divided again, this time vertically, into three more Small, Medium and Large sections. The idea is to further divide the initial three levels of granularity by another level providing nine slots in which to distinguish the relative size of the stories. The team should now redistribute the stories – this time over all nine slots.

Click to Enlarge

This will no doubt result in yet more discussion and closer questioning of the requirements as the team attempts to distinguish between the stories in terms of effort, complexity and uncertainty. The Scrum Master should facilitate these discussions until, again, consensus on the placement of the cards is reached. Note that at this point it is perfectly valid for stories to move from any one slot to any other should the team change their mind on relative sizing as they compare stories and tease out requirements from the Product Owner.

Click to Enlarge

With the refined placement of stories agreed, ask the team to verify it quickly comparing the stories in each size section with those that are immediately smaller and bigger. Cards may be moved again as they deem appropriate. Note that in this example we did not require all nine sections (here we used only eight) to get a granularity of relative story sizes that the team was comfortable with.

Step 4

It is at this stage that story points are introduced to the process. Each section on the board now contains a set of similarly sized stories with the smallest stories in the top-left section and the largest in the bottom-right section. The idea is to assign a story point value to each story section and therefore to each story.

Click to Enlarge

We currently use the following story point values: 1/2, 1, 2, 3, 5 and 8. However, the technique is adaptable to any range. I start by asking if the stories in the smallest, top-left section are a 1/2 story point. If so I write 1/2 in that section and move on. If not I ask if they are 1 story point and so on. In this example the team chose 1/2. I then move to the stories in the largest bottom-right section and ask if they are 8 points. If they are I write 8 there, if not I ask if they are 5 point stories. In this example the team chose 5. I then turn to the second smallest section and ask if these stories are 1/2 pointers or 1 pointers (roughly the same size or roughly twice the size of the smallest stories). I then turn to the second largest section and so on.

This process continues, working towards the middle, until all of the story sections are assigned points. I then ask the team to cast their eye over the proposed story point estimates to verify whether or not they are happy with them. If they are then the Product Owner and team can be dismissed for a while. If they are not we can move individual cards until the team is satisfied.

Step 5

The Scrum Master can now total all of the individual story point estimates to get a figure for the entire release. For this example we have:

1 story x 1/2 SP= 1/2 SP

3 stories x 1 SP = 3 SP

1 story x 2 SP = 2 SP

4 stories x 3 SP = 12 SP

3 stories x 5 SP = 15 SP

Total: 32.5 SP

Combined with the team’s sprint velocity of, in this case, 14 story points, we get the following calculation for the sprint duration required to complete the release’s work:

32.5SP / 14 = 2.32 sprints

Our sprints are two weeks long which gives us a release work duration of 4.64 weeks. I tend to round up to the nearest week which gives us an estimate of five weeks for this release.

Step 6

Armed with an estimate the final step is to validate it with the team. The team’s buy-in to the estimate is crucial. To get this buy-in the Scrum Master reconvenes the team (but not the Product Owner) and informs them of the estimate in weeks. As transparency is important the Scrum Master should also detail the process by which the figure was calculated. The Scrum Master then asks the team if they think that the estimate is reasonable, i.e. do they think they can complete all of the release’s work in that time?

I do this using the fist of five. If anyone votes with a one or two then some discussion can take place as to why they are uncomfortable with the estimate. If the responses comprise threes, fours and fives then the IRP is over and the estimate can be provided to the Product Owner and be incorporated into the full release plan. Should the date prove to be disagreeable to the Product Owner then they can move some work between releases and see the impact that this has on the forecast date. With all the of the figures available this kind of what-if analysis is straight forward. Note that any such changes should be verified with the team to ensure no dependency issues are introduced by reordering stories.

Sprint Planning and Actuals

Note that the IRP estimates do not in any way negate the requirement for sprint planning. This still needs to happen at the beginning of each sprint and I do not make IRP estimates available at this time. All stories must be re-estimated as a lot may have changed between the IRP and the sprint when the work is to be done. However, the IRP assists with sprint planning as the team have seen all of the stories before and have discussed them together. I do, however, compare IRP time estimates with the actual time taken to complete releases as it is interesting to see how accurate IRP is against actuals. The reason I believe so firmly in this technique is that, so far, estimates have been fairly close to actuals (plus or minus 1 week for 4-6 week releases).

Summing Up

IRP is a technique that has worked well in our team. While we cannot provide one big release plan in a single hit we have been able to provide regular release plan updates from early on in the project which prove to be reasonably accurate. Repeated IRP sessions have quickly led to a complete release plan early in the project’s life. I have found these sessions can be run very quickly with 4-6 weeks worth of work being planned in just 30-40 minutes

The IRP technique does require some preparation from all parties. However, the preparation effort in terms of requirements definition and team review pays dividends later when the stories are actually implemented as nothing about the work is a surprise to the team.

New Owner Wanted for KeyStore Explorer

“Owner wanted for a ten year old freeware key management application that answers to the name KeyStore Explorer. KeyStore Explorer is fun and rewarding to maintain, has a clean codebase and comes packed with utility. However, this mature application still has a lot of potential for a new owner to add useful functionality. KeyStore Explorer’s author can no longer take care of it and so KeyStore Explorer requires a new home to get the love and attention it deserves.”

Okay, so KeyStore Explorer (KSE) is not an old dog looking for a home. However, it does require help if it is to continue to evolve.

Since KSE went freeware it has become increasingly popular. With more than 1,500 downloads every month I like to think that it is helping lots of folks out. However, it pains me to admit that, after ten years of development, I am no longer the best person to look after KSE. this is because I no longer have the time to maintain it, far less drive it forward.

What I do not want is for KSE to die a slow death because I am not prepared to let go of the helm. So I am using this blog post as an advertisement to attract a new steward for the utility. I am open to ideas as to what type of ownership this would entail although open sourcing the application seems a logical choice which I am in no way opposed to. Continuing the application as a freeware application or commercialising it are other (less attractive) options that have occurred to me.

You may ask why I don’t just open source it myself. Well there are two reasons. Reason number one is that open sourcing and simply casting the application to the void is not enough to ensure the application’s future. I believe that there has to be a defined owner or owners to take charge of its direction. Reason number two is that there are a couple of impediments that will need to be overcome before the codebase is open source compliant. These impediments are not trivial but nor are they, in my opinion, insurmountable with the current availability of open source alternatives.

You may get the impression from the paragraph above that I just want to chuck the codebase at a willing participant and walk away. What I propose instead is that I provide the successful applicant(s) with the following:

• The full codebase including the mostly complete, unreleased version 4.2 features.
• Licenses  for all supporting tools and third party libraries.
• Ownership of the existing lazgosoftware.com domain for long term use or as a means of redirect to a new home for KSE.
• My ongoing support via email with any questions regarding the application and codebase.

All I require, as the original author, is that my name remain associated with KSE.

If you would like to be the new owner of KSE and think you can do the application justice then drop me a line at the Lazgo Software contact page. We can talk details and I will endeavour to answer any questions you may have. If a deal is struck I will post the outcome on this blog.