The Wrong Questions

I was in a management meeting with a traditional client last year. They have a very ingrained top down culture.  They were in what I would term the first stages of Agile transition.   Mini Waterfall, Stage 1 Agile, Immature Agile or Wagile.

There were questions which seemed to illustrate the traditional way of thinking Vs current ways of thinking.

Project development was overrunning, nothing had come through to test for over 6 weeks. They had 30+ testers waiting  … a question was immediately asked by a senior manager “So what have the testers been doing?”

To which I responded ‘I don’t think that is the correct question – what we should be asking is how do we get things through to test more effectively’

Other statements included asking for an over abundance of metrics – The illusion of control.  ‘We need to assign clearer individual Roles & Responsibilities’ – Counter to an environment that promotes team thinking.

Straight away the focus seemed to be immediately on the effect (people ‘doing nothing’) and not on the root cause (the project mechanisms).  Keeping people busy does not mean the project will be more effective.  There is a tendency of personnel to concentrate on the micro and not the marco project efficiencies.  Silo mentally promotes this thinking.

This case illustrates some of the fundamental differences between the old world thinking and new world of Agile approaches.  Asserting top down micro control in preference from bottom up thinking simply isn’t as effective.

Test should not be a segmented actively which is passively disjointed from the development lifecycle.   Test should seek to understand the engineering process, engage and attempt to embed their practices within.

Test should seek not to be test, but seek to become a QA function.  To me QA is embedding test practices into every stage of the lifecycle, seeking to prevent issues and resource inefficiencies leaking into subsequent stages of the lifecycle.

This is done by reducing the time latency effects within project and ensuring shared understanding of requirements.  See QA Bridging theory for more detail.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s