Philosophically, I’m aligned to the context-driven testing view of the world. Largely, this is influenced by a very early awareness of contextual factors to success in my first job, and the wild difference between games testing and corporate testing roles that I had. Since 2003, the work of the context-driven school founders has been a significant influence in how I speak about testing.
In 2004, when I worked on my first agile project at ANZ, I was lucky to fall in with a group of developers and analysts who were skilled and keen to solve some of the problems we had in enterprise intranet projects. A huge piece of that was using agile ideas to solve *our* most pressing problems, not all of the problems that enterprise had. To do that we aligned the corporate project management practices and rules to more general principles, and then set about satisfying the principles in a way that met our other objectives (the main one being to make it cost less than $30,000 to put a static page on the intranet).
Another question that came up was how we might move away from a rule-based governance framework to one that was oriented to principles and context. The meat of this blog post is the result of how that initial idea connected to my context-driven approach. It then turned into a model for project context. It was also spurred on slightly be the over-simplification I perceived in the commonly used agile project sliders – Cost, Time, Scope, Quality (though Mike Cohn has a somewhat improved version, and reminds me I should finally read that Rob Thomsett book Steve Hayes recommended).
This has hidden in my blog drafts for a good seven or eight years. It is intended to support my test/delivery strategy mnemonic, though both are useful independently. I’ve recently started sharing it with my testers and colleagues, so I feel it’s time to open it up to the world for review.
The usual caveat applies, that this is a model that works for me. If you find it helpful, I would love to hear from you. If you improve it or change it, I’d love to know about that two. Here are a few ways I hope it might help:
– To help us and other stakeholders consider elements of context that require us to assess the suitability of our standard approaches.
– To help ensure stakeholders understand that each piece of work they undertake is different in subtle but important ways.
– To help ensure that the test/delivery strategy/approach is reasonable.
– It may help us to create a record of project characteristics that we could search for stories about projects similar to the one we’re undertaking now.
This is rough, but given my observations of the context-driven community and software development in general, getting this out is more important than polishing it. So here is a model for context, intended to be put up somewhere visible with associated sliders:
Time to Market/Time constrained/Time criticality
A scale that indicates how time critical this piece of work is. That is, how bad is it if it takes longer than expected?
Business Risk
A scale that indicates the likelihood of failing for business reasons
Technical Risk
A scale that indicates the likelihood of failing for technical/technology reasons
Complexity
Is this inherently complex?
Size
Similar, but different to complexity. A big system with simple functions brings its own challenges.
Novelty
How well understood is this problem? Have others solved similar problems before?
Value ($)
What is the size of the benefit?
Team Size
How big is the team?
# External Stakeholders
How many of the stakeholders are not within the same management structures (eg. Subject to shared KPIs)?
Interfaces (external, internal)
Are there lots of interfaces to this product?
Cost/Budget/$ Constrained
How significant is the impact of spending more than planned?
Criticality (failure impact)
How bad will it be if this fails in production? (Max is life/safety critical)
Priority
How important is this relative to other projects in the organisation?
Scope/Feature constrained
How much opportunity is there to vary the scope of what is delivered? Fixed scope translates to risk if other things are constrained (especially time and budget).
Dependencies
Is everything required to solve the problem within in the team? What things/people/knowledge that are needed to deliver are shared or external to the group?
Feedback cycle time
How quickly can you get feedback on questions regarding the product? This includes how quickly and how often you can test, as well as how long it takes questions regarding direction of the solution to be answered (eg. Availability of product stakeholders).
Communication bandwidth
When you are able to communicate as a team, what is the quality of that communication? Is it limited by technology, language? Offshore teams are frequently low feedback, low bandwidth communications.
Communication frequency
How often are you able to communicate with the team? Subtle difference to feedback cycle, in that someone may be able to quickly provide answers when available, but not very often.
Time constrained?
How fixed is the schedule? What is the impact of overrunning the planned completion date?
Team cohesion/familiarity
How long has the team worked together?
Team experience/maturity/skill
Has the team worked on this domain for a long time? Is there broad experience of different ways of working? Is the team strong technically?
Compliance requirement? (Note that this is not a slider, it’s a checkbox)
This can arguably be modelled using other properties, but may be worth flagging separately when a project is something that must be done.
Additional contributors:
Thanks to Shane Clauson for prompting an addition to this model last week. Thanks to Vito Trifilo for cooking the barbecued ribs that brought me and Shane together!
