RSS

Tag Archives: Death March

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.

http://www.cio.com.au/article/309384/self_evident_truths_project_management_truth_10_success_comes_from_being_excellent_what_how?fp=39&fpid=26092

http://www.cio.com.au/article/308478/self_evident_truths_project_management_truth_9_-_value_management_makes_sense_project_governance

Posted by John Watson

 
1 Comment

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

 

Tags: , , , , ,

With Freedom comes Great Responsibilty

Whatever life holds in store for me, I will never forget these words: “With great power comes great responsibility.” This is my gift, my curse. Who am I?

I’m Spiderman.

As with Peter Parker, I see the same holding true with agile testing. I was recently delivered a course on agile testing and I found myself repeating the above phrase but substituted the word “power” with the word “freedom” – “With great freedom comes great responsibility.”

I see agile as an adaptable framework or more accurately, a set of principles, that allow testers (amongst the entire project team of course) to look outside the “box” (testing processes) and yet at the same time let the framework help guide the testing activities.

 There are of course, certain constraints within an agile project (particularly the duration of an iteration) which means that as a tester, you need not only have to be flexible but also efficient.

I have been on far too many projects that have followed a traditional pattern (analysis, design, code, test – wait that sounds almost like a waterfall) that, in hindsight, weren’t the most effective way of building software.

 Some succeeded, alot failed.

 One particular BUFD (Big Up Front Design) project had a physical separation of the core team (Analysts lived in one area, testers in another and development in another city). There was a distinct lack of collaboration let alone co-operation and a degree of animosity between testers and the analysts. There were numerous changes to the specification within a three month period which meant a re-write of a majority of test scripts (literally thousands of test scripts) – all this without even seeing a working prototype.

This project failed – it was a death march from the beginning which was obvious in hindsight.

 I wonder if this project would’ve fared better if it was developed iteratively? Who knows? Maybe we could’ve discovered the problems earlier (and abandoned the project earlier?) or maybe the physical separation was too big a huddle to overcome?

 Many questions with many hypothetical answers.

 This project suffered, from a testing perspective, from inflexibity. We all wrote test scripts (approximately 14 testers in the team) which kept changing. We adapted but we were no where near efficient. We clung to the “box” (the teams testing process) because that was all we knew. There was no great responsibility because the responsibility was mandated by the “box”.

 From an agile project perspective, the walls on the “box” can change quite quickly – one minute it’s a box, the other it’s a cube. This can be disconcerting for some for it appears that the fluidity of the “box” is chaos but what it really is, is freedom and “with freedom comes great responsibility!”

Good agile, agile done well appears to have a greater degree of freedom in the way testing is approached and performed but with this freedom comes disciple, structure, governance – this is the great responsibility. We value working software yet we don’t sacrifice goodness for sloppiness, constant velocity for speed or good practises for dogma.

 As testers, we understand that the project context helps determine our approach, the freedom to achieve this is based on the context which in turns helps us understand the responsibility we have in delivering our part of the bargain with the project team.

Posted by Brian Osman

 
3 Comments

Posted by on July 6, 2009 in Agile, Testing

 

Tags: , , , , , , , ,