Bad developers see problems and sit there waiting for someone to come up with a solution in enough detail for the developer to transcribe the solution into code, much like an old fashioned typist takes dictation and types it onto a page.
So if a bad developer noticed that their house needed cleaning, then he or she would simply complain that someone should clean it. Then if you point out that it is their house that needs cleaning then they will either claim management won’t let them clean or that the problem is more complex than it seems cannot be solved.

In fact even if you ask them to try and clean, they will just start to reveal that cleaning is “more than vacuuming” and could involve the removal of micro-particles that only quantum physicists could possible manipulate. Indeed, they will contend, it is unlikely that anyone really cleans their house and the only practical solution would be to upgrade to a new cleaner house.

But good developers are different. A good developer will notice that the house needs cleaning, work out that actually cleaning it less fun than designing a better way to clean houses and immediately begin working on the design for a new robot.

In fact, rather than cleaning the house for an hour, most good developers would prefer to spend a whole day building a robot that could clean the house for them.
Of course, the robot might occasionally turn evil and attack the developer as happens in every science fiction movie; but even this is seen as being preferable to cleaning the house manually.

So a similar thing happens when it comes to testing. Bad developers seem to think that testing is optional, or at best a good idea in a utopian world, but simply impossible with our existing systems.

Good developers suggest that we hire a cleaner to come in once a week (er – a tester I mean). But that means that our house gets dirtier during the week and is only ever clean for a short time. It also turns out to cost money to hire both testers and cleaners and it turns out that if they are not good at their job then they don’t help us to clean things up at all.

So it is no surprise that when I asked my developers to do some regression testing recently, they immediately recommended hiring a regression testing specialist. When my budget ran too low, they immediately started to build robots to do the testing for them.

But the robots turned out to need maintenance and development and sadly even testing – they were developing their own bugs. So now we face the challenge – should we build a new robot to test our existing testing robot?

Now it seems we face an infinite loop, with ever increasing armies of robots being built to test and protect us from the robots we have already built.

Or, maybe we can do some manual regression testing.

Manual regression testing involves somebody sitting down and testing that what we built yesterday still works, even though we added some new stuff today.
Because regression testing is boring, we would like to defer it to the end of the project, but because our system gets dirty one day at a time it seems better to test it every day.

But without robots and nanotechnology we cannot test everything every day and even with robots, they only test the same obvious stuff every day.
This is what you would call a problem that sucks:

So I decided to as a tester – What is it about testers that makes them enjoy doing long hours or boring, sucky work?

The answer might surprise you – the tester I spoke to actually hates doing long hours of sucky boring work. He even hired a cleaner to clean his house because he could not afford a robot with nontechnology. Also he noted, he would not trust a robot that was built by developers because he was sure it would eventually turn evil and try to exterminate humanity.

So I asked him a new question – how can manual regression testing be anything but sucky work?

“Build some robots,” he responded, “Automated testing is much better than manual testing for fun value, even though manual testing often reveals more important problems.”
“But how can a human out-test a robot?” I asked, “ and why do you do manual testing if it sucks.”
“Repetitive testing sucks and robots are better at stuff that sucks. But manual testing is really problem solving not just typing test scripts,” He responded.

My immediate thought was that if I could fool the developers into thinking that testing was fun then I might be onto something … but they are probably too smart for that.

So the bigger challenge is to try to find ways that testing is actually about problem solving while keeping the repetitive stuff to a minimum. Unfortunately that sounds like the opposite of regression testing doesn’t it?

So – how can regression testing be valuable work that people don’t hate doing – rather than low value work we defer indefinitely? (Besides through building robots).

In this case I am looking at how to be scared. 

Apparently there is a standard approach to being scared that inolves the amygdalae in our brain and us cheking our big catalogue of things to be scared of when any event happens. But that is a biological response and I am more interested here in a project management response.

So here is where I start – the ISO90210 standard for being scared at the start of a project (or halfway through):

1. For both Product risk and project risk (see below for the definitions), write down a list of:
• What could go wrong?
• What would cause it?
• When and how would we find out?
• What would happen after we found out?
2. Once you have a long list, review the list and look for patterns:
• Are any 2 things symptoms of the same underlying cause or event?
• Do several bad things result in a similar bad outcome?
• What is the level of risk outrage – ie how pissed off would the stakeholders be with each, regardless of how bad or mild it really is?
• Ask yourself – If one or two of these did happen, which ones would they be?
• Ask yourself – If there is one thing we know we should deal with, but probably won’t, what would it be?
3. Consolidate your list into the top three (or 1 or 5):
• Which 3 things should we be the most worried about?
• Why them in particular?

 Then you have a consolidated list of what you should be the most scared of. The final steps are:

1. Compare your list to what others came up with; and
2. Discuss what we should do about the combined list of concerns.

Note – it is worth looking at both product risk and process risk:

• Product risk is the risk that we will deliver the project but that the product we deliver will not do what we want (it will fail to meet expectations or do unwanted things). For example it might not sell or it might canabalise demand for another product; and
• Process risk (or project risk) is the risk the project won’t deliver the product we have asked for when we want it. Examples include too many bugs, a restructure impacting the team and so forth.

At least if you are going to be scared (which you should be on every project), you can now do it properly.

• What they have done since last time
• What they will do today
• What obstacle or issue is in their way

It works really well in my slides but now I am trapped in the real world temporarilly working on a real project. Do I really want a daily meeting?

I actually do really benefit from the daily meeting, especially when I compare what we say we are doing to a physical story wall.

Lately though, I have been on multiple projects, all of which have a standup.  I have also asked my own team to do a stand up.  So now one of my obstacles is “I am in too many meetings about my obstacles”.

The simple solution we have implemented is that nobody can be in more than two standups a day. It seemed impossible because we are doing so much. But then we realised we were actually commiting to so much, not necessarilly doing it all.

Nobody believes me in my training courses, but if you are on 10 projects you really do have to stop being spread so thinly. People often thing there is no choice but to remain too thinly spread. But even if you get thrown off the projects for complaining and people tell you off, this is better than being left on 10 projects and then having people complain that you are not delivering.

So I was happy again.  But I had no idea that outside of agile projects some guy published a book on “Mastering the Rockerfeller Habits“. Based on this the team I am working with have:

• A daily meeting to keep up on things.  The agenda should be short and sweet and should cover
• What 3 things you will do today
• The “rock” or obstacle in your way
• Your daily measure or “Key Performance Indicator (KPI)
• A weekly meeting to confirm progress, communicate across the team and commit to the next week.

It all sounded very agile even though I assume Rockerfeller never used the term “agile”. 

I particularly like the limit of three things you will do today, because it forces you to prioritise and to be brief in your update. But then I stopped to think about it – why would I provide a KPI every day?  And what happened to the “This is what I actually got done yesterday”.

So we now have a story wall for one team (we are colocated) and make sure we put our daily commitments up on the wall – so we see if they have been done.  For the other team we have to remind each other what we missed or achieved.

But good grief – who wants a daily KPI?  It turns out that it sucks quite badly for multiple reasons. 

• Rather than just reporting tasks completed or stories delivered, we have to measure the quality of our work every day. It turns out it is a lot easier to talk about stuff you did than about the value you added or the quality of what you did.
• You need to find out what the core focus of your role is and quantify it.  Then you need to explain your focus to the rest of the team.
• You need to constantly come back and focus on your measure.
• Even simple measures lead to challenging questions when they are inconsistent (or too consistent) or unexpected.

Of course these are also good reasons for doing it.

My initial measures were a bit lame, but now I think I will change one of mine to the following

• Percentage of time spent adding new value to the business (new stories for developers, something hard for managers)
• Percentage of time spent “consolidating or protecting existing value”.  This would include fixing defects (because you are repairing the system to what it should be doing already), maybe monitoring the system and maybe refactoring to simplify what the system is already doing
• Percentage of time spent doing other stuff (writing on my blog, going to meetings which have no defined value nor good muffins, writing reports for people, etc).

Since we don’t have time sheets here (yay) I will have to guess what the percentages are every day. But then I would probably have to be able to justify the rating I give and that seems really hard.

Maybe I should tell them that agile projects don’t measure KPIs. We measure activity rather than quality. 

In fact many projects measure activity instead of progress (story points complete but not problem solved or new capability delivered).

Then again – maybe my agile projects should be providing some kind of measure of daily contribution to the business rather than daily activity.

What would happen if our agile projects were expected to do that in the same way the team I am working with have been asked to?

Generally I think of them as “project managers for creative people and artists” but I did once ask a producer what they really do and they succinctly described all the roles of business analyst, Scrum Master/iteration manager, project manager and product owner.

Maybe a shorter description is that they make sure everything comes together on a brief before time, creativity and money run out.

Producers are often used to running running relatively small projects where they can deliver through hard work, luck, finesse and sheer determination; but they often struggle when they end up on larger and larger projects where their role becomes ever more critical while simultaneously becoming ever more vague and confused until they need to resort to PDD as the only way to bring the project home (PDD – Panic Driven Development).

Agile approaches often provide a structure and a discipline that allow the producer to manage the complexity and creativity on larger initiatives, but unfortunately most agile literature and training is aimed at IT development teams, rather than producers.

So how do a producer learn to become agile?  I got asked this question recently and referred it onto Rebecca Yik – Executive Producer and accidental agile coach. She came back with the following advice:

Things I’ve learnt and can recommend as a Producer developing my Agile expertise

Blogs, Resources, Guides

• James King http://kingsinsight.com  (goes without saying right?)
• Agile @ Atlassian http://www.atlassian.com/agile/
• Version One http://www.versionone.com/Resources/
• Mike Cohn http://blog.mountaingoatsoftware.com/
• Rally Software http://www.rallydev.com/

Books

• Agile Estimating and Planning by Mike Cohn

Tools – At the moment I’m reviewing/trialling online tools we should use

• Version One
• JIRA with Green-hopper

Groups you should join in Sydney Australia

• Agile Sydney http://www.meetup.com/Agile-Sydney/

Training

• Software Education (snuck in by James) http://softed.com/Courses/Agile.aspx
• Agile Academy http://www.agileacademy.com.au/agile/
• On the job!

To that list I (James again) would add one course that looks like it will be a really good one for producers: Passionate Product Ownership with Jeff Patton.

Of course both Rebecca and I are also available to help your journey – either with advice over coffee or fully-fledged coaching and consulting work.

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.

As a user I want to report on the number of users who read articles on my blog so I can see whether a topic is popular or not.

This approach can work really well for a production support team, but sometimes the users are listing issues or bugs, which don’t naturally follow the format. For example:

• The current report is two slow, it needs to run in less than 30 seconds
• Can I have the date modified to use Sydney time in Australia rather than GMT
• The report sometimes crashes when I run it

In practice, I often find people present their “story” or request as an impact statement:

• The issue;
• Why it is significant; and
• What I want to see happen.

This works OK but is quite informal, so I found a good way to capture the same infomration is through the “FAB” structure that salespeople sometimes use.

FAB means “Feature, attributes and benefits”. So instead of listing the features of your product, you focus on how the particular attributes of your product provide a benefit to the customer.

Of course, the customers of a production support team rarely feel the need to sell the benefits of their requests, they just want everything urgently for free.

So here is how I like to use the FAB structure to capture their requirements:

Impact statement

• The feature (or thing with an issue) is ___________________
• The attributes are _________________
• The impact that is it having on me/us is _______________

For example …. The usage report (feature) takes up to 4 minutes to run (the attributes of the report that I won’t to talk about) and the impact is that it really annoys the users. Other attributes might be the fact that it crashes once a day or the fact that the time zone is based on GMT.

Then I then agree or capture the desired outcome:

• The feature (which is often the same but might be a new report) is _____________
• The desired attributes are _______________
• The benefit of changing these is that _________________

For example, I might capture the “story” for my report as

The report (feature) needs to run in under 30 seconds (the attribute) so that we can run it on the fly during presentations (the benefit)

If you look at it, this is almost identical to the standard wording for a story. I just find the impact statement a little more instinctive for users raising requests that might be bugs, changes to performance or other non-functional requirements.

I also like the fact that I can now list all the “stories” that relate to a feature rather than a thing the user wants to do. So for a small enhancement I might list a number of desired attributes for the one feature.

You can track the user requests in this format or you can use this format as an “epic”. In which case you would then break it down into stories for the purpose of getting the work done.

I also know that creating a test strategy should involve more than just taking the 25 page strategy from the last project and replacing the project name.

The minimum I think you can get away with is a discussion with the whole team about:

• What could go wrong;
• What needs to be done right; and
• What the team will actually get around to testing with the limited time and money available in the real world.

Hopefully, a professional tester or developer can do a lot better than that. But in the absence of anything else, I think a brief conversation or two should allow the team to produce the following “optimised for laziness” artefacts before diving into more detail.

Create some kind of understanding of the architecture

Start with a basic architecture diagram. It can be a simple as a heat map or as complex as you would like it to be.

Use the diagram as the starting point to discuss the kinds of things that can go wrong from a technical point of view.

Create a system impact table

In this system impact diagram I have created the following data:

• The name of each system the team will work on or interface with;
• A column detailing whether I am changing the system or simply interfacing with it;
• A column detailing whether the system is a new one or an existing one;
• A column to detail how complex the system is to work with, but the team decided not to use this one;
• A summary of the risk of trouble when we work on the system
• How likely are we to make a noticeable mistake;
• How bad would it be (the impact);
• How easy would it be to detect or test for the errors we might make; and
• How easy would it be to recover if we did deploy something wrong (for example if we are in a plane that took off or we are distributing via DVD then it would be hard to correct any mistake, if we are creating pages in an intranet it might be easy).

So far so good – I think most teams should be able to create this much understanding through a single workshop.

Of course, since many projects involve interfaces, integration or process changes then you can add these to the table just as you would another system.

Create a test strategy

Once again, for the lazy team, it is easier to create a table on a whiteboard than it is to create a 25 page document:

For each system (or process?) the team add a row to the table. Then they add columns for:

• The testing that will be done continuously throughout the project (every week or every iteration);
• The team have added unit testing, UAT, regression testing, factor testing and sector testing.
• I don’t actually know what factor or sector testing are, but that is part of the discussion. You would be amazed how many teams claim they are doing system or integration testing but are not sure what it means.
• The testing that will be done each time the software is released, for example DR testing, performance testing or user experience testing.
• The testing that will be done on an adhoc basis or is a one off at some point in the project.
• The testing that the team are going to skip on the each system. Of course the team should robustly test for every conceivable bug on every system they are going near … but they also have no money or time available.

Finally, the team go through each column determining whether the testing will be

• N/A – not done for this system;
• Manual – done by the team;
• Other – done by the customer, another team or another organisation. This requires coordination for the team but no actual testing effort;
• Automated – done by robots or through automated testing tools; and
• Done by a specialist vendor or team.

Do better if it is justified

Of course, testing is a critical component of most IT projects so you might do a lot better than what I have detailed here.

But as a minimum I think the sponsor and team members should also understand what testing is being done and what is not being done (Say DR testing), so that they understand either the risk the team is taking or the reason the team is spending so much time and money on testing.

I guess the answer is yes, but …..

I believe that you can certify anything if you can define and measure it.

So you can certify an accountant if you can define and measure the things an accountant should be able to do. I would not go to a tax accountant unless they were part of a professional body because I respect the professional bodies and trust that their “certified members” abide by a set of skills, practices and ethics that embody what I think their profession is.

Along the same lines I think you can certify a person as a project manager (or business analyst, tester or developer) if you can define and measure what they do.

So I like the idea that someone is certified in DSDM/Atern (Prince2 branded agile) because it is a set of processes and practices. This means that certified in Atern means someone knows what the practices are if I want to use them to run my project. But it does not mean they are a good agile project manager.

But I don’t hire people because they know what Atern is. I hire lucky project managers and innovative developers. So it would be awesome if I could Google (for example) CLPM – certified lucky project manager and find one, but I am not confident that I could.

So my concern with certifying someone as agile is that I am not sure how to define and measure what we collectively mean by agile.

I would be happy to rate someone “certified by James King as being good at running agile projects” because then people can use my credibility (or lack of credibility) to make a decision about whether to hire the project manager.

But in the absence of a single recognised body of agile professionals who have defined the finite list of practices and ethics that their members abide by, then I am not sure what “certified in agile” really means.

So I am happy that someone is certified by Prince2, Scrum or PMBOK as knowing what they think agile means and meeting the entry criteria for their respective groups.

But I don’t yet see how that means they will be able to meet my definition of agile leaders (to adapt their approach to the context of the situation or encourage effective interaction and creativity in a team). So I am not yet convinced that there is such a thing as an effective certification for agile, for lucky or for innovative.