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

Now that's what I call a plan.

Creating a bunch of stickies never felt like a satisfactory result from planning. This is a reflection on the progress made by one team to create a real plan of how to convert story into software.

Stage 1 - Creating tasks without conversation

The team's planning session creates stickies for various tasks that we need to develop the feature. This is led by only a few of the developers and it is almost entirely directed by them. The stickies represent pretty big elements of work and the estimates are pretty high - most are over a day in length. There are very few testing tasks, which are created by the QA guy only.

Observations:

• The team aren't thinking how to do this work - someone else has decided and are dictating the tasks as they see them
• The tasks are not very granular so detail is being missed and the resulting estimate is not very accurate
• The team is not owning the QA - they are creating 2 teams which might not join up to deliver the work

Stage 2 - Experimenting with Diverge and Merge

A recommendation from our Agile Coach gets the team using Diverge and Merge to create tasks. The whole team creates tasks in parallel and then they merge their stickies. This breaks the dependency on individuals leading and makes everyone think about what needs to be done. Merging creates conversation as some people think of things that others haven't and we all reach agreement where we have the same tasks. To make this work, it is need to follow the work through sequentially. You can optionally play a game to see who keeps the most stickies on the board, which keeps the session flowing.

Observations:

• The team don't really buy into Diverge and Merge but the sequential story of what needs to be done makes sense to them
• Involving more of the team means we have less direction from individuals - there is more ownership from the team rather than following individuals
• QA still a secondary process within the team
• Tasks are still quite large

Stage 3 - Creating tasks sequentially

SM encourages the team to explore how to do the work sequentially, encouraging quieter members of the team to contribute. Larger tasks are broken down and things we often forget also take time are included like documentation, deployment packages, merges. The QA guy is still doing the same thing but SM asks them to explain the approach to the team, which does not result in a lot of feedback.

Observations:

• Following a linear path through the tasks makes it easier for the SM to pull developers into the conversation
• The larger tasks were hiding detail that we need to discuss in order to estimate - breaking them down helps reveal these
• Asking the QA guy to explain the testing approach helps to breakdown the 'us' and 'them' - it introduces the notion that the whole team should understand testing, led by QA

Stage 4 - Team ownership of Quality

We start the planning by talking about testing not development, which was an action raised in a retro. The team create a basic test plan and everyone estimates the test tasks. There are clear gaps in knowledge as estimates are wildly different - team estimates and indicates which tasks need pairing for knowledge transfer.

Observations:

• Talking about testing first influences the order they develop in, so the tasks are a little different.
• The testing plan being known by the team means they can shift between development and testing tasks - this gives the team more options as to how they deliver the work during the sprint
• The knowledge sharing is clear and improvements are found easily as a part of the process - no retro needed for this one

Stage 5 - Team collaborates on an approach

The team realise some stories need more thought. If left to the sprint, these decisions need to be made by a single developer rather then by using the wholes teams skills. A retro action is to use a whiteboard session to discuss the approach before a story is started. The sessions visually describe the areas of the system making it easier to spot difficulties or additional tasks that might be missed with conversation alone.

Observations:

• Pictures work better and getting people to explain using the diagram helps too
• This is very Just-in-Time - is there an earlier opportunity for this?
• Some areas of discussion maybe go too deep - the team sometimes dive a little too deep into implementation.
• A retro action from the team empowers them to huddle if they need team ideas/consensus - this helps counter only one or two developers deciding things without anyone else knowing

Stage 6 - Planning using a whiteboard

The team move the whiteboard session to planning and then decorate the system areas using tasks as they follow the development sequentially. The team discuss testing as a part of the conversation, making testing more integrated into the development. By grouping the stickies to areas of the system, they are able to see how many of them could work on the story at the same time.

Observations:

• The combination of a picture and sequentially discussing the development works nicely - it helps expose tasks the team has frequently missed
• The team is starting to think more about how the tasks could be done in parallel by picturing areas they can work on without tripping over each other
• Testing tasks are easier to spot - impacts on existing tests are highlighted quickly

This journey took quite a few sprints. There were regressions as well as advances but when I look back I saw these stages of development. The retrospectives drove many of the changes but we also saw spontaneous creativity - using the whiteboard sessions to plan against, is a good example.

The key thing I saw from the team was a shift in focus. Instead of planning how to do the development, they are now thinking about how to deliver the story. This goes further than a list things to do - it should aim to answer the questions:

• What order is best to do these tasks in?
• Who has specialist knowledge that we need to leverage?
• What does testing look like for this story?
• How can everybody assist with testing?
• How can we get everybody working on the same story?
• What do we need to knowledge share on for the future?
• What does the final solution to this look like?
• What are the 'risky' tasks?
• Who else might we need help from?

What does your 'plan' look like?