Painting over the rust - Preparation, preparation, preparation.

I thought I would follow on from my post painting over the rust.
It would be too easy for me just to say, hey our business people don’t get Agile, boo hoo. So I thought I would try and address the issue by thinking about how I felt when I was first introduced to Agile. Thinking about it this way allowed me to take a step back and understand why they don’t get it.

1. All Requirements are not needed up front.
This ones a biggie. I wrestled with it for ages, but then I would, I’m a tester and I need those requirements to do my job; after all the V-Model is nothing without upfront requirements, right?
How did I overcome this? Easy (for me at least), in that in our old way of working, even when the requirements were available early, they often didn’t reflect what was actually delivered. This is software delivery after all; we expect the customer to change its mind during the life cycle. So if I’m used to finding that the requirements documentation don’t match what’s delivered into test, why am I so worked up now? Oh wait, I’m not after all. It just felt uncomfortable because its new to me.

2. Story Points are a guess but the deadline is still firm (if not impossible).
This one is a bit of a paradox. Both are true. During estimation we size the stories with t-shirt sizes or points. The point or size at that stage is no more than an informed/educated guess. Again I had a hard time with this, until I realised that it is just a concept that allows us humans to gauge the relative size of the stories. Wrap your head around the simplicity of that device, and your home free. Sure it’s a guesstimate, but we can still meet the deadline, knowing how much work is in there. Once you get the fact that its just about relative sizing and not a unit of currency for determining performance, it becomes second nature. Its all about making sure the team gets the same amount of work passed down the conveyor belt, and that they don’t get under or over utilised. Once you know they can knock out two 4 pointers and a 6 per iteration, you know your capacity (well mostly).


3. Tasks do not get assigned at Iteration Kick off.
I didn’t struggle with this too much, in that previously a task could sit with someone that didn’t have the bandwidth to complete the task for a very long time. One important protocol is leaving things until “the last responsible moment”. By not assigning tasks we can leverage the flexibility that the last responsible moment affords. Also, during the iteration planning, the team can agree what tasks make up a story and perhaps identify the required SMEs. The whole team takes Responsibility for promises the team made. We will deliver value.


4. An increase in speed comes from maximising Quality.
It took me a while to fully understand the power of this. If the team gets it right first time, then it spend less time fixing broken code, or miss understood/poorly captured requirements. I’m sure some Kanbaners out there will be nodding sagely. But this is one of the core principals that Toyota follow, they claim to produce one brand new, fully tested, inspected and passed vehicle in the same time other manufacturers spend snag fixing at the end of their lines.
Traditionally in software delivery, code fixes are not time boxed, and a defect can loop through QA and DEV several times before its fixed. One pair can sink a load of time into fixing the defect while QA source the effort around regression. It’s a massive waste. Enforce a Zero Defect policy; get the business to sign up to it, get buy in from the operational functions (Helpdesk, System Administrators etc) and say goodbye to the defect backlog. Get it right first time and watch throughput soar. Write your tests, then your code, then apply your design.

In Summary

It was difficulty for me to adjust to being a tester in an Agile world, and it took me time. I learnt through an apprenticeship with ThoughtWorks. They may have their own flavour of Agile, regardless its not something you can learn in a book or on a course. Much of what i learnt about Agile is more about your mindset, and self discipline.

Several times along the way, I thought, this is rubbish, this is causing pain and this doesn’t work. But hey that’s Agile right? If it doesn’t work for you, you can stop, change, and monitor for improvement. Once you appreciate that, you become empowered. You can leverage the power of one.

But, we had left our business behind. We (the software delivery team) decided we had to be Agile to deliver a project, without considering the impact to the business. Worse than that, we undertook an apprenticeship with ThoughtWorks and expected the business to understand story points, velocity, waste, lean, eXtreme Programming... the list goes on.

If you haven’t taken the time to bring your business along for the ride you cant expect them just to get it.
If you use enough filler, you can paint over the rust.