Story Cards 2.0

A while back I was exploring some other options for story cards. In a previous blog, I mentioned that making it super easy to create stories was not necessarily a good thing.

So, I bought a few things and started some experiments.

My first cut of this was to laminate a card, the idea being that I could re-use them. 1 pack of A6 lamination pouches later and I had something that looked pretty good!

The first stumbling block was what to write on them with. In my first cut, I used OHP marker pens which are 'semi-permanent'. I eventually found out that meant they could be wiped off with a damp cloth - which sounded perfect! Or so I thought...

Version 1.1 - getting there!

The problem is that OHP markers smudge like crazy. My test bunnies complained that they ended up with black smudges over the cards and their hands.

"Can't we use sharpies instead?". Hmmmm.

After a bit of Googling, I found that standard sharpies can be wiped of with Isopropyl Alcohol - useful to know if you have habit of writing on whiteboards with them! Having a bottle of this kicking around the office did not seem like a good idea but I found you can buy Isopropyl Wipes pretty cheaply.

So we have now have a re-usable card and something to write on them with and wipe it off again. In my experiments, I also found chalk pens were a viable option but they don't come in black so it would depend on your card colour. I like both sharpies and chalk pens but sharpies win since we have tonnes of them laying about the place. Chalk pens are a bit pricey but are hard to rub off once dry.

We started with just using good ol' fashioned Bluetack to stick these to the board but I hated the way they often ran out of stick and then fell off, so I looked for an alternative. I have experimented in the past with Scotch Restickable Dots which are pretty good but also eventually run out - they can also be too sticky, making it hard to move things.

We started by using magnets which worked great but looked terrible - you obviously need a magnetic board, which might be a problem. After a bit more Googling, there have clearly been many innovations with magnets since I was a lad - I found rolls of self adhesive magnets, which could be cut to size. This allowed me to make the cards self sticking by adding these to the back:

Self Sticking magnetised story cards

So now we have stickable, movable, re-usable, templated story cards. I created a few in different colours to denote different work streams and the team started using them. We also used the magnets on the avatars and our other icons we use to show items that are blocked, paused etc.

By making the cards 'hard' to create we can easily tell what we planned to do and what we decided to add to our board during the sprint. We can then use this information in the retro and find out what is wrong e.g. prioritisation, support issues, emergencies, rogue work items.

A side effect of the cards being hard to create means that there is a finite stock of them - you can't keep adding them. This got absorbed into our process and we try to get the stories as small as possible so we can re-cycle the cards during the sprint for another story - the side effect of which is that the work in progress is also limited.

So there you have it, story cards 2.0 - have you tried anything similar?

Agile or just common sense?

A while back I was at a sort-of reunion with some people I used to work with at a previous company. Most of the people there had gone their separate ways and were doing new and exciting things.

One girl that was in my team had gone freelance and was working as the lone wolf on a project that sounded pretty cool.

"Much better than that agile s**t you were making us do".

How encouraging, nice to see I make a difference. I was intrigued, so I asked a little more about what she was doing.

She started by explaining how she worked with the customer.

Each week she had a regular meeting with the customer where she showed what they asked her to do last week.  They often took her work and played with for it for a bit, giving her some feedback on bugs or problems. If it did what they wanted then they would make it live and start using it.

Hmmm. That sounds familiar.

Then she explained how the customer would give her work based on what they wanted it to look like and a bit of background on what they were trying to achieve. She would then work out what she thought she could do in a week and agree it with them. She would talk about this at the same weekly meeting.

Hey, that sounds familiar too.

She said the work was a mix of front and backend work, essentially taking data out of a database and providing visualisations for that data. She was enjoying the mix of work and because it was just her it was easier to provide estimates or suggestions that she felt she could stick to.

That's spooky. I'm sure I've heard something like that before.

How about managing the work? Backlogs etc, how does that work:

"Nah, we talk about that stuff when we meet each week. They have a list of stuff they want to do but I just work on the one they are in a tizzy about."

Interesting.

So, I asked about the changes she was making. Where these big pieces of work - how does she fit these into each week? She focused on changing a specific bit based on what they said they wanted to achieve. Each weeks work didn't tackle the whole idea but just something specific that worked towards it.

I asked why she did it that way:

"I wanted to show progress so I wouldn't have problems when I charged them for my time each week. We agree what they are going to get and I show them that work a week later - I don't want any hassle and I work from home so this is great for me, I don't want to f**k it up!"

No arguing with that. These sound like the perfect customers! She was pretty quick to respond:

"God they are a pain! They change their minds all the time. Each week, we seem to go further and further away from what they said they wanted. Each week they have a new 'idea' that I have to work on!"

Definitely hitting a 9.0 on coincidence meter now. I'm sure I've heard this before.

Despite her previous remarks, if we ran a check list of the agile manifesto she would have been following the ideas of the manifesto 100%. As an 'agile hater', I pretty sure this was not her plan!

Each thing she did was to solve a problem for her customer. To her, the approach was just common sense. I wonder how many of us get tied up with the rules and doctrines and forget this too...

Common Sense? Yeah, I've heard of it....

The Sarcastic Scrum Master

As a Brit I am unbelievably sarcastic at times. Some might say uncontrollably, which can cause problems.

Just recently, I have been trying to channel this urge for good. I do this using my new favourite start to a conversation, "If Only...". This is the setup for my call to action, delivered with a sarcastic punch.

Here is an example:

Frustrated Developer: "GOD! What is going on with communication in this team? Nobody seems to know what is going on, everybody is running around like headless chickens - it's soooooo frustrating!"

Sarcastic Scrum Master: "Oh, that is SOOOO true! If only there was a point in the day when we are all gathered, in receive mode and trying to actively organise ourselves. That would be a great time to share knowledge or highlight a conversation that might need to happen."

Frustrated Developer: "What? Like the standup...."

Sarcastic Scrum Master: "OMG! I had forgotten about that! You're right that would be a good time to share things with the team. You would need to remember to say something of course, maybe we could add some sort of cue for you to let the team know something important...."

Frustrated Developer: "Erm. Like when you say 'Is there anything else that we need to share?"

Sarcastic Scrum Master: "Hey! You're right. I DO say that everyday.... what a ninny. That would be a super time to let the team know anything that they should be aware of."

It would be so easy to just say "That's what we have the stand up for" and be done but there is no learning attached to that.

Yes this is gently mocking and I know it works in my team with the relationships I have built. Your distance may vary.

My case for why story cards deserve a bit of love

I am an avid user of Post-its, which I commonly call 'stickies' since I am not a brand junkie even if I secretly compare my Brand X to Super Stickies.

I give you exhibit A:

Definitely a 'C' for effort - could try harder!

The stories on my board are represented by stickies and they have traditionally been extremely low rent. Creating a new story takes seconds and have always thought of this being a good thing. The format usually persists and easily adaptable so I have never done it any differently.

Just recently I have noticed that the simplicity of creating cards also means new ones are created often which I am not sure is a good thing....

Are we facilitating the idea that changing items in a sprint is quick and painless? Maybe even that it's a fringe benefit and does not cost anything?

If our goal is to form a set list of work for a sprint then we should be only creating stories once. We can afford to spend a little bit of time on them.

The card should reflect the effort that the team has already expended to get them into a state that we can create software with, which could have had many hours spent on it in refinement and planning by various members of the team.

Does a sticky really represent our investment in that story? Throwing away a sticky does not 'feel' serious but it might represent a significant investment in time and ultimately money.

So I have a new theory: Story Cards should be difficult to create and fantastic to look at.

Whilst my team think that glitter, funky calligraphy and lamination is maybe a smidge too far (I disagree) printing them off using a nice template and font's would make them easier to read whilst making them just too difficult to create ad-hoc or without a good reason.

Is our work really best represented by a dog-earred stickie written in questionable handwriting? Doesn't it deserve just a little bit more?

I think story cards should embody our view of our work and deserve just a little bit of love.

Maybe allow anything that was not part of our sprint planning be a sticky so we can see just how flexible and accommodating our team really is, which is often overlooked by the wider business.

What if it was your money?

A while back I wrote about my adventures with making a pizza oven. I built a prototype to test if I would actually use one, which went OK. I refined my prototype based on early feedback, adding insulation and investing in a laser temperature gauge so I could measure the impact of any changes to my design. I managed to cook some pizzas and other yummies but it was never really big enough to cook anything other than experiments.

This year I decided to build one for real. This involves a whole level of commitment higher than I put into my prototype, both in terms of money and time.

I spent a few months looking at how to go about this, reading articles and blogs from all over the place. If you boil it down an oven really had 3 key ingredients: the base, the skin and the insulation. There is lots of discussion about the shape but I think the dome shape really wins and the math is pretty well understood (there is a mathematical relationship between the height of the door and height of the oven).

The decisions are largely technical and there is great advice all over the place. I made my decisions based on what I could get hold of locally and my budget. The key decision was about the actual dome and I opted for one made in clay.

I chose clay because I had a pottery supplier nearby who sold clay that was premixed with sand specifically for pizza ovens - the thought of having to mix and muddle what would be about 75 kgs of clay did not appeal. I had previously purchased a bag of the clay in question so I knew what it was like to work with and decided that it would be more pleasant that working with a refractory cement, which was the other option.

The building of the base went well as did the dome and I stood back and looked at my creation with a bit of pride. Everything had gone according to plan and actually within my time estimates too. A for execution.

Then it all went wrong.

This was the first time I had worked with clay and everyone talked about leaving it for a few days before firing it for the first time. I waited for 2 but very quickly realised this was no way near long enough. I came to this conclusion when I saw some cracks forming. Frantic searching about this revealed it was nothing out of the ordinary and to be expected in some cases.

I slowed the fire but the damage was done. The cracks continued growing and once it was all cooled I realised the scale of the problem was pretty big.

Time to find a happy place.

So my sprint went well but what my team had put together did not meet expectations. The team had done all they could to know just enough to get started - we ask teams to have courage as well as be transparent when problems arise. We need a retro to find out what happened.

"What went well this sprint?"

The techniques we used worked well. The clay dome came together quickly and was structurally sound. The base retained heat well too.

"What didn't go so well?"

When we fired the oven, cracks started to appear. By the time we cooled the oven down the cracks had grown significantly, one of which is very wide. We did not factor shrinkage into our design either, so the dome is smaller than we thought it would be.

"What caused the problems we experienced?"

The big problem was that we did not wait long enough before firing oven. The guides were very loosely worded which we never questioned - our clay needs a lot longer to dry before being fired! By firing too early, the water in the clay formed too much steam which had to escape forcing its way out by creating cracks. There is a good chance we created too big a fire, too quickly. In conjunction with being too eager to complete the dome, these combined are probably the root cause. The sand mould we used should have been bigger to take account of shrinkage, which was not something we considered.

"What could we have done to stop this happening?"

If we had done some black hat thinking we would have found out about what happens if you fire to early. Searching for cracking and repairs would have given us the information we needed. We could have talked to someone about what a "series of small fires" actually is, which is very subjective! We should have talked to the pottery people more, who suggested that we should not be too eager to fire the dome. We could have quantified this with them - I thought a couple of days WAS enough! The shrinkage could have also been quantified with the pottery people.

Now thinking like the PO, I still need to realise the value in work we have done. What are our options?

The engineers view is that the dome is bust. There is a stonking great big crack in it. We can patch it but it will never be 'right'. We know how to do it better, we should kill it and start again. If we don't fix it then doing the insulation layer would be a waste of money - if the dome fails then we will have to destroy the insulation layer to get to the dome, wasting more money.

The shrinkage is not a large problem but there is a gap between the dome and the arch which will need to be addressed.

The insulation is definitely a problem, well described by the engineers.

In this case, we still don't know if we can make pizza in this oven since we have never tried. In software terms this is like throwing away code because you suspect it will not handle live load due to it's design without actually testing it.

Thinking like the SM, we need to generate some options. If we are unsure about the dome, is there an alternative to the insulation that requires less investment? Is there a way we can return some value from our oven without investing more into it?

If we did the bare minimum and made 10 pizza's this weekend before the dome failed would that be better than investing more but delivering a 1000 pizza's over a much longer period of time? Would we loose anything by patching what we have? What could we learn by doing this and how long would it take?

A more interesting question: What happen's if don't do anything? Do we know the dome will fail or suspect it will? Could we add more insulation at a later point if we find out what we have is actually OK?

We are often divorced from the money when we do this for a living but if you behave like it's your money then maybe your thinking is different. Seeing the sprint as an investment and asking what gives the best return is often a great way of getting people to think about it differently. I often use this with teams in retro's instead of using dot voting.

In this case I am the engineer, the PO and SM. And it's my money on the table. An I still don't have yummy pizza! As much as I hate the mistake I made, I can also see a half way house that allows me to get some value from what I have along with some more learning without additional investment. I might have less options in the future but I get some value now, which is a compromise I am happy to accept.

If I have to make another one, you can bet it will be awesome.

Future Trends - Part 1

I like imagining what might happen next. I'm terrible to watch films with - you tend to get a running dialogue!

Recently I have be applying this past time to my day job, imagining what might influence what I do and the teams I work in. I have a somewhat quirky, vivid imagination so some of the things I muse on are possibly the stuff of films rather than reality.

At the same time we all know that much of what ends up in films becomes real at some point too, which is the loose premise I am going to stick with for the time being.

Bold statement No. 1 - 'virtual world' development environments will become the mainstream

So what do I mean by this.... basically the VR technology we are using will be used to develop software. The virtual worlds we see in MPRG's will be used for developers to collaborate on software using avatars and systems will be represented as 3 dimensional structures in the virtual development environment, allowing visualisations of architectures. Groups of avatars collaborate by converging on a shared space to allow them to share the same view of the virtual world. People can zoom into a structure to see the code that makes it work.

Part of this thinking was inspired by a talk from Jamie Knight, who works at the BBC. Jamie is non-verbal and described how communication works in his teams. Since he uses tools to type and speak, conversations are limited by technology. To combat this, he has found that if everyone else use's the same technology then it makes the communication easier.

I started to think about the limiting factors for teams in successful companies and realised that the physical location was probably the primary one. Your staff need to be in the same area as you in order to turn up to work everyday, tales of serious competition for candidates are not uncommon as companies tend to group in local areas.

Played out on global scale, this is massively limiting. The best person to work for you might not even be in your country! When we think politically, they may not even be allowed to move to your country - with realisation of Brexit, this could impact the UK in future years.

If anyone has been working with a fast growing company, you will know the massive nightmare that it causes when you need to find (and house) a large work force. The physics becomes the limiting factor - you can't find the people fast enough and if you can, you can't keep adding people to the space you have. And we know how everyone just loves an office move...

On the flipside, anyone who has worked with a remote team or team members knows the associated issues - we see problems with communication, collaboration, ownership and culture. It is such a well know problem that we simply advocate co-location of teams since this basically gives you a massive advantage.

For me, taking the entire development environment into a virtual world actually starts to make sense:

• Everyone would have the same level of communication and visibility, so it is up to the individuals to make this work. By giving people the same tools, we level the communication playing field - the location is no longer a factor
• You would also be free to employ people from where ever you chose - reducing your problems to timezones and language, something which international businesses have previous experience with.
• By allowing people to stay in their native country, businesses have the potential to offer much more competitive wages as it's actually the cost of living that they must meet
• We know this scales massively (look at gaming) - it is only how we organise and communicate that becomes the limiting factor.

So why is a Scrum Master seemingly committing heresy by talking about such a thing?

Teams are key in this world I am describing - it is the whole reason why I have thinking about it. For starters, this would need to operate in a high trust culture - which get's me interested. It is entirely possible you may never meet the person you employ. They may also be protected by local laws that do not match your jurisdiction. That requires a level of trust that is hard to find in most companies.

Many of the interactions I take for granted can't be applied in this world - eye contact and body language would cut down my levels of feedback, meaning I would need to think differently.
All interactions with my team would now be virtual:

• What would interactions between virtual team members look like? 
• Would we still use boards (with virtual stickies, obviously) to organise ourselves? 
• Would we create entirely new ways of visualising our work, leveraging our virtual world's unlimited flexibility? 
• What would stand ups look like? Would we need them?
• How does the communication scale - would we have virtual replacements for messaging and chat or something new?

What about the 'feelings' of our teams? In this world people who are frustrated or annoyed are easy to spot - a virtual world allows people to edit their emotions, even block them entirely:

• How can we create a culture of trust that would encourage people to display their feelings given that this would be optional?
• How would we build lasting relationships? Do our team building techniques travel in a virtual world?
• Would a lack of 'real' human interaction be depressing?
• Would it be hard to get people to work together given that they are not?

There is no doubt this could be massively empowering. Small companies could grow exponentially and we could always hire the best. Having people in multiple timezones could create a naturally longer day maybe having multiple stand ups to coordinate work between them. 

People could spend more time with their families and have greater flexibility as we build our businesses in environments that are as flexible as our creativity. Where people need to come together, they could choose to meetup at co-working spaces or any other space they deem appropriate.

Wouldn't these be the real internet companies?

Also See:
http://liberumvir.com/2013/07/08/a-wholly-immersive-dev-environment.html
https://ghost.org/careers/
http://www.ibm.com/developerworks/library/ws-virtualspaces/

Retrospective: The End

People leave. Occasionally, this will be the SM. This retro is dealing with the handover to the next SM and acting as a exit interview for the SM.

The goal behind this is to give the new SM insight into how the team regard their process, what they need help with and most importantly what they want to keep. This was to give my new SM a good idea of what the teams buttons where so he would get off to a flying start with the team.

It also helped me see some improvements that I could carry with me to my next team. Some I knew about some I needed to acknowledge. SM's, like teams aim to continuously improve.

The icebreaker I used was a simple game where I wrote up some numbers and asked the team what they thought they correlated to. I went back to when this team formed and found totals for: Number of Sprints, Total number of stories, Total number of points, Longest Lead time and average velocity.

Then we did a happiness radar to give the overview of what the team think about 3 areas:

• People - the people they work with both in and out of the team
• Technology - the kit they work with on their local, development and integration environments
• Process - the way they work

I gave my team 2 votes each and they created this:

Thinking like my new SM, I would be thinking "Hmm, I wonder what's up with the technology?" and maybe "So, observe for a while since these guys think everything is working just fine".

The last section was just a post it session around some key questions:

• What should the SM leave alone?
• Is there something the new SM should look into straight away?
• What are our strengths?
• What does Richard do that our new SM should do too?

As usual, it's the little things that made me chuckle - biscuits, always a favorite:

When the SM arrived I went through what the team had said and gave them a rough history of the team so he had some context. Not only did I find this process quite therapeutic, I think it helped the team know that the next SM would help them continue on their chosen path rather than make them take a different route.

So, who is the customer exactly?

The term customer is often used in agile teams to represent who we are delivering value to.

The problem is that the larger the organisation, the more difficult it is to separate value in terms of things software teams can deliver and financial value placed on those things by the institution buying them.

In a previous role, my company sold software to the NHS. Part of my challenge was to connect developers with the value they were delivering. The challenge with this was the sheer number of people that were involved with the software, each of whom derived a different value from what we sold.

The NHS is split up into trusts, which are spread throughout the country. You don't sell to the NHS, you sell to a trust and each one is independent even though they all contribute to the same national charter for healthcare.

The trust itself could consist of multiple sites which offer services, each of which might have different requirements depending on the services they deliver. Each trust has it's own IT departments and generally a project team for a large deployment. The project team will be looking after how the solution is implemented. They will also have accountants looking after the financial aspects of the project.

The project team work across the different departments that will be impacted. During a tender they will consult with the heads of department and consultants that work in those departments. There are also doctors, nurses and other support staff who may be consulted.

As you can see there is a bit of chain forming and each level of this chain is looking for a different aspect of value from the delivered solution.

At the top you could say this is predominantly financial - how much the thing costs to implement, support and run. The project team are interested in the financials, but more so about what the solution does and how it fits in with their existing infrastructure. At the bottom you have the people who use it, who's concerns are solely with the software itself. They have no interest in how much it costs, just what it does.

For me, this does not still describe the true value of the systems the NHS use since the customer is actually the patient. They do not use the software but without them there is no point to the rest of it. Continuing one level further down the chain reveals a better way of understanding the value we deliver. In this example, everything should positively impact the care of the patient.

Indirectly, this could be reducing costs for the trust. Lower costs mean more funds for the care of patients, however the trust chooses to deliver it. Directly, it could be managing the information gathered by the hospital to provide the best care for the patient by the doctors, nurses and specialists who use the software.

In every system, there are multiple customers and the value they want from the system will vary. In each case, there is at least one core person or group who benefits - removing them, removes all value from the chain. Finding that person is key to understanding the true value of what is being delivered.

The Art of Not Listening

"What was that? You want to know more about my day and all the fun I had with your daughter's teacher telling me how she wasn't LISTENING to anything she was being told...."

Yes. I am in trouble again for not listening. Totally my fault this time, I got distracted and missed a very important part of what my wife was saying and never quite caught up.

The talking to herself in the third person is an coping strategy mostly to give me another chance to join the conversation as well as being the equivalent of counting to ten before exploding- I can be challenging to live with.

Every time this happens, I am usually doing something else. Whilst I can have many threads spinning away in the back ground, I can only ever have one being actively done - so in checking the post and listening to my wife's day, I inevitably drop something. And it's usually the wrong one.

To prove the world is in balance and everything has a positive spin, I am going to explain how and why not listening was one of the better things I had to learn to do as a Scrum Master:

1)  Trust - the detail of what is being delivered is my team's responsibility and I trust them to make the right choices. I have learned over time to disconnect from the detail of what they are talking about and only dive in there is something they need to observe or think about. I like to think of it as filtering and reacting to key words or phrases (more about that in a minute).

2) Non Verbal clues - being involved in the conversation means my attention, running on that single thread is consumed by that alone. I am missing body language from individuals (who's bored, distracted, confused, agitated, annoyed) . This might be revealing how they are sitting, fidgeting, facial expressions - all of which need you to observe and process. These are cues for a good facilitator to jump in, to draw out something that might help us as a group.

3) Who's not speaking - some people are quiet but that does not mean they don't have something to say. Most teams have a dominant character or 2 and it can be all too easy for them to take over. Watching who is not speaking, along with body language allows you to pull them in and give another voice to the conversation.

4) Highlighting issues - I have learned to filter and listen for key phrases. I use these to help the team realise issues or change the conversation they are having. So if I hear things like "Maybe...", "What if...", "I guess..." I'm starting to think there is a little uncertainty in the air. Are we making an assumption? Is there someone we can get to help us with this, if we don't understand it fully?  If I hear "Could we..." from a couple of people then maybe we are in whiteboard territory and should be drawing this out rather than trying to explain it. The cues can we quite unique to the team but some are universal.

5) Facilitation - freeing up that single thread means you can help out! We can capture that conversation in notes, write up stickies or actions, repeat and confirm with the team to move conversations along. We can structure the conversations to provide a background for the team - I have noticed that talking about the things we find hard first usually yields better results e.g. deployment, testing.

Allow your team to get lost in the detail but know when to pull them back again. This can only happen if you are the observer and not caught up in the moment with them.

Obviously you probably want to the opposite during a retro. And when you significant other is talking to you.

The foundations of the Agile Manifesto

There have been many occasions where the Agile Manifesto has been pulled out in a presentation. Makes sense, it has been around for a while and started a movement which is still growing today.

We usually get caught up with the Agile Values and Principles but have you ever thought about the very first line?

"We are uncovering better ways of developing

software by doing it and helping others do it."

Recently, I had cause to realise the how this is the foundation of the Agile Manifesto by making and acknowledging a mistake.

I had been recording leadtimes for a while. The information was useful but there was something troubling - 13 point stories just didn't fit. No matter how we prepped or planned they always took longer than our sprint window, sometimes MUCH longer.

So I wielded my power as an SM and banned them. Poof! Gone! Good riddance.

Thing is, I had just moved the problem. Over time, I noticed the same issues we had observed with 13 point stories start to affect 8 point stories. I don't think this was conscious but I do think it was due my 'ban'.

It struck me that we had broken one of the foundations that are baked into the Agile Manifesto and everything it contains - by no longer doing it, we could not learn from our mistakes or successes.

It seems kind of obvious but I had never thought about it before. 

The manifesto was born out of 'doing' and 'sharing' - the people who some up with it did not hypothesise! You can only learn from doing - by banning my 13 point stories, I had stopped all feedback from experience and therefore any learning too. We accelerate our collective learning through sharing our experiences, both good and bad.

So I came clean with my team, said I goofed and the team took in not only 13 point stories but much larger ones too. Each time we tackled one, we learnt a little bit more and the next one was just a little bit smoother.

(But they still don't fit!)

What's in your tool kit?

Yeah, yeah so you have a million different Post-Its and Sharpies. Time to experiment.

Recently, I have been spending an obscene amount of money on other bits and bobs to help me come up with some better (or longer lasting) visualisations. There's also some stuff that I ended up using in retro's a lot. Here's some stuff I have tried:

Magnetic Tape
Most boards are magnetic these days (mine turned out not to be but I have stopped crying now) so this is an alternative to blue tack for avatars or other icons. Pretty pricey but it does hold well and is easy to move.

Sticky Tabs
I have begun to hate Blue Tac and these are promising. They are sticky tabs that stick and re-stick. The hold on them is often a little too good sometimes but they do what they say on the tin. Early days, wondering what happens when they get 'fuzzy'

Egg Timers
I love these in retros. They are very unconfrontational and allow you to keep everything moving along - if you need to work to a timebox, these are awesome. You can also use them in meetings to keep people from rambling on. 3mins is a nice time, will be ordering more - they come in a range of times.

Phrase and Date Stamp
I found this rubber stamp that had phrases on it too - nice for dates on story cards. Now people will not have to suffer my handwriting.

Stapler
I have found that stickies often don't make it across the board - one of my teams started stapling them to the main story once they accepted it to cut down on picking them off the carpet. Can't live without one now....

Large Ruler
Tip: add a little some Blue Tac on each end to make it easier to draw a dead straight line on any surface

Chalk Pens
These turned up one day and are brilliant for writing on glass. They come in a range of funky colours and are more difficult to rub off than whiteboard pens - good for lining out task boards. They come off easily with a bit of water.

Lining Tape
Great for lining out boards when you don't want them to move. Not sure when then really 'stick' or what will be left behind if you have to remove.

Sucker Cups
If you cannot use tape or afford Chalk Pens then this could be an option. Sucker cups with string work OK but do have to be pushed in everyday or they have a tendency to fall off. Good on glass not sure about white boards.

Magic Whiteboard
Personally, I don't like this stuff but it does have it's place in the emergency corner. I am usually lucky enough to have a whiteboard but this fills the gap when that luck has run out.

What have you got in your toolkit - have I missed anything? Let me know :)

Debts and credits in your backlog

Once a month I feel like a rich man. On the day I get paid, my bank balance shows the fruits of my efforts in all their glory. This lasts a day or 2 until some bugger comes and swipes the lot!

In reality, I am actually poor. Like most people I have a huge debt in the mortgage on the house that keeps me warm and dry. This is a well-managed debt, lasting years that I nibble away at each month. 

If I were to treat my finances like a business on an extensive balance sheet then I would make my true financial situation visible. It would make me sad obviously, but if I want to know my true position then this is what I should do.

A POs responsibility does not lie solely in serving the customer. They must also align the customer’s requirements with their company’s vision. These are 2 perspectives but the developers give you a 3^rd which is equally important – they can tell you about all the things you CANNOT see and yet still affect your product.

Many POs I have worked with insist that the backlog should not have any stories that describe technical debt since they have no value. I would ask you to consider that the backlog is better seen as a balance sheet – it forecasts the future worth of your product.

So if we treat the backlog as a balance sheet, we can start to attribute the losses of not addressing technical debt against the gains of new features. It is actually the combination of these that describe the true position of your product and its ability to continue making you money. 

Our technical debts are ever increasing – this is either an active process which we decide on or a passive process through neglect.  Just like a mortgage, there is maximum we can afford based on our resources – we cannot keep increasing our mortgage forever.

If we don’t carefully managing our debt we might have to take out a more expensive loan to cover the costs over a shorter term. At worst, this could be one of those payday loans because we exhausted our credit with all other lenders who rely on us being sensible in order to do business with us.

Technical debt provides balance to your backlog. Viewing your debt alongside your credit allows you to make more informed decisions about what to invest in and when.

What the Minions movie taught me about job hunting

The Minions sole purpose is to follow the most evil boss they can find. They are completely fulfilled by following their master. They are easily distracted from their current master if a new, more evil master comes along.

They don't get paid. There is no package and employment conditions are dubious to say the least.

What we could all learn from the Minions is that their choice of employer is solely based on leadership. The more bad ass the boss, the more the Minions want to work for them.

So when the Minions meet up with Gru, they know they have found their 'big boss'. They follow him because he is the baddest, most evil villain they have ever seen and that is what they need to believe in his leadership.

When was the last time you did this when you were looking for a job?

We all read a spec, find out where it is, what the package is.... how many times do we look into the guy or girl at the top? Not just finding out his or her name but understanding what they are about - 'why' they do what they do?

This was a question I asked myself not only because I recently have made the decision to move to another company but also because I was reading "Start with Why" by Simon Sinek. It made me question how I had been looking for roles which has been governed by the dating style dance of supply and demand rather than a desire to work for a specific company based on leadership.

The recruitment industry fulfills a difficult dance - an employer needs to fill a role and the recruiters essentially play a numbers game trying to find a fit for the person, skills, place and time to fill it. Someone might be a perfect 'fit' but unless they are ready to move on, it simply won't happen.

But how many people search for their role based solely on the ethics or purpose of a company? I'm talking about companies that have a clear intention and vision - those who are led by people who inspire us? People who have inspired an entire workforce to follow them.

On a practical note, how would we find these people or organisations? The large companies are well known - they cannot be the only ones! How do we find the next generation of Virgin or Apple? How do we know they are looking for people like you? At the moment it feels more like luck than a plan - like the Minions following a new master until something better comes along.

This is slowly changing to a more pull style recruitment drive where social media plays a pivotal role. My recently journey onto the job market was totally different to anything previously - I reached a dozen or so organisations through introduction alone. I managed my own interviews and offers and yes, it was hard work.

In the meantime, I want to pose a question:

How many of us really see an interview as a two-way thing?

Shouldn't we be interviewing them as much as they are interviewing us? As much as they are trying to find out how we will make their 'why' real, shouldn't we be trying to find out about their 'why'?

Whilst we might not be able to target our recruitment 'aim', we can certainly make sure we know what an awesome company looks like when we end up in an interview with them. That is only obvious when you find out 'why' they do what they do and you believe it too.

How I would interview developers now

I have done my fair share of interviews. I recently realised I was doing it all wrong.

Now, I would only talk about testing. It's a much better gauge of a developer than anything else.

If the developer is describing manual testing, I'm thinking Junior. At best.

Everyone has heard of unit testing, so I'm interested in the level they have taken this to. Have they only done unit testing on green field projects? Did they add functionality to a project that already had good coverage? Did they have to bring up the coverage of something that already existed?

If they had to add tests to something that existed, how did they deal with architectures that didn't have testing in mind? Did they use any patterns to help with the transition? How did they negotiate the risk of refactoring code that had no tests? Did they form a strategy for ensuring the functionality was the same before and after - what was it? Did it work? What did they learn?

Test driven development usually comes up too. Describe it to me - I'm interested. How did you get started with it? Do you use it for everything? TDD is hard and you can loose the discipline quickly. I have come across only a few developers who really did TDD - the rest write unit tests after their implementation, which is not the same. What's the difference? Is it OK to do it this way - sell it to me.

So you're writing tests. I'm now thinking you are developer with a few years experience - you've seen things, you have scars.

Again, I'm interested. What does a good test look like? How would you name a test? This is particular PITA since we all know naming things is haaaard. I want to know the thought process though. How have you managed hundreds of tests? How about thousands? How did you structure these, how did you evolve this over time and what did you learn? Did you group tests together - what has worked for you in the past?

Let's talk smells.

What does a really long test tell you about the code you are testing? If you have initialise half the app to do the test what's going through your head? If lots of your tests are using the same dummy data, what might you expect to happen in the future? What would you think if you saw multiple asserts - is that OK? If not, can you think of any examples where it might be OK?

Tools can also be a topic of conversation. What frameworks have you used? Can you do unit testing without them? How would you go about that? What's the difference between a fake, a mock and a stub? How would you use each?

Getting more interested. You've probably refactored some tests - maybe had to teach people. Maybe had to be the sheriff at times. All good - I thinking more senior now. You've probably had more responsibility or accepted more for 'the cause'.

We're in integration land now. How have you set the state of a test - what strategies did you use and why? How do you deal with large databases during tests? How did you deal with specific customer configurations? How can you structure tests around failures - how does this affect automated runs? What happens when you have too much to run in a single night?

Depending on your flavour we might be talking API or UI. Have you had to apply tests to a legacy Windows application? What challenges did you face? Have you tested Web applications? Is there anything you had to differently to allow the UI to be automated? What mistakes did you make or uncover? How about mobile applications? How did you deal with apps that were for multiple OS's and ensure conformity?

Integration testing is often tool heavy. What did you use? What's your favourite? What features really helped you? Did you write anything to enhance your toolset? What did it do?

If we get here, I really thinking lead. I'm liking the embedded approach to your thinking - QA is a part of your thought process and experience.

Testing is a part of team life. Agile teams own quality. They nail it in the sprint - it is a part of the DoD, one guy in the team cannot do all of it. How far on this journey are they? How do they plan testing in their team? How do they estimate it?

Think about what I'm REALLY asking. If you are not testing anything yourself, I'm wondering about your code - to be honest, I'm wondering if I could understand it and maintain it. If we are talking unit tests, you have probably had to confront this and do something about it. We all have had that "who wrote this rubbish?!" moment only to discover it was us.

Talking about unit tests means, I'm pretty sure you are familiar with Dependency Injection, if you can describe smells you probably also get Single Responsibility Principle too. You might have had struggles with the Open/Closed Principle and realised the pitfalls of inheritance and how this affects what we are testing. So we are also touching on OO principles like encapsulation and composition which influence how we structure code so it can be tested. I don't need to ask you any basic questions because if we got here, I'm pretty sure you know that!

I'm also getting direct feedback on how you regard quality. This is not the QA's job - it is everybody's job. It is core to delivering product. Quality is embedded into each line - code is crafted to be tested, products are designed to tested, developers need to think in terms of delivery - the output of which is also tested.

Anyone can rattle off definitions but describing how you apply these to deliver software is easier to gauge if we only talk tests. It's also really hard to fake.

Why I hate 'Best Practice'

I hear the words 'best practice' almost every day. My eyes roll over and I look vexed. I don't mean to, I just hate this phrase.

I live in a world where we make things transparent so we can inspect and adapt.

How does this work with 'best practice'?

By adopting 'best practice' we are making the assumption that this is the ideal, that there is nothing left to learn.

We might also put this all in a locked box so we can't change it. It is 'best practice' after all - you will probably mess it up if you play with it.

So when one of my team recently said he could not change the QA 'best practice', I suggested that we absolutely needed to try.

Together we proposed we do something different - based on observation and experience - that might make the process better. We decided to run an experiment to test our own theory that the 'best practice' was flawed and can be improved.

We proposed how we could evolve the process and measure it's impact so we can decide whether we should keep the change.

So what is 'best practice' in a process that designed to evolve?

To me, it is the last thing that worked.

This might not be the last thing you tried since you always have scope for experimentation and learning.

In my world, nothing can be 'best practice' since we can always improve it.

A tale of teamwork

Our daughter was born very suddenly and very, very small. Being only 5 grams above the threshold for special care, she was a tiny little thing. Being a bit of a drama queen, she decided to sit on the exit so we had to go in a get her. This meant both mum and baby had a week in hospital while mum healed and we waited for baby to get big enough to be discharged.

My wife was determined to breast feed but within hours we all realised there was a problem. Our daughter had a tongue tie which made it very hard for her to control her tongue and suckle. Basically the little flap of skin under the tongue was attached to the front of the tongue. To this day she cannot really spit out her tongue (although she gives it a bloody good go!)

The week in hospital meant mum and baby were surrounded by professionals. They had seen it all and gave every piece of advice they could muster to help mum and baby breast feed. There was marginal success but we still had to top up with bottle feeding. Being so small the effort often made baby tired, so much so that we used call her 'two tugs' since she should often take a tiny drink and then go back to sleep!

The midwives discharged mum and baby not because baby had put on the required weight but because they saw there was nothing else they could do. Mum knew what had to be done and was still determined to do it and baby was feeding but just needed to do it a bit more. We were told mum and baby needed to feed every 4 hours. That's EVERY 4 hours - which we did for 8 weeks. I still chuckle when I say "I'm tired" out loud.

At home, every friend, family member and even passer by offered their advice and expertise on the feeding problem without any improvement being realised. Their input was welcomed but they could not fix the problem for us.

It was only when mum and baby were just left alone did something amazing happen. Through trial and error they came to some sort of arrangement. Baby got bigger quickly and everyone was happy, not least because we were getting some sort of sleep.

The arrangement was possibly the most quirky and odd thing you would ever witness. Mum realised that baby was a bit finicky about sides meaning she had to slide her from one breast to the next, holding her like a rugby ball, curled around her side.

Keeping baby awake turned out to be easy - mum simply blew on her face which was enough to get baby back to the task at hand. She did look a little startled the first couple of times!

The tongue thing was resolved with a combination of timing and what can be only be described as hurling the child at the target. It turned out to be the only way baby could get a good grip that she needed to suckle. Baby is hungry, she opens mouth and mum flings her at the food source - it looked very funny!

But it worked.

All teams form around a common goal. Sometimes they just need to left to figure some stuff out for themselves. We equip them with everything they need to be successful - knowledge, encouragement and trust. Teams need to find their own path - it's often not the way we envisaged or advised. They know where we are if they need our advice.

Great teams figure out their own way to get the job done. Sometimes we are lucky enough to be present for their success and the small part we had to play in their journey.

My favourite team