Uncovering better ways

I am uncovering better ways of developing solutions – by doing it and helping others do it. Through this work I have come to value:

  • Apply the costs to add business value – over cutting costs
  • Being flexible and open  – over adding predictability 
  • Providing information for decisions – over ensuring the reliability

Continue reading

To scale even agile needs governance

Key takeaways from [ “Why Agile doesn’t scale, and what you can do about it” | Dan north (@tastapod) | GOTO Aarhus 2013 ] If you want the full version see his full slide deck here.

2013-10-30 15.21.48

Being agile is about getting something out the door – it’s very good in doing SHIP IT – Tweak it – think it build it. Wax on – wax off. Being agile is about people and tools  and is a great approach for problems that allows to be solved with these borders.

The challenge is in the more complex  domains with a bigger solution, a bigger problem, a bigger program with many people, many dependencies, many teams. In these (NP?) problem domains other factors come into play: Governance, Customers, Money and the organization as a whole (see slides regarding Agile Adoption Patterns).

In the later contexts agile as a delivery model doesn’t scale without project governance and portfolio management to oversee and prioritize based on strategic returns on investment. Shipping any minimum viable product from time to time in a larger context requires more oversight on “are we nearly there?” “are we ensuring delivery?” “are we ensuring credibility?” .. are the many global teams going agile in each their direction?

The same goes for the testing efforts – agile scales to a certain point, and at that point the scrums, the state-models and so on are a part of the solution engine. It’s what’s tests something, but with size comes the need to know why we make the decisions we make – and  are we there yet?

5993667708_727f601b5e_z

Disclaimer: GOTO Aarhus 2013 is sponsoring my attendance as a blogger.

On applying a single method

Simon Wardley, Leading Edge ForumOh not again – should we be an agile or six sigma shop? ]

First, every system of any reasonable scale consists of multiple components. Those components are all evolving (due to the effects of competition) and you can (and should) map out the components of any system before embarking on trying to build it. Below in figure 1 is a basic map from a heavy engineering project with a large IT component

Now, all the components are evolving from left to right and as they do so their characteristics change – they move from an uncharted space (the novel, the chaotic, unpredictable, uncertain, potential differential) to the more industrialised (the common, appearance of linear order, the predictable, the certain, the cost of doing business). 

The same thing with your testing – that is: If you dare to take a holistic approach and not only focus on the mechanics. See also:  Mapping testing Competencies , Learn to think like a businessWhen do testing happen? 3D model for testing contexts Black or white – it is the same box

Mapping testing Competencies

[ Recognise and Acknowledge Your Skills  | Ministry Of Testing – The Testing Planet | June 2013]

The below model is directly inspired by the Vancouver Agile Quadrant introduced in “Agile Testing: A Practical Guide for Testers and Agile Teams” by Crispin and Gregory 2009 based on the original matrix from Brian Marick in 2003. It consists of four primary branches – as seen on the illustration. It is not a matrix or a table, but four directions with each their cloud of buzzwords. For specific contexts a mind-map will be a better choice of illustration – try drawing your own competencies.

Tester Skills Matrix
Tester Skills Matrix

TYING IT ALL TOGETHER…

[ Recognize and Acknowledge Your Skills | Ministry Of Testing – The Testing Planet | June 2013]

What you know and what you do is an important part of being you. Often it is required to rethink: What do I know? What are my skills? How strong are they? It can be about you personally, or it can be about your organisation or testing unit. I have used the below approach in the context of identifying “testing competencies” among 120 testing professionals and in relation to my own skills in times of refocusing.

Acknowledge the level of your skills

First let me tell you about the skill of tying a square lashing to connect two poles of wood. It is a fundamental building block of the scouting activity Scout Pioneering. Tying together poles let you build all kinds of scout camp equipment: tables, benches and other constructions.

To make a square lashing you tie a loop knob around the first pole. The rope is then taken around the two poles, crossing them first one way and then the other – thus making a cross diagonally across the poles. The end of the rope is tied to the other pole using a specific fastening knot.

I have specifically selected this to find something that you have probably never heard of – to illustrate how to approach skill levels. Prior to reading the description and seeing the illustrations you probably never heard of it, you were at level 0. But after reading about it, you have at least heard about the term – or perhaps searched the web for it. From here (Level 1) you need training and mentoring to tie any of the knots. When you can tie a square lashing without help – independently, you can up your rating one more level (2). Later on by writing books about lashings and knots, you can become a mentor, a trainer of others (Level 3). Ultimately you may master the skill at level 4 – you wrote the book, but also studied the craft to know where even the books are insufficient.

This 5 level rating of skills is nothing new, and perhaps you use a rating with more or less steps in your context. Perhaps it’s very detailed, with very discrete steps – or perhaps it’s just a guideline, a floating value between “a little” and “a lot”.

If it squeaks it will hold

Yet even master builders forget to keep the skill alive. For doing the square lashing and riding a bike, it’s usually up and back on track in a few rounds. Some of the tricks come back quickly, others require a hint or a “now – how did we do this” moment in order to recall the theories and practices. There are various means of doing this within the software testing field and elsewhere:

Heuristics: In the Rapid Software Testing course the term heuristic is introduced, as a fail-able method to aid in decision-making. Scout pioneering have a very used one: If it squeaks it will hold. That is applying pressure and weight to the lashing, if the lashing makes small noises it will usually hold.

Backtrack: Another way to get back on track in skills formerly used (at levels 1-4), is to step one level down. If you used to write the book on the topic – practice. If you knew how to do it confidently and individually – ask for help and training. Scout pioneering builds constructions in triangles; they focus on building a solid base first. Returning back to basics, and building a good base in software testing is equally important.

Just Do It: Jump onto the bike and learn. There is a learning curve building back skills again – it might as well be tested, tried and experienced. My experience is that recalling knowledge will come back instinctively and faster than expected. It doesn’t matter so much how long ago it was. As long as the brain is stimulated, it will come back instinctively. If the brain gears start squeaking – it’s usually a good sign.

Recognize and Organize Your Skills

In Scout Pioneering as well as software testing, there are many heuristics – and many areas of detailed knowledge that can be learned: Knots, techniques, theories and applications. These are the competencies and the skills – and we have to name them in order to manage and develop them. It is important to find out what we know – what we know as a company, group and personally. We live in an age of abundance of information – the key driver of introducing knowledge management systems is to find out “what we don’t know we know”.

[WayBackMachine: https://web.archive.org/web/20131109225946/http://www.ministryoftesting.com/2013/06/recognise-and-acknowledge-your-skills/]

clove hitch

Look for Minimum Viable Testing

How much critical mass will the product/project/service need to allow for (software) testing?

Recently I participated in a local “coffee shop meet-up” along with photographers, coaches, entrepreneurs and start-ups. We could agree that coaches as well as testers give indirect value to the business – but while staff coaching could be individually sold to carpenters and hairdressers – (software) testing could not. Afterwards I challenged my self to think otherwise!

Good testing is an information and exploration activity – to find risks and present information to the stakeholders. Usually it’s easy to find the known risks to entrepreneurs – but good testing can test for unknown unknowns – even if there is no product or “just” a minimum viable product:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The definition’s use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

Similarly minimum viable testing is an effort, that allows the team to collect tacit and explicit learning about the solution, given the context. Go look for it in your context – Testing can add business value to any project state

tractor

Related: Acceptance is more than what can be measured , You call that testing – how can that add value,