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.

16 points that may rock the boat

8 Things You Don’t Know Are Affecting Our Choices Every Day: The Science of Decision Making ]

  • Why we accept the default choice
  • Why we make worse decisions over time
  • Why we make better decisions in the morning
  • Why we make better decisions in a foreign language
  • Why being hungry is bad for decision-making
  • Why a full bladder helps us make better choices
  • Why ventilation is important for good decision-making
  • Why leaning to the left affects your choices

8  Qualities Of A Truly Loyal Employee ]

  • she displayed the highest form of loyalty by helping you avoid missing the “do the right thing” forest for the “do it right now” trees.
  • they ask the questions or raise the important issues when others won’t.
  • Employees that praise and recognize others, especially when it’s not their job to do so, don’t just display great interpersonal skills.
  • Weighing the positives and negatives of a decision, sharing conflicting opinions, playing devil’s advocate… disagreement is healthy. It’s stimulating. It leads to better decisions.
  • when you’re loyal, every decision is, ultimately, your own.
  • truly loyal employees realize that while you may not like what you hear, ultimately you want to hear it because what matters most is doing what is best
  • Well-intended silence can be a good sign of loyalty; speaking up, especially when it’s awkward or even painful to do so, can be the best sign.
  • they help you prepare to fill the hole they create.

Related Can you help me? , In a star team – the team gets the starsEven a self-acclaimed guru breaks the rulesEstablish yourself as an expert or thought leader I know it is your job – but thank you anyway

Learn to think like a business

The Evolving Skill Set of Tomorrow’s Top Testers | Scott Barber | Ministry of Testing ]

it is a career-limiting mistake for testers to ignore opportunities to develop a sound knowledge of how businesses operate and the skills necessary to ensure that testing supports business decision making.

 It’s not the job of a tester to make quality-related decisions. That’s what Project and Product Managers get paid to do. Testers should be focused on identifying the business risks that managers need to be making decisions about.

 If lots of bugs are making it to our radar it makes us think that someone isn’t doing their job. What we care about is mitigating risk while delivering a salable product as quickly and cheaply as possible. Time and energy spent dealing with bug reports detract from that goal.

We need information to make high-level business decisions. We need to know “Are we on track to deliver what we promised when we promised with acceptably low risk?”

When times are tight, businesses take more risks. Sure it’s risky to ship software that is under-tested, but it’s less risky than running out of money before anything gets shipped due to the additional time and expense of testing.

Seek to understand what makes businesses successful. Learn to think like a business executive (at least sometimes) when you are testing. Understand business risk management and the reality that as a tester, you are a cost center, not a profit center. No one (in their right mind) wants to have to pay for testing – sure they want the information, but they’d rather not have to pay for it, so you’ve got to make sure that information is valuable in their eyes.

IMG_0306

Related: Align conference selection and business strategyPragmatic choices of what is important and possibleLook for Minimum Viable Testing ,

Value of Information for Decisions

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

Value of Information for Decisions

If you ask “what is the ROI of context-driven testing” it is the same as asking:

  • What is the value proposition of providing information to the stakeholders?
  • Will management and customers pay for information?

Let me tell you a story: Just today I finally got around to changing tires on my car. Three months ago I bought a campaign voucher for a cheap switch of winter tires to summer tires – so it was about time. I booked a time and went to the shop with the summer tires in the trunk. BUT then … the front tires where out of shape due to wrong “tracing”, brake cables and other stuff worn and empty for lubrication. sigh!

So … the shop had to repair those critical defects (yeah, the vouchers a good business generator, #I’mOKwithThat). They gave me the keys to a replacement car for the day for free. And we discussed fixing some other stuff – the tricky ignition was Deffered/FixedUpStream but the defective brake lights added to the work order (New bug raised due to a hunch). I got an estimate and went for the day. The quote was pretty close, the repair on time and the requirements verified on the release bill. 

And then they provides me with a list of a few things they noticed along the way. 

  • I probably paid for an automated test and configuration of a “trace” balancing – I assumed it there.
  • We did discuss scope, price, schedule and timing – along with bug triage
  • The shop did provide me with enough information and estimation up front to base my decisions on
  • As the product owner I did not pay directly for the list of test ideas not covered – but I appreciated it!

The shop could have just swapped the tires for the voucher cost – and noticed nothing else. They could have chosen not to tell me about the additional bugs. They could not have offered me a replacement car for the day. They probably where more expensive than a moonlighting garage dude – I known now what the difference can be.

I value that they provide information to aid my business decision-making – besides just swapping the stupid tires. They will probably get repeat business from me – directly or indirectly. 🙂 And yes, Scott, they did have free coffee

Come join the Context Banquet

We are setting up Dansk Workshop on Exploratory Testing (again) inviting testing people to join the banquet. We all test the software, the hardware, the context, the project, the environment the performance, – to give the decision makers information. We need testing people to have all kinds of backgrounds

| This is what the C-D-T is about |  Also know as the exploratory testing and the muh muh |  further more know as a jam |

Let me tell out about the invitation to the Context Driven banquet in another way: There once was this man who had a great fortune and many talents – and wanted to celebrate. He walked to his friends to invite them to come for the fiesta. One friend just landed a new job – but she was not yet as equal as the others. Another just had a new minivan, and had to test drive it (pun intended). But there where room for more at the banquet – so the invitation is sent to the insecure, to the un-educated, to the start-ups and the emerging thinkers, to the bloggers and the twitters, the black swans, the unicorns and the dancing monkeys….

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,

3D model for testing contexts

If software testing is solely about finding bugs, I would do nothing else to hack, break and attack the solution. In one context the testers job is to “positively destroy” the solution. Taking this to the extreme – this contradicts with the shared purpose to deliver value to some one“. If the context require that the tester is not allowed to report errors (#bad, but it happens) – that contexts is also not good taking to the extreme. If the acceptance criteria is that X severity bugs can be released, gaming the play will leads us not to look for them.  Where does your team score on the Bug hunters dimension

Bug hunters dimension
Mission: Break the solution
Mission: Confirm solution

In a Rapid Software Testing situation, testing is on the spot, with the given information at hand within a short time frame. I could imagine that a lot of mobile app development projects have very few formal/informal tests besides: “Does it work – then ship it“. Enterprise settings and medical systems need a higher degree of conformity to contracts, standards, certifications and FDA approvals. Where does your context score on the Exercise dimension:

Mission: Skipping Mission: Deep-dive
Mission: Skipping
Mission: Deep-dive

A lot of testing contexts have the job to verify the solution. Given so and so requirements, so and so predefined charters, testcases, scripts … verify that the thing works as predicted. To solve this problem brawn is usually enough, tasks are broken down and systematically applied (machine checking). On the other end of the scale is a more learning context, where sapient tests trigger exploration based on brains. Where does your context score on the Thinking dimension

Mission: Verify Mission: Learn
Mission: Prepared
Mission: Explored

When you start considering these dimensions it’s easier for you to get to the what, the where, the whom and how much. In some contexts the sliders are not easily moved. But even so consider to apply a bit of the dimensions in the various phases of your software testing – scoot over the application in “gold master testing” and snow plow testing. Verify and learn, test and check, break and confirm.

[ Rob Lambert | Thanks for the information, I’ll make up my own mind though ]

As professional skeptics we need to make up our own minds and come to our own conclusions. That should be done using any supporting material we can, but ultimately from our own information, decisions and activities

Please make your own model – what 3 dimensions characterizes the testing in your context? 

See also:

Without Timing – Quality, Schedule and Cost is nothing

A project usually has to be on target on Quality, or at least on agreed quality. 

A project usually has to be on Schedule, or at least on agreed schedule.

A project usually has to be on target regarding Costs, or at least agreed costs.

It is an ancient IT project manager mantra, to control these parameters using change requests and change management – typically due to events during the project. It takes to long, it’s too buggy, it costs more etc. etc. To change one parameter – you have to change one of the others. In example (and strictly in some context) – even adding more testcases will increase cost or influence the schedule (discuss).

But there are plenty of examples (of Government IT projects) that are on schedule, on cost, on quality – yet they fail the timing and after a number of years delivers a system on an obsolete platform [true story]. More recent examples – bank D launches their banking app first, get all the press – and a month later bank N comes around – on agreed schedule, agreed costs, agreed quality… and get very little of the “hype”.

When contemplating the business decisions – what seems right now right now might be wrong later – considering the Timing.

4triangles

Acceptance criteria are more than what can be measuredAn Expected Gathering

I’ll fix this later 🙂