Skip to main content

Project Inception: The Forgettable Mnemonic



This blog is designed to help me to remember the thing that I'd created a mnemonic about, so I didn't forget. I did forget it, immediately after presenting on the topic. So, writing it down should help.

So, when you want to kick off your project in an expedient but sensible manner try my charming mnemonic, IWOOWI (pronounced I-WOO-WI):


Iterate, Man! 
If your engineering iterations are two weeks then limit your project inception to that period too. There is an excellent chance that more thinking than this will only ever beget more and more thinking at this point.



Who Feels What About Which or Whom and Why? 
I know, this is awkward as you'll need to ask about feelings. Let me put it this way, how many rational decisions were made on your last project? Humans are inherently irrational, place no expectations of sensible decisions on your stakeholders. Discovering how they feel about a feature/deadline/other stakeholder is more useful information than what they know. As it will be what they think they know.


Obvious? 
The software development world does so many things which don't have an obvious reason why they should be done. Not every reason is obvious. Being non-obvious is sign. When the bus is about to run us over it is obvious that we should take evasive action. If your project/product has no obvious reason for existence, ask the question.



Optionality 
In the beginning you will meet those who wish to confirm, finalise and nail down each and every aspect of your project. It is a tempting thought. Until the entropy of time gets involved. Resist these nail-downers and approach your project kick off with a view to increase your options, not narrow them.
Why is this so hard? - If your project kick off is unforgiving, then what you shouldn't do is doggedly push on with your plan to get under way, you should ask the question of why this is so. Perhaps some of the previous parts of this mnemonic are in play, most likely your stakeholder engagement is not what it might be or the critically important project that you are about to embark on is not, well, all that important.



If stuff built > 0 && {insert kick off document name} !signed off 
This test provides an examination of how effective your current process really is. If the kick off document that you have slaved over is still awaiting a rubber stamp 10 weeks into the project, I think you know how keen your stakeholders are on both your project and the way you've handled the kick off phase.

This mnemonic summarises (for me) the key to an effective project inception, setting the tone and direction of the humans involved. Technology and process plays a part but I believe (and experience tells me) that your humans having a similar vision at the same time is crucial for successful delivery.

Comments

Popular posts from this blog

A Lone Tester at a DevOps Conference

I recently had the chance to go to Velocity Conf in Amsterdam, which one might describe as a DevOps conference. I love going to conferences of all types, restricting the self to discipline specific events is counter intuitive to me, as each discipline involved in building and supporting something isn't isolated. Even if some organisations try and keep it that way, reality barges its way in. Gotta speak to each other some day.

So, I was in an awesome city, anticipating an enlightening few days. Velocity is big. I sometimes forget how big business some conferences are, most testing events I attend are usually in the hundreds of attendees. With big conferences comes the trappings of big business. For my part, I swapped product and testability ideas with Datadog, Pager Duty and others for swag. My going rate for consultancy appears to be tshirts, stickers and hats.

So, lets get to it:

3 Takeaways

Inclusiveness - there was a huge focus on effective teams, organisational dynamics and splitt…

Wheel of Testing Part 2 - Content

Thank you Reddit, while attempting to find pictures of the earths core, you surpass yourself.
Turns out Steve Buscemi is the centre of the world.

Anyway. Lets start with something I hold to be true. My testing career is mine to shape, it has many influences but only one driver. No one will do it for me. Organisations that offer a career (or even a vocation) are offering something that is not theirs to give. Too much of their own needs get in the way, plus morphing into a badass question-asker, assumption-challenger, claim-demolisher and illusion-breaker is a bit terrifying for most organisations. Therefore, I hope the wheel is a tool for possibilities not definitive answers, otherwise it would just be another tool trying to provide a path which is yours to define.


In part one, I discussed why I had thought about the wheel of testing in terms of my own motivations for creating it, plus applying the reasoning of a career in testing to it. As in, coming up with a sensible reflection of real…

Getting started with testability

At TestBash Netherlands, I said that, in my experience, a lot of testers don't really get testability. I would feel bad if I didn't follow that up with a starting point for expanding your mindset and explicitly thinking about testability day to day, and making your testing lives better! 

In large scale, high transaction systems testability really is critical, as compared to the vastness and variability of the world, testing done within organisations, before deployment, is limited by comparison. We need ways to see and learn from the systems we test where it matters, in Production.
Being able to observe, control and understand is central to testing effectively, and there are loads of resources and experience reports out there to help. I was/am inspired by James Bach, Seth Eliot, Matt Skelton, Sally Goble, Martin Fowler and a little bit of PerfBytes/Logchat, so lets see if it works for you! 

Overall Model:

Heuristics of Software Testability by James Bach

http://www.satisfice.com/tool…