Month: February 2012

Agile development, Capability growth, Leading changeLeave a comment

Performance agreements – a first attempt for agile project team members

James King

I was just reading an article on performance appraisals by Shane Hastie. It is a good summary of some of the issues that traditional performance appraisals cause on agile projects.

But it leaves two questions unanswered:

  • Where would you start if you actually had to do a performance agreement; and
  • How would you actually know what was expected of you if you didn’t?

The situation is made worse, according to the links in Shane’s article, when you want the team to be jointly accountable for shared success rather than individual success.  This is important if you want to work out how to evaluate testers or BA’s for example, because their purpose is to make the team successful rather than to stand out on their own.

Continue reading “Performance agreements – a first attempt for agile project team members”

Agile development, Idea management, Investigation2 Comments

OODA Loops for fighter pilots, business analysts and testers

James King

When I started to learn agile approaches to projects, OODA was all the rage, but it seems to have disappeared from view as modern agilistas move from Scrum to lean to Kanban to ultra-velocitus development.

I guess I am still a bit old school, because I still think the OODA loop is the essence of the agile approach.

So what is an OODA loop?

OODA loops began as an approach for fighter pilots to avoid dying. It is a way to train fighter pilots and also a way to design fighter aircraft, develop tactics for air combat and win wars in the air.  It turns out that it is also really useful for agile projects, production support teams and anyone rolling out a product in a competitive market.

Continue reading “OODA Loops for fighter pilots, business analysts and testers”

Idea management, Investigation, Observations, Reflection3 Comments

Famous BAs in history: Mark Twain on interviews

James King

I stumbled on a letter from Mark Twain where he comments on “the interview”:

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.

Continue reading “Famous BAs in history: Mark Twain on interviews”

Agile development, Idea management, ImplementationLeave a comment

Stories for production support teams part 3: stories involving vendors

James King

A long time ago I used to do production support as part of my role (I was a Unix administrator/DBA/system analyst).

In those days requirements were really easy for me: people would come to my desk and ask for something, or they would email me or maybe even leave a scribbled note on my desk. There were no standard formats, no formality and (usually) no problems.

But even back then I had to work with vendors and sometimes that was when the trouble started. Some were happy with my “give me a call” approach to requirements, while others required a ticket and some even required a complicated work request form.

Now days, some production support teams are more professional that I was and they actually have real requirements or (if they are agile) stories. And most of them seem to be flooded with vendors.

So, do stories work with vendors?  The obvious answer is YES. For example, if you receive a story in the following format then it should work for you and also for your vendor:

  • As a coffee club member I want to be able to see a list of future coffee appreciation classes so that I can enrol in those that look interesting.

But what about complaints and bugs?

  • As a coffee club member I don’t want to have my name spelled incorrectly because it is really annoying me.

Continue reading “Stories for production support teams part 3: stories involving vendors”

Agile development, Idea management, Implementation3 Comments

Use cases make for better test scenarios

James King

I have encountered Use Cases on several occasions, sometimes they seem like a simple tool that can be used to better understand how a system behaves from a users perspective, while at other times people describe them as terrifying monsters that have murdered people and led to the destruction of entire projects. So I am going to recommend only using the good kind.

But what is a use case? It is simply an example of how a system (or business service) could be used by someone.

Continue reading “Use cases make for better test scenarios”

Capability growth, Leading changeLeave a comment

How can you manage people on projects these days?

James King

Life used to be easy for managers. We had good people who delivered lots of stuff and bad people who stuffed up lots of deliverables. It was easy to tell who the good guys and the bad guys were. 

But then something significant happened. We discovered that work was not just about performing a set of predictable tasks. We started to realise that:

  • Work was about adding value rather than destroying value rather than just delivering stuff; and
  • We started to see value as something delivered through the interaction of entire teams and not through individual achievement.

Continue reading “How can you manage people on projects these days?”

Agile development, Capability growth, Leading change2 Comments

Succession planning as an idea whose time has come

James King

Everywhere I go I am starting to notice consistent problems or patterns of behaviour that hold back some of the best people in the teams I work with. I think they are starting to rank right up their with the Peter Principle as ways to stop good people from reaching their true potential and really contributing value to the teams they work with.

And they are all related to the managers in the team not having enough time to talk about succession planning.

Continue reading “Succession planning as an idea whose time has come”

ObservationsLeave a comment

What is stepwise programming?

James King

Stepwise programming is a very useful way to prioritise when there are many variables at play.

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.

Continue reading “What is stepwise programming?”

Agile development, Implementation4 Comments

Regression testing – day 1

James King

Regression testing is the easy part of IT development, not the horrible monster  some people think it has to be.

But where do you start if you want to do effective regression testing, but you are already busy and don’t want it to be huge burden?

I hope this article and a couple that follow will turn out to be a guide to one painless way to get regression testing up and running. Let me know if it helps.

Continue reading “Regression testing – day 1”