I don’t
blog often, and when I do I tend to stay within my field of expertise –
testing. But I need to get something of my chest today, so here we go! (sorry
about the long blog post J)
When I read
books or blogs about agile, or hear presentations or tutorials at conferences I
hear about all these great methods and tools for building quality in, for
testing first; test driven development, behaviour driven development,
continuous integration/delivery, business as an integrated part of the
development team, tightly knitted teams – high performance you know, tribes,
squads, a/b testing etc.
All that
stuff is really great; and hearing the stories of how to embark on an agile
journey is a dream – but can you see that dream happen just like that in your
reality? I mean if you start an agile transition when starting the creation of
a new system it surely makes sense, and you can start “the right way”. And
maybe then it is “just” something you can do.
But what if
your context is different? When I look around at the companies I know of, or
hear about from fellow testers, and I can’t help thinking: there is a HUGE
journey to take from that reality and to the Nirvana described above;
Huge system
landscapes with large dependencies between systems, old legacy systems mixed
with new, rather bad test environments, only manual test cases above unit
testing – huge manual regression test suites – or maybe the opposite; no
regression test at all. Unit test coverage around 2-4% if any at all, product
owners totally stressed out because they have their normal day job besides the
product owner role, projects with people assigned 30-60% because they have a
couple of other assignments... oh yes and lets top this with a desire to
outsource because that seems to be the thing too.
So with the
risk of awakening the unicorn world vs. real world from Agile Testing Days past
– could we move our inspirational talks and tutorials a bit from the perfect
world scenario to the one that many people are in today? In a context like that
how do you get started with agile? What is needed before you embark on that
journey? If you have an old organization used to work within a waterfall
approach with strict roles and responsibilities – the shift is not that simple.
How do you eat that elephant? Let me hear presentations about the struggles,
the challenges and how you overcame them – not just the fairytale where all
just went well. I learn so much from mistakes; mine or yours doesn’t really
matter.
I don’t
have the answer – but I think there are some fundamental things you need to
start with, before starting to talk about all the different methods and tools.
First of
all, understand that agile is indeed a Journey – it is not a switch you can hit
and then presto - you are agile! Maybe you will one day reach that Nirvana you’ve
read about – but maybe not, and that might actually be okay. Understand what is possible in the context you’re
in.
Before you
embark on the journey; understand what agile is – get an understanding of the
agile mindset, the principles and the values. Agile was not created for the
companies to save money – it was created to strive to give the maximum customer
value, to create a better understanding and faster feedback between business
and IT, to deliver quality – of course these things may save money too, but
that was not the end goal in my humble opinion.
Get a clear
picture of your own context. And if you are an external agile coach reading this –
PLEASE get a good understanding of the context you are in – coming from the
outside, start with using some time understanding! If you have several hundred
systems entangled in a big pile of spaghetti of dependencies, and no test automation at all - maybe shouting “let’s
do continuous deployment” is not the right place to start J. Understand the people you are
going to help – where are they, competences, values, organization, culture.
The next
thing to do is not to find the right tools – it is to find the right people,
and bring them together. It is hard to be agile if you are sitting in different
locations, if all communication is via phone, Skype or video. We need to meet,
learn, and share – if every day is not an option, then at least often. And
remember it is not for everyone to take that journey to an agile way of working,
some will chose not to and that is okay too J
And then I haven't even mentioned the business yet - how to integrate them, under stand their world and needs. But that is for a whole other blogpost. Well I am a tester, so I need to jump to that area of the journey. The
decision is made – we want to move towards an agile way of working... How do we
get this show on the road when it comes to testing? Imagine that:
- Your system is 5-6 years old maybe older - and it is BIG and complex
- You have a huge manual regression test suite
- The system integrates to a number of other systems
- There are limited to no unit test and no other automation at all
- Developers are doing a minimum of manual testing before it is handed over to business to test
- There are no experienced testers – business only and they differ from time to time
- There is a test manager – he is responsible for getting the business resources for testing, but have little influence on how the development team tests.
Where to
start, what to do? What do you think?
Thank you for your patience... I will stop now ;-) but I need to write a part two I think :-)
/Gitte aka godtesen
