Monthly Archives: July 2009

High Performance Teams Emerge

Something that came across to me last week when delivering a suite of Agile courses is how high-performance teams emerge.   One day of the course covers the identification of reuirements as stories; to help make it real we used two actual projects that the customer is about to start.  They are the two most important pieces of work this group is currently facing, so the pressure is real.

We had 25-or-so people in the class, so they split into two groups (based around the teams that will actually work on the projects).  I briefly explained the theory of stories and turned the teams loose. 

It was wonderful to behold – there was a bit of thrashing at the beginning, then the teams self-organised and worked fantastically together.  After about 2 hours we paused and had a brief retrospective (what’s working, what’s not, what still confuses me…) to ensure the teams remained on point. 

The session continued until about 4:30, at which time we stopped and asked what had been achieved.  The reaction was one of wonder – in the course of a single day of workshop they had scoped and prioritised the two most important pieces of work facing their group for the next 6 months.  Every person in the teams understood their project goals and objectives and what the most important features need to deliver. 

Some of the comments I heard inclided:

We achieved in one day what normally takes us six weeks

For the first time I understand why we are doing a project

It was an energising experience for me to facilitate, and I got the feeling it was great for the participants.

I’m going to send this link to the people who were in the session and ask them to comment.  I wonder if their experiences were the same as mine…

Posted by Shane Hastie


Posted by on July 21, 2009 in Agile, Courses



Common Testing Issues

What are the key things that we find are issues for software testing? How can we address these problems? In my experience we usually have a solution to most of the problems – we just need to identify the problems and then we can workshop the solutions!

Here is my top 10 problems
1. late delivery of code
2. poor requirements
3. wrong requirements
4. late engagement of the testers
5. shoddy code
6. problems in communicating with PMs
7. problems in communicating with developers
8. lack of career growth
9. lack of exposure to/access to test tools
10. lack of training on tools

What are your key issues?

Posted by Sharon Robson


Posted by on July 21, 2009 in Testing



It is more important to deliver value than to deliver on-time and within budget

I have placed a link below to an article written by Tom De Marco.  It raises some very interesting issues.  I think one of the most important issues it raises is pertinent to my thoughts on how important it is to have a proper, and is far as is practicable quantified, business case for any software project.   Please please please establish the business case before attempting to estimate the cost/effort of a project.  I also feel the article presents a strong argument for agile approaches (please note the small a) to the development process ….. processes that are nimble, flexible, collaborative, non-bean-counter-driven, focussed on delivery of value

Check out this article from Computing Now:

Also: a reminder … have a look at this link (first posted by Shane)

Posted by John Watson


Tags: , , , , ,

Don’t start until you know when you’ll be finished!

One of the best articles on project managemnt I’ve come across over the last couple of years is this one from CIO magazine:

The author makes some great points about making sure you understand what the project sponsor will measure success by.  He makes the distinction between a project that builds a brick making factory when the sponsor was expecting a factory making bricks – fully staffed with the ovens running and bricks going out the door. 

“The big difference between the ‘brick making factory’ and the ‘factory making bricks’ is that the latter is meeting the real objective of having a brick factory — generating revenue”

So often we see projects where the team doesn’t understand what the end goal actually is, and they spend lots of time and effort very efficiently solving the wrong problem.  They use the best methodologies, the right tools, have low defect rates, great user interfaces, have empowered teams and enjoy delivering the product – the surprise comes at the end when the customer says “you missed the target”.

How do we ensure that our participants get this message loud and clear?

Posted by Shane Hastie


Posted by on July 14, 2009 in Project Management


Tags: ,

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


The importance of WHAT not HOW when stating Scope and Requirements

Have a look at following two references from CIO magazine.

They support my arguments about the importance of using scoping techniques like the Context Diagram and the B5 technique. We should use these techniques, of course as part of understanding the “as is” business, but more importantly as a way of describing the business’s or system’s goals. this often can lead to the uncovering of additional opportunities to improve the value of the business.

The key factor when scoping and when understanding the “as is” (I prefer the term “what are we trying to achieve?” over the term “as is”) is to focus on the what and not on the how. Too early a focus on the how is as bad as committing the crime of premature design.

Posted by John Watson

1 Comment

Posted by on July 9, 2009 in Agile, Culture, Project Management, Testing


Tags: , , , , ,

Agile (note the big A) versus agile (note the small a)

I picked this one up several years at one of Software Education’s  Software Development Conferences.  I think it might have been Steve Mellor who said the worst thing to happen to agile was when it was re-spelled Agile.

I think that “agile” (note the small a) is the application of the commonsense, expressed so well in the Agile Manifesto, that competent Software Project Managers have been following for decades.  I would summarise this as:

  1. Value people over processes
  2. Deliver a little, deliver early, deliver often
  3. Don’t rush to code (no, this doesn’t contradict point 2)
  4. Don’t over-specify — don’t under-specify either
  5. Know what your test cases are before you design your product
  6. Avoid premature precise estimates
  7. Never negotiate estimates
  8. Continuously refine estimates
  9. Do negotiate what will be delivered within a spend ceiling
  10. Do not base the spend ceiling on the estimate of effort/cost to deliver the product
  11. Do base the spend ceiling on what the business is prepared to spend to gain the quantified business benefits from the project
  12. Don’t demand that people do more than they can do in a 40 or so hours 5 day week
  13. Cancel the project if it ceases to stack up against its business case (this form of cancellation is a success not a failure)
  14. Don’t base the project plan on some theoretical “religion based” (e.g. Extreme Programming or RUP) methodology
  15. Do base the project plan on delivery of product features
  16. Continuously revise the plan

I could go on and on — hope you get what I mean by “agile” with a small a — and I can’t overemphasise how important it is to value people over process: value fit-for-purpose product over too much documentation: value continuous involvement of the customers.

Now for Agile with a BIG A:  My observation is that Agile with a big A is a poorly understood (by management teams) brand — actually I think it is a fad — driven by a hope for cheaper, quicker, and better.  It possibly is driven by a “free lunch” mentality.  To pick up on Shane Hastie’s terms we are looking at a Tragile or Fragile approach that, of course, will fail to deliver.

To achieve true agility the whole team must work within a highly disciplined environment and use skills.  Few organisations are sufficiently mature to insist on the disciplines and to spend enough money on training. It is important here to differentiate between education and training: when I’m educated I know about, possibly know how to:  when I’m trained I have demonstrated my ability to perform the task to the required standard and I respond automatically as required to stimuli.

Posted by John Watson


Posted by on July 7, 2009 in Agile, Project Management