The final stage of preparing for an interview is to come up with an agenda and preferred set of questions.  In some cases you might use a very detailed and structured approach, while in others you might not spend any time preparing your questions.

Either way it helps to have an overall structure for an interview and one approach you might try for this is to use “FOC” or Frame-open-close. You can use this approach when preparing for an interview or you can use it without any more preparation as the interview starts.

Open and closed questions

Closed questions are those that require a short answer that is generally something the stakeholder could choose from a list (ie they have a finite or closed set of possible answers to choose from).

Closed questions include:

• Is that true? (Choose yes or no);
• What time did you get home? (Choose a time); and
• How many people went to the restaurant? (Choose a number).

Closed questions are good for restricting the answers you get. They limit the stakeholder to providing the specific information you want. But they also restrict the stakeholder from exploring or explaining a topic.

Open questions are the opposite. They provide the stakeholder with an infinite or open set of possible answers to choose from.

Open questions include:

• What happened?
• How did you do that?
• Tell me more about the issue (a statement that leads to an answer).
• Why did that happen?
• So what – what impact will that have?

Open questions are good for gaining an understanding of the subject matter and for exploring a topic in detail.

Framing the question

Sometimes an interview might feel very “stilted” or fragmented. The interviewer asks a question, the stakeholder pauses and then gives a vague sounding answer and then the interviewer pauses before asking another, unrelated question. It may seem to the interviewer that the stakeholder was reluctant to provide information while to the stakeholder it seems to be a disjointed and uncomfortable experience.

Where this is the case it may be that the interviewer is asking good questions but is not providing any context or structure to help the stakeholder think about and respond to the question.

For example, let’s assume that Steven grew up in Melbourne Australia. His family owned restaurants and he often worked in the kitchen after school.  He is now publishing a cookbook that includes a lot of the recipes he learned growing up.

An interview could flow like this:

The interviewer might get better answers if he or she asks open questions. But even then, the questions might come out as disjointed or unconnected, making it hard for Steve to answer without having to stop and think about each question.

On the other hand the interviewer could frame the conversation with a short introduction and then ask a simple open question:

Framing the question like this gives Steve a context within which to understand the question and also helps both Steve and the interviewer to create more of a flow in the conversation.

FOC – Frame – open – close

FOC or Frame-open-close is an approach to creating a structure around the questions.

It is often better to ask an open question to open the topic up for discussion and then follow on with a closed question to confirm that you understood what was being said. So it is common for experienced interviewers to deliberately plan an interview around open questions, which are then supported by closed questions to confirm or clarify your understanding to the answers given to the open questions.

Rather than just asking a question though, you can start by providing a short statement (or “frame”) to prepare the stakeholder for the type of question that will follow. Just as a picture frame is designed to help the viewer to focus on the picture, a frame in an individual helps the listener to focus their thinking on the question being asked.

This then gives you a pattern to follow:

1. Frame the question with a short statement to give your stakeholder some context.
2. Ask one or more open questions to explore the topic.
3. Ask closed questions or summarise what the stakeholder said in order to confirm your understanding before moving onto another topic.

FOC as an agenda for the interview

Just as you can structure your questions around a topic area by using FOC, you can do the same for the agenda of your interview.

This will at least give you a structure for the interview.

• You will start by framing the whole interview with an opening statement and then you will ask a series of questions.
• Your main questions will be open questions to allow the stakeholder to give a more detailed explanation than if you asked all closed questions.
• Finally you will sum up the interview by running through a summary of what you learned.

But of course for each open question you can also use FOC to create context and confirm your understanding of each major question or topic area.

For a more complex interview, you may find that the GRIFT approach (explained above) can provide the content you can use to create an introduction (or frame) for the whole interview.

The interview may also cover a number of topics that each consist of a number of questions and also justify an introduction (frame) and summary (close) to support those questions.

Similarly, a complex interview will often end with a list of action items as well as a summary of what was covered in the whole interview

The FOC approach can therefore be scaled up to give structure to the agenda and then scaled down to give structure to the individual questions.

In practice I often also use my “question compass” to explore each area.  I do this by using a structure like this

(new topic – frame): Which brings me to the question of how you incorporate ethereal conductive cooking into your recipes

(open – question compass): What do you mean by ethereal conductive cooking … etc

(Close) So ethereal cooking is a key part of what you do. (next topic)

Question tennis

One of the best scenes in the play is when the two characters play a game of “question tennis”. It is worth watching this short video if you haven’t seen it.

http://www.youtube.com/watch?v=fGEYFE7e_R8

The idea of the game is to keep asking questions so the conversation is always in the other player’s court. So each player must answer every question with a question. If they mistakenly answer with any other response then the other player wins the point.

But how does this relate to being a BA? Well, this is where I think a lot of BA’s run into trouble.

Questions in stasis stay in stasis

It is very common for a BA to ask a stakeholder a question the stakeholder does not know the answer to.  Then the stakeholder leaves the question for the BA to answer, but the BA does not know the answer so he or she parks it to be answered later.

But of course the question will not get answered since nobody is attempting to answer it. So the BA needs to learn to hit the question back to either the original stakeholder or someone else.

So when the BA hits a dead end then he or she should respond with “who can help with this?” then they should formulate and pass on the questions they have as soon as possible. Otherwise the issue seems accumulate more related questions until the BA ends up in a state of temporal stasis (ie they are frozen in time).

Questions with inconvenient repercussions lead to infinite delays

Many questions result in people finding out that they will have to make a trade-off between to related desires. But humans hate making trade-offs to they will subconsciously answer inconvenient questions with vague responses, general discussion points or responding questions.

Unfortunately, since the original question started to unearth some things people want to avoid, the vague responses will sit with the BA until the issue becomes urgent and then everyone will wonder why the BA is not doing anything, while to BA will think that he or she is waiting for more concrete information from somebody (or several people).

Once again the best thing the BA can do is hit the question back quickly. In this case the best solution is probably to ask very concrete and specific questions that will allow very little wriggle room.

The stakeholders will often respond vaguely two or three times in a row but persistent, concrete questions will eventually lead to the right outcome.

Interesting points

Often when a question is asked, a stakeholder will respond with “That raises an interesting point” or “I guess the real question is …”

Of course in both cases the response is not really a response to the questions but rather a potentially new question. So the best thing the BA can do is to immediately ask a question back, either to come back to the original issue or to explore the point just raised. Failure to do so will leave the ball sitting in the BA’s court.

In all cases

In all these cases and many more you might be able to think of, the best thing the BA can do is to ask clear questions of specific people as soon as possible when a question bounces back on them.  They may need to hit the question back several times, or even redirect it several times, but failure to come back with a questions means the BA will start to come under pressure to find the answers what people assume are outstanding questions.

It may be true because I love to understand puzzles and problems. Perhaps it is true because I do enjoy playing those corny puzzle games on my outdated nintendo gadget even though I have no time left in my day and even have access to far more sophisticated games if I want to try them.

So maybe what follows is good advice or maybe this is my own bias.

I recently saw some great proposals for small projects and some pretty decent requirements. I could understand what people were proposing and even who would be using the solutions we were providing. And my advice each time was the same – “we are clear on what we are doing but not really why”.  In response people told me we were doing it because these customers want it (our team, people who purchase our software etc).  When I then asked why they wanted it, the response was “so they can …. ”.

They can do (what our requirements say) but that is repeating what their requirements are, not explaining why they have them or how we know those are the real requirements.  So I generally asked why again and got a reasonable response:

• They told us they want it; or
• We can see them doing it now (or having that problem now).

Maybe this is enough – if people want it and they will use it then isn’t that why we build solutions?

Unfortunately the intellectually pure part of me detects more of a puzzle to wrestle with, so I am hassling people for one more piece of information – What specific problem are the users/customers going to solve?

Most of the time the answer I get is the same – the problem they are solving is that they want to do this.  But I am still trying to work out what difference that make to them.  They are doing this so that (something is better) but what is better?

The answer I get is often that they can sell more stuff or do things faster.  But I still think there is a missing link and this is what I am wrestling with.

This is the requirement … it is for this specific user.  They want it because it will remove a problem or allow them to do something new

… but what is that thing and why do they want it?

So here are my new questions

1. Who is this for?
2. Why do they want it? Cool is that the real problem they have or is it a symptom of the problem?
   1. People often deal with symptoms of underlying problems, without really knowing the real problem.
   2. For new solutions people often ask for “accomodations”. An accomodation is a solution that is needed to compensate for the weaknesses in their current solution. Fo example, “we need more spare parts” might be caused by the weakness that our existing spare parts are poor quality and fail too often.  More spare parts will help, but better would be to remove the need for more spare parts.
3. So what problem are they solving when they get this?  What problem will they still have?  is this second problem the one we
4. Do they know they have that problem? how important is it compared to other things? How often do they have the problem?
5. What solution do they have in place at the moment?  (I know they don’t have this thing yet but they might have something even if it is hand-written post-it notes on their fridge) Have they tried anything else that hase faded away?
6. When we solve this problem, what happens next?  What will they want next, what will their issues be with our solution?

Maybe I ask too many questions when we have already been told what they want.  When I send people off to ask more questions they often get the response that things are urgent and their questions are slowing us down – “we know the requirement already -so let’s get on with the solution?’

We know the requirements already – we need to move onto the how we will implement the solution.

But if we are focussed on providing a solution we should know what we are solving shouldn’t we? And even if we know what the requirements are – what are they the requirements for?

Maybe I would settle for this much (but i will still have more questions).  In the book “Four Steps to the Epiphany” they recommend these questions for early adopters of products

1. Who is it for?
2. What problem will it solve for them?
3. Is it already hurting them? ie are they aware of the problem and if so how important is it to them?
4. What solution do they have in place?
5. Do they have a budget to pay for the solution?

But even then I will secretely have one more question, I can’t help myself – Who will this not help? Or who might use this but won’t care too much?  Then rather than solving the generic problem for all our customers (and being “lot’s of customers focussed), we can solve a specific problem for a specific customer.

I am presenting to the IT people of the future on what agile is (and is not).

Here is their rather long link to the presentation:

http://www.acs.org.au/nsw/index.cfm?action=event&area=9001&temID=eventdetails&eveID=30229661985484

Come along if you are local and part of the group (or can sneak in).

Then I realised that work is actually a lot more like Star Trek than I thought it was, so let me explain:

The whole crew nearly die in every episode in Star Trek (we don’t nearly die each week, which is good).  Since they are in a starship, the Star Trek crew’s survival almost always depends on their ability to work with technology. But I guess the show would be a little boring if everything worked as planned:

Captain: Yikes – that looks like a rare Lithiam based ameoba that eats starships, we need to warp out immediately

Pilot: No problem, the engines are working well within their design perimeters.  We have escaped easily.

(end of episode)

We don’t see many episodes like this though, we see the ones where they are in real trouble.

Of course, since they are a great team, they never seem to get into trouble because of their own defects or technical debt. Instead they constantly run into problems that push their technology to places where no technology has gone before.

Again, we don’t get to see the episodes where other teams confront this problem.

Captain ”yikes – we are doomed unless you can get us out of here or blow the bad monster up”.

Pilot/product owner: ”I am trying captain but the system is not up to it. We can only go at warp 8 and the rare alien metabolism is sucking us back at warp 9.67″

Captain: “Engineers, can we get out of here at warp 10″

Engineer: “That is technically impossible”

Captain: “Oh come on – it looks pretty easy to me.  You just go as fast as now but then a bit faster”.

Engineer: “Sorry captain, technically impossible. But we do have a new Facebook interface we can show you as we die”.

Captain: “Oh OK.  I guess that’s it then”

(episode ends in chaos and mayhem as the crew get metabolised while trying to fix their Facebook interface before being eaten)

If you believe in Star Trek (some people do) then you must believe that a lot of crews die because they hit things that are technically impossible. But the Star Trek crew always seem to overcome the “technically impossible” problem.

Of course they are on TV and we live in the real world. But this iswhere I think our teams are a lot more like Star Trek that people realise. The product owner/sponsor asks for something hard so the team say it is “technically impossible”, after which:

• The team go off to work on other things while the evil monsters of deadlines and customer expectations slowly start to threaten the team; or
• A long discussion follows that takes up the whole episode (or sprint if you do Star Trek Scrum); or
• A passionate discussion follows, that involves some problems being put aside and others being tackled with the full creative force of the team.

What I have learned from Star Trek is that while they have room for improvement, their approach to technically impossible things is usually successful:

1. The engineers always say something is technically impossible, but it turns out that:
   • They can solve the problem some other way; or
   • They need the crew to do something to buy enough time to make it possible, which means it was not technically impossible, just “something we don’t have time for yet”.
2. The pilot does not just say to the captain “I am waiting on engineering” and the engineers do not just say “we are waiting on better requirements”. Instead they all get together and collaborate as if their lives depended on it. Every problem in Star Trek is a problem for the whole team.
3. After they collaborate they usually find out that they can solve the problem, even if the original request was ”technically impossible”. Somewhere near the end of the episode, the team say “we can’t do X, but we can do Y” or “If you can buy us this much time we can fix it” and then they all work together to survive in time for the ending credits.
4. They always experience a lot of drama and stress before they fix the problem. This seems to work well when there is only one monster to fight per episode … the whole crew of 500 seem perfectly aligned to the goal of “not dying today”.  Maybe though, their approach would not work so well if they have 2,3 or up to 10 monsters to fight every episode.
5. Every third or fourth episode the team see the wreckage of another starship where the crew could not be innovative enough or spent too much time fixing their Facebook interfaces while the real monsters came and killed the crew.

So from now on, I think we can say “that is technically impossible” as much as we want in our projects.  It can add a sense of drama and it is a cool sounding phrase.  But the result is always the beginning of a longer conversation because whether or not the solution is feasible, the problem is still there.

So maybe a better approach is to

1. Provide enough information to clarify whether:
   • We don’t know how to solve the problem – in which case we need to guess how long it will take to understand it;
   • We understand the problem but our technology will not allow us to solve it – in which case we need to estimate how long it will take us to research a solution;
   • We just don’t want to do it right now – in which case we should say “I would rather not” rather than “that is technicall impossible”.
2. Use this information to prioritise which things to work on, so everyone knows the biggest monster every episode (or sprint if you want to use Star Trek Scrum)

You might have a better format. But I think it would help if you search and replace your use of “technically Impossible” with this more mundane but potentially more useful approach:

1. This is my understanding of the problem:
   • I understand that you want to {something} so {something}. The problem we have though is that {something is wrong}. For example “I know you want to escape that monster or we will all die. The problem is that the engines won’t do warp 10″
   • This is why it is wrong . “The engines are only designed to do warp 8 because of you budget cuts in engineering last year you wally”
   • This is where it is wrong “the engines in the main ship can not do warp 10, so the while main ship is doomed”
2.  This is what we could do about it
   • Option 1
     • If we do {something}, it will take {a vague guess at the effort} and then
     • When {event}: {The system} will {something} if {conditions}
     • When {event}: the systen will NOT {Something} if {condition}
   • Option 2 (etc)
3. This is what I recommend. “Let’s use the life boats and ditch the ship” or “lets run the antimatter backwards so we can go at warp 11 for a day with a 20% chance of death”
4. What we need to decide now is “Let me know what you think of my summary”

So I guess I think my team is as good as the one on Star Trek, and yours might be too.  But even the crew on Star Trek could work a little better if they replaced “technically impossible” with the right information for a longer conversation.

Inteviews are pure twaddle

Controversially, he claimed that interviews are appalling and should be completely abolished … which would seem to be a strong position for a business analyst to take these days. But then Mark Twain was around at the beginning of last century and we have learned a lot since then. Maybe he just didn’t know any better.

Since Mark Twain’s time, we have invented computers and the whole IT industry. We even invented the term “the business” so we could blame someone else if what we built turned out to be stupid rather than brilliant.

Then we invented the role of the business analyst to make sure that we actually understood what “the business” needed, rather than just blaming them.

The business analysts came up with the obvious idea that they should interview people to find out what they want before we build things. We hope this will result in us building something valuable instead of just allocating blame when we do something dumb.

A century has passed since Mark Twain wrote the letter I refered to and given how much we have learned since then, can’t we just ignore his outdated views? Sadly I think he turned out to be right.

Mark Twain claimed that the written word and the spoken word are fundamentally different. He claimed that if you interview someone and write down what they said then you will produce twaddle . In fact he said:

“The moment “talk” is put into print you recognize that it is not what it was when you heard it; you perceive that an immense something has disappeared from it.

That is its soul. You have nothing but a dead carcass left on your hands”

Later in the letter he says he would not talk in his sleep if he could not talk better than the wording found in most (reported) interviews. He claims that to capture the meaning of what someone said, you can never merely write down what they said. In doing so you will lose all the meaning that they had in their tone, their body language, the conversation before and after the part you wrote down and so forth.

This is exactly what I have seen happen when a business analyst writes down what someone said and calls it a set of requirements. You are left with “nothing but a dead carcass left on your hands”.

A good author or (if they exist these days) a good journalist does not interview people and simply write down what they said. Insteadthe author collates information from multiple discussions and then interprets it and compares it to other information they have gathered from research or even their own analysis. Then they go back and confirm their understanding, not just of what was said, but what the implications are and whether what was said was what they stakeholder really meant.

In the same way a competent business analyst does not simply write down what someone said – even if they can do in in Agile stories, UML or some other clever form of stenography.

Rather, a competent business analyst does what the job title implies.  He or she analyses, interprets, validates and chalenges what was said. Through this analysis they discover  the meaning of what has been asked for and the implications of delivering it.  They can then go back and talk to people or write down what they understand – in a written form that is effective rather than “twaddle”.

In other words they write requirements and do not simply quote what people said without the “soul” or meaning of the conversation.

So I would expect the requirements written by a BA to be in a different form to “talking”, or I would expect the BA to go back and read what Mark Twain wrote.

If you agree with me then lets write good written requriements and have good spoken discussions and lets make effective use of the written or spoken word when we do.

On the other hand if you disagree with me then blame Mark Twain – it was him that said you write twaddle and produce nothing but the carcase of the conversation you are meant to be analysing. All I did was quote him. I actually think you are a nice person and not at all a murderer of requirements.

The key benefit of the approach is that you do NOT try to understand and prioritise every thing at once against everything else. Instead you break the problem down into very small pieces and move through each one methodically. You then come up with a ranking of the importance of each variable from top to bottom.

And the approach scales well. You can do it on your own or you can get a lot of people to use the process at once to form a consensus about what issues really matter the most. I have used the approach for everything from setting priorities in retrospectives to ranking the capabilities needed in a team to structure more effective training.

An example of where you can use it

For example, lets say you are working with a team of testers who work on projects across the whole organisation. They have been complaining about being unloved and their stakeholders are questioning whether they actually add value to projects.

You do a retrospective with the team to reflect on where they think their could be improvement and you have some meetings with your key stakeholders. As a result you find out that the team could get better at communication, team building, consistent tool use, work quality, knowledge of the systems being tested, working with the developers instead of against them, finding critical defects instead of just cosmetic things, problem solving, collaboration, good manners and a range of other things.

If you decide on one thing to fix then everyone will complain you are not fixing the rest, but if you try to fix everything you will not get anything done. Even worse, if the team don’t see value in what you are fixing then they will not help and you will fail. Even worse again, if your customers don’t see value then they will keep escalating and complaining about everything and you will be too busy apologising (or hiding from them) to focus on fixing things.

So you need to prioritise and here is where you can use stepwise programming.

Applying stepwise programming

The approach is simple. First you create a matrix with the items you want to prioritise listed in both the left hand column and the top row:

Next you start on the first row and compare the heading you put in the left-hand column with the heading you have put in the top row.

• If the variable in the left hand column is higher priority to the the one in the top row, then enter a 1. Otherwise enter  -.

For example I think it is important for the team to get better at both root cause analysis and collaboration. But if I had to choose between them, then I would choose root cause analysis. So I would enter a 1 in the appropriate field. I then continue through the first row doing the same thing:

Similarly, if instead of doing the exercise on my own I had my whole team of 6 people do the exercise I would get each person to complete the row separately and then update the table with the total votes that people gave to Root cause analysis compared to everything else:

So I could say that the team think getter better at root cause analysis is more important than getting better at collaboration and (unlike what I think) the team as a group believe that getting better at root cause analysis is even more important than using automation to improve testing.

But the real benefit comes when you have completed the whole table:

So you can see from the table that the team (as a group) believe the biggest benefit would come from getting better at root cause analysis. And if we could pick a top three to focus on then we would pick Root cause analysis, Collaboration and Use of automation.

The numbers may not add up in this table because I just made them up quickly. But even in the real world some people seem to vote that (say) root cause analysis is more important than collaboration the first time you compare them and the vote the opposite way the second time. To counter this, some teams only allow comparison once and then simply put the number (6 – 5) in the field that has collaboration as the left-hand heading and root-cause analysis as the top. But I don’t do this, because I think even that flip-flopping can help you get a better understanding of where the team feels the value is.

In the real world, I often use this technique when there are between 10 and 20 variables to compare. I find it a really good way to prioritise when I am faced with both intangible stuff (values and preferences) and great complexity (too many variables for my little brain).

Of course it does not tell you how to fix the problems, only which ones the group really think you should focus on first.

Interestingly it turns out the real world is harder and more ambiguous than the projects in my training slides

Having said that though, the fundamentals don’t seem to change. We have stopped a project and are about to restart. It is really urgent and we have inherited a project whose budget (in time and money) has already been spent. So we really need to get going.

But are we better off starting or are we better off getting our act together before we start so we are not “mistaking activity for progress” by rushing off in the wrong direction?

What I say in my training courses is to get the team together and brainstorm everything that needs to be in place before we start.  Then prioritise these ideas using MOSCOW and spend your first iteration (or sprint) nailing those stories.  Then if you have not done all the “must haves” then don’t start and if you have not done all the should haves then you know your next retrospective will include “should not have started before …”.  But with your should haves you can turn them into risks or tasks to do in the next iteration or two by dropping some stories to make room for them.

Great, I can’t fault the logic, but now I am in the real world and the development team is already off and running on some of the things they know need doing for our first urgent release, while some of the team are yet to arrive on site.

So here are the must-have’s I am applying.  Let’s see what happens.

1. Do we know where we are going?
• Do we have a Mandate to do the project? Ie
• Do we know the problem we are solving (yes). 
• Do we have funding allocated and not just “soon to be sorted”. (Yes)
• Do we have a complete backlog that the whole team understands (no).  Eek … do we know what to do for the first release? (Yes – we need to be ready to integrate some functionality for the other key project by the end of next month.
• Do we know our scope and priorities? (Yes-ish, er that is to say roughly yes) [which is probably the most dangerous answer of all].  (But we do know the scope for t he release in one month and we know our first priority is to hit that deadline subject to our other first priority of sufficient quality is mandatory).
• Have we defined success? Do we know what “good” and “fixed quality” actually mean? When is a story done? What non-functional requirements need to be meet to release? (Er No we are not really clear yet)
2. Do we know how to get there?
• Do we know what practices we are using? (Yes – we are stealing them from the project we need to integrate into).
• Really? Do we have planning and showcase meetings booked (yes). Do we have retrospectives and standups? (Yes)
• Do we know what technologies we are using? (Yes, except for some of the bits).
• Do we know who is doing what on our project? (We have a sponsor, a product owner, a scrum master, a BA, some developers and a project manager). Again – Do we know who is doing what? (They should do, they know their job titles, except the Scrum Master, I am not sure if we told him that he is on the project to the bitter [or joyful] end). In other words – We need to be clear on what they actually do. Cool – do we have an architect and a tester? (Long pause … oops)
• Do we have a test strategy that is understood by the whole team? (No).
• Do we have a publicly available risk register? (No but the PM is listing and discussing the key risks)
• Do we have a high level architecture that is understood by the whole team (coding standards if we want them, standard tools, guiding principles and of course a big picture on a wall or whiteboard of the context diagram and dataflow diagram (or domain model or strawman or something). (Yes-ish)
• Do we know the biggest constraint that is likely to inhibit our success? (Yes and no)
• Do we know the few things that really need to be done well and the other things that need to be done well enough to succeed? (sort of) What has to work for us to succeed and what has to be done really well? What will be forgiven and what will be remembered after the project is done? (er … yes)
• Do we have a road map of what is being released in what order, say epics per release? We have lots of stories and epics in Sharepoint, Jira and Version One. But we do know what needs to be done for the end of the month and we are consolidating to one backlog in the coming days)
3. Are we set up to succeed?
• Do we have the right people? (yes)
• Have we moved to one location (No – same planet but different countries)
• Have we cleared the decks of all other distractions (no – some of the core team are on other initiatives)
• Do we have real buy-in and trust from both the team and the business stakeholders (yes)
• Have we all worked together before (no)

The trainer in me is screaming stop. The enthusiastic optimist in me is calmly saying we have been here before and the crew is a good one so we will pull it off.

But the project manager in me is comparing risks against each other to pick the least worst (or should I say best) options. (I am not the PM on this project but I will sink or swim with him so my inner PM is talking loudly in my head).

So here is my current cunning plan:

• Get the test strategy in place before anything else.  Then make sure we have a technical scope and high level architecture diagram that we can show both the related project and the business customer.
• Define Done, Quality and the “what do you really do” part of the key roles
• Break the project into “imminent release” and “rest of project” and get on with some of the imminent release while sorting the rest out.
• Smile and look confident while copping a schalaking from the sponsor for not being fully ready.  Calmly repeat “its better to be unhappy now than at the end of the month; It’s better for the team to commit than to force them forward before they are ready; We know the biggest constraints and we are focussed on managing them first; stop hitting me, its not really appropriate).
• Expect to only deliver one quarter of my potential velocity in sprint one because I am really doing sprint two late.  Maybe I should delay to sort things out but that always seems to rub me the wrong way.What

What would you tell me to do?

But there is an explanation – My most recent project has been consuming more of my attention than expected.

Project New Baby (Or since we normally use acronyms in IT – “PNB”) involved the development and delivery of the next generation of peopleware for the King household (ie a baby).

Since the project was run by my wife, who is an exceptional project manager, the project delivered earlier than promised, which sounds good.

But there is a thing called project Karma that came into play on the delivery date. I have delivered a lot of IT projects in my time and have sometimes been guilty of saying “We can do that in warranty support” when I encounter things that could delay delivery of my project. I have even managed to deliver a project early by shifting some of the work into the forthcoming production releases.

The down side of deferring things to warranty support meant that the issues left behind were dealt with by a shocked looking and under-prepared production support team.

Beyond the short term impact though, the theory of project karma states that the luck you have on your future projects will be impacted by the good and not so good things you have inflicted on others in your previous projects.

So it should come as no surprise that although my wife delivered PNB earlier than expected, the warranty support team of two (my wife and I) found themselves under-resourced and poorly trained to support the new baby in production.

Consequently, I have been in a state of perpetual chaos for the last month or so, dragged away from other endeavours to support the new release.

On the plus side though, PNB has exceeded stakeholder expectations in customer satisfaction and other key indicators.

To become a Certified Strum Muckster you need to meet the strict sounding entry criteria for the International Strum Alliance and then abide by a number of rules that have been deemed by the International Strum Alliance  (currently me) to be the one true and correct way to create and deliver training courses.

Strum Alliance Membership

• James King

His mother also said that she would join if nobody else did so he wouldn’t feel bad … Though she hasn’t actually turned up yet.

Conditions that must be met to become a CSA

Potential Strum Mucksters  need to follow the correct pathway toward Strum Muckstery. No exceptions are allowed and unfortunately no credit can be given for existing qualifications or experience. This is to ensure the maintenance of the highest standards demanded of Strum practitioners.

1. The potential Strum Muckster must deem themself to be certified. Unfortunately the current volume of applicants and the inherent laziness of the existing membership of the International Strum Alliance means that nobody else has time to certify you. So certification will be strictly performed on a do-it-yourself basis.
2. If the newly qualified CSA wants a certificate he or she will need to work out how to print one.
3. The Certified Strum Muckster must use the title Certified Strum Muckster or CSA (Certified Strum Acronym) in at least one conversation, email or a comment on this blog.
4. The CSA must agree to absolutely not pay a membership fee of $22.50 per quarter to James King for the privilege of ongoing membership. Those who do decide to pay the membership fee will need to cease using the CSA qualification and instead adopt the title of RSBC (really should be certified). They will also need to look in a dictionary to find an alternative meaning for “certified”.

The rules of Strum

As with all true and correct approaches to building training, there are a number of rules that must be adhered to, unless you decide to break them.

The approach to learning the Strum method is similar to the approach used in learning many project methodologies and indeed the secret martial art techniques of the Yue Bet monastery:

1. Learn the rules
2. Follow the rules
3. Break the rules

In the Yue Bet approach to martial arts, students are expected to learn a technique, practice the technique until they master it and only then adapt the way they apply the technique to create their own style.

The same approach applies to learning many methodologies.

Practitioners must first learn the rules of the methodology, then they must follow the rules and learn what happens when they do so in the real world, after which they usually break the rules because the rules turned out to be quite silly and unrealistic when attempted without modification in a real project.

The same applies to learning Strum with one modification:

The 3 steps listed above must be closely adhered to. However, the CSA is free to apply the steps in any order.

Rule 1

The best way to train and learn is through face to face conversation, preferably through interaction in solving case studies as a group.

Having said that though, books are pretty interesting too and some of the new technologies like youtube and e-learning are pretty amazing. So use those things instead if you want to.

Rule 2

The correct class size is 5-9 students and 1-2 facilitators (CSAs).

But you can’t always find 5 people and sometimes you want to have more in the class so do that if it makes more sense.

Rule 3

The difference between the wise man and the fool is that the wise man can learn something  from anyone, even a fool.  But the fool will not learn from anyone, not even a wise man.

So if you have mastered your material to the point where you won’t find yourself learning from your students, nor being corrected by them in front of everyone else … then you can be sure that even the wisest of your students will still have something to learn from you.

Rule 4

Strum Mucksters do not seek to provide students with the correct answer but with the correct question.

That way the student has to do all the thinking and the strum muckster can drink cappuccinos.

Rule 5

Learning is optional but catering is compulsory.

In the end each student will only learn what he or she wants to learn but the CSA must cater to each student’s individual learning style AND provide muffins.

Rule 6

The Certified Strum Muckster must possess emotional intelligence and develop the appropriate level of soft skills.

If nobody got upset or uncomfortable during the course then you were probably too soft.

And if there was blood left on the carpet at the end of the course (particularly your own) then you probably should have been more tactful, or you might have pushed the learning too hard instead of remembering rule 5.

Rule 7

PowerPoint slides don’t bore people, trainers bore people with PowerPoint slides.

So feel free to show as many slides as you want and include as many bullet points on each slide as you feel you should add … even if someone said you should only have one idea per slide, no more than 3 short lines on each slide and no more than 10 slides for a one hour presentation.

Similarly you can feel free to replace all the boring PowerPoint slides with cool photos that you like and streaming videos all over the place.

After all a picture is worth 1,000 words so a presentation with 50 unrelated pictures is like a presentation with 50,000 unrelated words.

Rule 8

When the student is ready then the teacher will appear.

But when the teacher is ready then the student will probably be stuck in the middle of a major project and he or she won’t be able to come to the course.

That sucks a bit but its a rule so what can you do?

(Note: “That sucks” is a technical term meaning “that is quite unfortunate”).

Alleged Rule 9

Your aphorisms are clever but probably not useful to the student.

You will always add just one more concept to the course because it is worth knowing  … but when you run the course you will realise that you should probably have stopped and let the other material sink in.

So there are only 8 rules and you should not be reading this alleged rule at all.  Go back to rule 1 or get out there and break the other rules.

Conclusion

The International Strum Alliance is now officially recognised among its membership as the single credible source for international trainer certification against the rigorous sounding standards of the alliance’s primary certification.

Please consider joining us if you feel you have the ability to rise to the challenge and the time to dedicate to the certification process.