Author Archives: James King

About James King

I coach organisations in how to better make use of the untapped talent they have in their people and to explore new ways of understanding and solving new and old problems I live in Sydney with my wife and daughter and have no real hobbies beyond the usual boring ones of reading, writing and watching tv.

Performance agreements when you are on projects

I was happily running a class when someone asked about how performance agreements work if you are on projects.

“Really well” I replied, “you just need a new one for each project you are on.”

My answer didn’t seem to go down well though. After all, who wants yet another piece of administration to do?

Then we discussed the problem that both permanent staff and contractors often have with projects. Contractors get no real feedback on how they are going until their contract ends, while permanent staff have to have a series of discussions based on a document that bears little relationship to what they are doing on their projects.

Read the rest of this entry »

1 Comment

Posted by on August 3, 2011 in Business Analysis, Testing


Tags: ,

Splitting stories and exploding scope in agile projects

We used the  “Abstract to concrete” approach to splitting stories in a training course recently.The approach is published in our “resources” page, alongside some other approaches that also work.

But I told the class I would publish it here for easy reference, so here it is.


Read the rest of this entry »

1 Comment

Posted by on July 2, 2011 in Agile, Business Analysis


Tags: ,

Agile BI and data warehouses

I have done a lot of data conversion projects and a lot of building of reports on financial information. But when participants in my courses ask about data warehouses my advice is a little more limited.

I usually tell people that data warehouses sound like a good idea and that every company should have one. People usually thank me politely for this but also advise me that they already have one – in fact they have around 17.

At that point we agree that if you use a cowboy based agile approach with no architecture you will add a lot of access databases and tactical databases to the existing chaos without simplifying the environment.  So we agree that we should do a substantial amount of careful design and strategy work before buildng too many databases (ie do up front architecture).

But then one of the group usually reveals that their company also did this and their architects are still trying to convince people that it is a good idea to build $100 million in infrastructure before seeing any benefits – and meanwhile projects are deciding they can’t wait for the utopian dream, so building “tactical datamarts”.

These tactical datamarts generally duplicate both data and interfaces without decommissioning, consolidating or even fixing existing data and interfaces.

So we end up with what is called spagettification driven development.

Even with my limited exposure the business intelligence and data warehouses I can see that this is both the wrong thing to do and an easy trap to fall into.  So a better approach would be to merge detailed architecture (upfront and ongoing) with a continuous delivery of value (new useful reports, simplified data and decommissioned redundant interfaces).

With that in mind I thought I would publish some of the links that participants have sent me to research this further:

An ebook on “agile data warehousing ” that several participants recommended (it will cost about $10)

A RUP based approach published by Scott Ambler

Cutter consorium page on business intelligence

Let me know if you have other links, or better yet some experience in successfully working with the implementation of data warehouses (using agile or not).

Posted by James King

Leave a comment

Posted by on August 29, 2010 in Agile, Design Process


What to look for in system testing

Previous readers of this blog will have noticed the intellectual firepower and sheer passion of the contributors who share their views on testing.

They will also have noticed the blatant and shameful lack of authority with which one contributor (me) replies to questions and issues around testing.

What you may not be aware of is that I frequently also share my confident but dangerously simplistic views on testing when running courses, talking in the pub and anywhere else.  So hopefully those better educated in the mysterious ways of the tester will continue to correct my wayward advice before anyone follows it.

So, with that opportunity, here is an email request I recently received:

Dear TWG (Testing-wannabe-guru):

On our last day of our BA course, you mentioned several things a tester should test for in system testing.  Would you be able to send me the list?

Yours – BA who believes in quality

So here is my response- subject to correction from the pros:

Dear BA

In system testing we should test for things that might be wrong with the system.  You would think this means the process, the IT applications, the training material and other things that a business person would think are the “system” we are delivering.  But this would be hard and might result in a lot of work when we realise there are issues.

So we normally only test the IT applications and even then we only test three  things:

  1. Test things the developer should have already thought of when writing the code.
  • Since the developer should have thought of these things, we should not need to test for them at all.  So you can assure yourself of the system’s integrity by asking the developer “does the system do what we asked you to make it do?”  They will generally say “yes” and look a bit shifty.
  • We then ask the developer “how do you know” and they will respond “I don’t know – its the testers job to tell you if the system does what you asked me to make it do”
  1. Test the developers patience.  You should now ask the developer if they are a proud member of the professional elite of great developers.  They will tend to say “yes”.  Then you say – “Excellent, then clearly you would have not only made the system do what we asked you to make it do .. but even suggested innovative new things that nobody else could have made it do … Surely that is the difference between the adequate developer and the great one.  So, how can I prove to others that you deserve their respect and even their awe?”
  • They will generally look perplexed or annoyed – so ask them “OK, assuming we had great developers then we should only need adequate testers – what would an adequate tester test for to make sure the system works”
  • Now ignore what the developer says, because this is the stuff they  have thought of and that will generally already be working.  This is therefore not what we spend time testing in the system testing phase.
  • Testing the developer’s patience should always be included in your testing.  Not only is it fun, but you will soon learn who the good developers are (they actually do know the system does the obvious things they were asked to make it do) and this is a good measure of the quality of the overall system.
  1. Test for bizarre things the developer would not think  of
  • Begin with scenario tests – create some examples of how people might use the system.  Don’t just look at one requirement but think up and example where the user would want the system to do several things.  For example, to test a banking system, don’t test just whether you can log in.  Do an example where someone logs in, looks at an account balance, performs a transaction and then goes back and looks at the account balance.
  • Think of some more examples (scenarios) and spend about 70% of however much time you have available running these though these examples to see if they work.
  • Now do some “bizarro testing”.  This is often called “exploratory testing“.  Think of random things that someone might do if they were dumb/they were distracted/they were intelligent but did not understand the system/they were older than normal/they were younger than normal/ they were in any way different to how a developer would imagine them to be.  Spend 30% of your time just doing some of these random seeming things and see what errors and unpleasant outcomes you can uncover.

Its pretty easy really.  The only problem is that you will only have a few days available and you will need about 6 months to test the system properly.  So, oddly enough what we pay testers for is not “finding bugs” but

“Spending very limited time to

  • Help the good developers discover the issues and problems they would not have thought of and
  • Let us know if it is likely that the system will suck in production and embarrass the team, or work as designed and make us look good.

I am not sure how they do this with so little time available but apparently this is their job.

Does anyone know how we can do better in system testing that the above approach?  It seems quite straight forward and yet appears to be a real challenge on projects.


Agile retrospectives wiki

Here is an interesting link one of our course participants sent through.

It’s a list of views and ideas centered around retrospectives.  It is not just for agile projects but certainly refers to agile principles and practices.

Let me know what you think.

Leave a comment

Posted by on May 3, 2010 in Uncategorized


The power of the BA

I was doing some spring cleaning recently and I started reading some old material I was meant to be filing (I am not a very efficient spring cleaner).

I came across some of my masters degree notes on power, politics and negotiation in organisations.  Some of the main sources of power were:

  • Being the “locus of communication”.  In other words being the person between multiple teams that handles a lot of the inter-team communication;
  • The ability to set the agenda in discussions (generally meetings and workshops by also interviews); and
  • The one framing the questions for discussion (apparently the way you word the question often dictates the answer, which dictates what will happen next in the organisation).

As I read through the list, these and several other sources of power seemed almost like a job description for a BA.

Then I read another old paper which I sometimes quote in courses.  It talked about who survives, thrives and gains power in tumultuous times in organisations.  This paper concluded that the power brokers (survivors) were the:

  • Boundary spanners (those who communicate between teams);
  • People who understand their own knowledge needs and the knowledge needs of others; and
  • Those good a team facilitation (workshops, meetings and BA stuff).

I pondered these papers (which still need filing) and I began to think about the book “Bargaining for advantage” by Richard G Shell.

This is my favourite guide to negotiation.  Among other things the book stresses the importance:

  • Information gathering and understanding in the negotiation process (ie what BAs do);
  • The importance of knowing who the influencers are in a negotiation (often the BAs); and
  • Knowing where to go to bring outside (but maybe biased) views to the table to influence the discussion.

I began pondering the idea of finishing my filing, but instead drifted off to wondering how much power BAs have.  It seems to me that they wield vast organisational and political power on projects, in their teams and in their organisations.

Yet, one of the gripes I hear from BAs is that they don’t have any power to make things happen on their projects.  All power rests with the PM and the BA is mere a pawn in the mighty game of organisational politics.

I have concluded that in fact business analysts DO wield vast power.  They just claim that they don’t.  I’d be interested to know if you agree.

I’d also be interested to know the answer to my new question – If, indeed, the BA does wield vast power and yet claims not to …. is this because he or she is unaware of the power of the BA, or is it a conspiracy, where they are controlling the information to keep everyone else ignorant of the impact they are really having on the world?

Leave a comment

Posted by on February 26, 2010 in Business Analysis, Culture


Some holiday reading – what happens to testers on agile projects

Hi agile fans

Once again I was talking to a client about the wonders of agile project management when they revealed that their biggest need was improve the effectiveness of testing.

I am not sure if it is because testing is where the symptoms of many different problems are highlighted or if it is because testing is such a crucial part of IT development and support that fixing it is the most natural first step to fixing other areas.

Interestingly, I had a participant in a class recently who said to me “I think IT really began to go wrong when we started having testers”.

This sounded a bit controversial so we asked him what he meant. Apparently, when he first became a developer, he was taught that a core part of his job was to test extremely well to ensure he produced quality work. Now, he claims, there is a view that BA’s come up with requirements, developers cut code and then it is up to the testers to make sure that things work.

I don’t think that we started to go wrong when we brought in people to test – I think the integration issues and complexity of many systems means that developers only understand part of the system well and will struggle to test everything effectively without a specialist helping with this.  So I think we started to go wrong when we started to think complexity was necessary in our systems.

But I do agree that we go wrong when we think that testing is part of someone else’s role.

In fact I really enjoyed this link that Shane sent me on how a tester perceives agile projects, where the tester is having to deal with a change in thinking away from the tester being the finder of defects:

So I now think that the essence of good development is going to come from the synthesis of the following two trends that I am starting to see:

  • Better development will mean we will do less testing: – We will start to see good projects as ones where we are surprised to find bugs rather than ones where fixing bugs is a key part of our work.  Thus testing after the developer is done will become a smaller component of projects since it will cease to provide much value; and
  • Better testing will mean we will do less development: – By defining the problem properly and agreeing how to test our solution, we will eliminate much of the development work we currently see as necessary.  Thus development will become the simple translation of well thought out testing into the code that the system will understand …  and be only a small component of the project.

I might ponder this further while consuming some of the copious leftovers we have in our house after the Christmas feasting season.  Maybe we should add a warranty period to Christmas and dispense with it on our projects.  Instead we should be able to assume that what we have built will work, since we wouldn’t have built it any other way.

Posted by James King


Posted by on December 27, 2009 in Agile, Quality, SDC 2010, Testing


Agile testing strategies

One of the participants in a course asked me about test strategies for agile projects.

Drawing on my extensive testing background I responded that I had heard of them and that I had also heard they were probably a good idea.

But I think he may have wanted a more extensive answer.  He is doing test strategies on both waterfall and agile projects and his team are still using a long-winded document with a lot of cutting and pasting from previous projects.

He understands that strategy is more about the creation of the strategy than the publishing of a document and is comfortable with the idea that he collaborates and thinks before documenting the outcomes.  But he is looking for a more effective way to document the test strategy and maybe have a template or approach that works for his agile projects.

Can anyone give him better advise than my sage comment “I have heard it is a good idea to have one.”?

Posted by James King


Posted by on October 21, 2009 in Agile, Test Strategy, Testing


Test Manager – The movie

I recently found out that someone has finally made a movie about a test manager.  What could be more dramatic and poignant than testing on a high pressure projec?

Oddly though the movie is a comedy that is apparently based on fact.  “The Pentagon Wars”  is about the testing of the “Bradley fighting vehicle” and has a familiar plot to testers:

  • The PM wants to “smooth over” flaws during testing prior to going live.
  • The test manager wants to stop the product being shipped as a deathtrap.

The only quote I have is from the “PIR”.  Burton is the test manager being referred to and Partridge is the PM who is responding to questions.

  • Major General Partridge: Just because the tests didn’t turn out the way Colonel Burton thought they would, was no reason to suspect there was anything devious going on.
  • Madame Chairwoman: I ask you General, filling the fuel tanks with WATER before a test to check the combustibility of those tanks, that wasn’t devious?
  • Major General Partridge: If the tanks had been filled with fuel, there’s a good chance the vehicle would have exploded.
  • Congressman #1: Isn’t that the point?
  • Major General Partridge: If the vehicle had exploded, we wouldn’t be able to run additional tests!

Has anyone seen the movie, or found a similar one on BAs or project managers?

Posted by James King


Posted by on August 29, 2009 in Culture, Testing


An example of a social contract

Shane and I were running an agile (Agile?) training course last week and we were discussing the idea of social contracts with the participants.

A social contract is an agreed code of conduct or way or working.  Some teams publish them on posters and others simply thrash them out over a few beers.

We thought we would include a slide showing social contracts and would use the world’s elite trainers (ie us) as a high profile example.

What would you think of something like this appearing on a slide for the participants to ponder/comment on?

Social contract for Knowledge Engineers:

  1. We will use our individual styles to present a consistent content.  If we don’t like the current content then we will openly debate with our peers with the aim of creating the best shared view of each topic that we can.
  2. We will always ask for help and guidance from each other and we will always provide help and advice when asked, even though our arrogant peers may ignore our sage like wisdom because they do not fully recognise our innate genius.
  3. We will give each other open and useful feedback whenever we see each other facitilate.
  4. We will openly steal each other’s ideas when running courses, but never each other’s jokes.
  5. We will always acknowledge the source and author of material we include in our courses.

Posted by on July 12, 2009 in Agile, Culture