While looking for advice on improving my critical thinking, I came across this article -

http://www.csse.monash.edu.au/~ctwardy/Papers/reasonpaper.pdf

Interestingly, there are a bunch of tools listed here that claim to help with the technique of argument mapping. I haven’t had a chance to try any of these yet. Hopefully, encouraging others to check them out will yield feedback faster than trying them all on my own!

Links to experience reports would be most welcome.

I came across someone asking for an answer to the old “How do you test a stapler” question, and in light of my new role, I thought this was a good opportunity to start taking up James Bach’s methodology challenge, using the stapler example as a starting point.

I’m starting with the meta-questions, those which I need to answer *before* I can begin to think about what and how I’m going to test it.

• Who is the stapler for? Who is it *not* for?
• Why do they want a stapler?
• How might the different stapler users know that the stapler has fulfilled their needs? What stapler features are unimportant?
• When does it need to be tested by? What will happen if it’s not done by then?
• How much can I spend to test the stapler?
• Who else can help me test the stapler?
• Does it need to be tested by anyone else before it can be considered ‘ready’?
• Does anyone else need to check the stapler, or approve my work before the stapler can be used by the person who wants the stapler?
• Is there anyone who doesn’t want the stapler to be had?
• What tools am I allowed to use to test the stapler? What tools do I know how to use that might help?
• Who might need to test the stapler at a later date? Who is going to read my tests? What documents do I need to create? Where do they need to live?
• Who shouldn’t be able to use the stapler?
• How critical is the success of the stapler? What might happen if it isn’t tested adequately, or fails to meet the needs of the stakeholders?
• Are there any standards our testing needs to comply with?
• Are there any legal constraints?
• What kind of staples does it need to work with?
• What kind of materials should it be able to staple?
• Does it need to work in conjunction with anything else?

I’m sure I will continue to add to this list and organize it, but it’s a start.

I’ve also found I need to develop a checklist to hit the ground running and ensure that I look far enough forward when my involvement with a project begins. For this, I’m grouping some questions under the heading “Start from the end”. This is a subset of the above questions, but are the questions I think I’m most likely to leave until too late if left to my own devices.

• What does success look like?
• What are the release processes/signoffs? Who are the stakeholders who need to sign off?
• When does it need to ship by? What is depending on it being released on that date? What else does our product depend on?

And so, it begins. If only I’d started earlier!

I’ve shared some ‘perils of XP’ conversations with Michael of late, so I wanted to consider my experiences on the topic.

One thing that strikes me about software methodologies is that like many things which are written down, recorded and/or institutionalised, the reasons are often long forgotten. The early adopters are typically passionate, thoughtful, and (I believe) seeking to solve a very specific problem.

Those that come to the team later may learn the practices that the current team is using, but never understand the problem that those practices are intended to solve. Indeed, the existence of the practices may cause them to never witness the problem at all. This may then lead to the Routine behaviour that Michael describes.

I’m also thinking that while writing down our values and principles as a guide for others is helpful, it may be more helpful to explain the journey that led us to our current thinking. Of course, we are usually slow to learn from the experience of others. I’m not yet sure how we instil just enough fear and understanding into those who haven’t experienced the pains of yesterday, but it seems like an important thing to do.

Before applying any software development approach (or modifying an existing one), it might help us to ask a few questions -

- What problems are we trying to solve?
- How might all of the team members best work together to solve these problems?
- How will we know if we’re succeeding?

- that you’re going to get it right first time.
- that nobody knows better than you do.
- that it is going to be faster if you do it all at once (tightly coupled to the first point).

Another possibility might be that you’re afraid of negative feedback, which, in the context of working on a software team, is delaying the inevitable.

I’m sure there are more possibilities.

Problems with our assumptions

That you’re going to get it right first time

How might we behave if we assume that we are not going to get it right?

That nobody knows better than you do

How might we behave if we assume that everyone might know something we don’t?

That it is going to be faster if you do it all at once

How do we know that ‘faster for me’ is necessarily faster for the project overall?

Jon Eaves was blogging about problems related to development goals not aligning with business objectives and it resounded with some thoughts I had been having on company values.

In addition to goal alignment, I’m thinking at the moment that alignment of values is equally important, or at the very least it helps when the true values of the company are clearly stated. Goals tell us where we want to go. Values help us make decisions along the way.

While individual values may vary from the company’s, by being conscious of our own goals and that of our employer’s, we can discuss the differences, or at least see just how wide the gap is between one’s own values and one’s employer. I think this is a good starting point.