RSS

Author Archives: jwpegasus

About jwpegasus

IT educator and consultant. Started programming in the dark ages. First serious code written in octal and hexadecimal machine code. Early background in real-time, life-critical, mission-critical systems. Served aprenticeship with the multi-national hardware and services suppliers. Current specialities include Busines Systems Analysis and Project Management. Fluent in UML, conversant with several CASE tools. Requirements fanatic but insistent on iterative and agile approach (please not the small "a" in agile. Suspicious of current BPM fad. BPM very good when well-understood: dangerous when performed at organisation's procedure level. Definitely a methodology sceptic but a believer (sort of) in CMMI type frameworks. Favourite framework is CxONE from Construx

Agile Development: A Manager’s Roadmap for Success

Hi all,

I found this link  today on Software Quality.com

Agile Development: A Manager’s Roadmap for Success:
http://go.techtarget.com/r/9265705/9110836/1 .

It makes lot of sense to me

Posted by John Watson

 
 

“Agile” Is Much More Than a Software Development Process

I’m intrigued, bored, encouraged, and discouraged all at once: not to mention optimistic and sceptical.  How’s that for a confused and mixed up kid?

“Ok matey! So what the heck are you going on about?”

“Well it’s this agile, agility, Agile, Agility thing.”

“Okaaaay so what is it?”

“Blowed if I know!”

I’m not at all sure that I know what Agile / Agility is.  I think it has its roots in software development approaches including Extreme Programming, which I think I first heard about more than a decade ago.  Does anyone remember the even older RAD or RIP or JAD from the 1980s?  The idea, then, was to use a collaborative, non-bureaucratic, approach to quickly produce software that was seen as fit-for-purpose by its users. Well I think the present agile methods have their roots in that RADish JADish idea of getting software cheaper, quicker, and better by minimising the time and money consumed by the older stage and gate (often misnamed “waterfall”) methods.

From my standpoint, anything that reduces the power of bureaucrats has to be good — just so long as we avoid devolving into chaos.

That’s how I read Agile / Agility: it’s an antidote to toxic bureaucratitis.  It has become much larger than a software development method.  When the principles are applied organisation wide we can expect the following results:

  1. A significant reduction in the use of top down command and control management methods leading to a reduction in toxic bureaucracy
  2. The evolution of collaborative self-managed teams with a skilled project manager as the effort coordinator but not necessarily the commander:  the “commander” is the demands from the work that must be done
  3. More positive pushback through questioning the corporate worth of any project: the catch-cry is “Demonstrate that this idea will give an appropriate, measured, return on investment.”
  4. Through collaboration, the “Them versus Us” syndrome reduces
  5. Products will be fit-for-purpose rather than compliant with out-of-date prematurely frozen requirement specifications
  6. Silos will have holes blasted in their walls: collaboration kills silos and that is a very good thing.  The best way to encourage projecticide is to build silos: so avoid silos
  7. Improved Enterprise Architectures should result from less silo thinking and more integration.  An oft heard question will be “How does/should this product integrate with product x?”
  8. The possibility of continuous process improvement will increase.  Agility requires that we use retrospection: lots of reviews asking, “Is our process working?” as well as “Is the product (heading toward) fitness-for-purpose?”

The points above sound good to me.  In fact compared with the state of most organisations today the points sound positively utopian to the point of being fantasy.

So how do we achieve our utopia from our current dystopia?

Clearly two major factors apply: Cultural change and training. The whole organisation has to change and the staff members will have to become highly trained: not educated: trained.  Out of training comes increased discipline.  Without discipline Agile becomes Tragile.

Without cultural change and training Agile / Agility will remain forever Tragile / Tragility.

Where do we go to find the change agents and the trainers?  I know a terrific bunch of people who can help.  They all work with Software Education Associates Limited.

Posted by John Watson

 
4 Comments

Posted by on August 19, 2009 in Agile, Culture, Project Management, Quality, Testing

 

Tags: ,

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:

http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r

Also: a reminder … have a look at this link (first posted by Shane)  http://www.cio.com.au/article/205313/why_projects_fail_part_three_wrong_targets

Posted by John Watson

 
 

Tags: , , , , ,

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: , , , , ,

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

 
3 Comments

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

 

Tags:

More on Agile and “failure”

I agree wholeheartedly with the points raised by several people about the definition of project failure.  I think it is commonsense to cancel a project once it is realised that the business case is poor or unrealisable.

A significant question to ask is, “How often is the business case expressed in terms that could later lead to outcome realisation testing?”

My ongoing experience is that organisations still put insufficient effort into defining “proper” business requirements.  This leads on to situations similar to,”The product behaves as required but our business has not improved”: or “We got we paid for but did we get a return on our investment?”  I suggest this is a form of project failure: possibly the most significant.  A possible (I think probable) cause is a lack of Project Owner/Sponsor skill.  Do the Project Owners out there actually understand the extent of their responsibility relative to project governance?  As a way of addressing this issue, the PRINCE2 people have instituted Project Sponsor Certification (not to sure about the value of certification — but at least it’s a step in the right direction).

I think that the lack of business requirements problem is exacerbated by the Fragile/Tragile practise of “the requirements are in the code!!”  It also bothers me that so many still seem to think the business requirements have something to do with the content, look, and feel of the user interface: the classic confusion about benefit versus feature. So many organisations still call Functional (system) requirements Business requirements.

I feel that yet another issue is the seeming lack of understanding about the difference between project governance/management methods and system development and maintenance methods.  I think Agile  is a type of SDELC and project governance should wrap around it.  I wonder if we should start Agile development only after business benefit requirements are well-understood and signed forward?

Looking at the issue of software becoming more complex, yes I agree it is. But I also think that there is much larger catalogue of solutions than there used to be.  Shouldn’t we be making much more use of “software ICs”:  electronic engineers rarely design their own components — they buy them from a catalogue.  I feel that there is an argument for software construction to move more quickly than it is toward software component integration. If you can buy it, why build it? The idea of software ICs is ofcourse not new:  what has happened to all the hype about reueability from just a few years ago?

Given that software projects are more complex than they were, this could well mean that the management of software projects becomes more complex.  That brings us back to the question of how do we improve project governance (of which individual project management is a part)?

People management is of huge importance: so why is it that so many Project Management offices seem to be staffed by grey bureaucrats with EQs approaching zero?

In the end it seems to me that my maxim, “Manage the requirements and manage the people, then the project will manage itself” holds true.

Posted by John Watson

 
Leave a comment

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

 

Tags:

Software Project Success Going Downhill!

I don’t know about you, but I am sceptical about the methodology used by Standish Group to produce the Chaos Reports.  That said, the report content since 1994 has tended to support my subjective observations of the state of software production:  I did think we were improving and I do think we are now getting worse.

 Is it just me that is unsurprised by the latest update to the report that shows we are going backwards?

 I think an agile approach (with a small a please) is a good thing.  Wholesale adoption of Agile (note the big a) by organisations that have little understanding of the skill and discipline required to make it work is surely a bad thing.  I wonder if inappropriate use of Agile is what is taking us backwards.

 What do you think?

 Have a look at:

 http://www.galorath.com/wp/2009-standish-chaos-report-software-going-downhill.php

Posted by John Watson

 
1 Comment

Posted by on June 30, 2009 in Agile, Project Management

 

Tags: , ,