RSS

Category Archives: Project Management

What actually happens on an Agile Project – part 1

I have frequently been asked about how work actually changes on an Agile project. Here is the first part of what I hope will become a detailed examination of what actually goes on inside an Agile project:

I’ve been working with a team at a company in New Zealand recently, mentoring and coaching their implementation of Agile practices.

Last week we had a series of workshops to scope and define a new project. This is a major rewrite of all their branch systems, with an SOA link to the core legacy system backend. The basic architecture has already been defined, largely based on the existing technology environment the company works with.

The team consists of project manager, iteration manager, developers, testers, business analysts, the project sponsor (senior manager responsible for the branch network), a branch manager, and four branch staff members– one from head office, three from branches around the country.

We started the workshops with the project sponsor setting the scene – explaining his vision for what the company is trying to achieve. We then used a brainstorming approach to define the key success criteria for the project. Each person wrote their own understanding of their key success criteria for the project on post-it notes which were then stuck onto a flipchart. We grouped and clustered the statements, following which we agreed on the key drivers for the work (which is more important – deliver on time, meet budget, meet functional requirements, meet quality needs …).

Once we had a common understanding of the goals and drivers for the project we spent the bulk of the afternoon of the first day identifying key stakeholders, constraints, assumptions and risks – again using a brainstorming and discussion approach. We ended the day with a set of flipcharts around the room that identified the overall scope of the project, key success criteria, assumptions, constraints and risks (with trigger points and mitigating actions identified for the currently agreed most important risks).

We then defined the key features that the new system needs to have in currently understood priority order. This formed the basis for the next day’s discussion about specific features and releases. The second day started by reviewing the wallware from the first session, double checking that we had a common perspective. A number of items were reprioritised at this point as people had pondered them overnight.

We then took each feature in turn and broke it down to the level of user stories. Some of the stories were in the <as a> <i want> <so that> structure, but most were simple one-line statements of high level requirements. We then prioritised the stories and roughly grouped them into three releases.

It is understood that the releases are not fixed, but this is an initial starting point. We focused most of the teams’ time on features and qualities which must be delivered in the first release, which has a clear target date. The remaining features have been identified and ordered, but only in a loose fashion – this is expected to change as we actually do the work.

One clear outcome that has already been of benefit is the way expectations have been set. The project sponsor acknowledged that their initial goals were unrealistic, and already expects to either cut scope or spend more money than was originally allocated.

The business analysts have found that their role is largely facilitating the workshops, and asking a lot of “what if” questions. They are also taking responsibility for recording the decisions that are being made in the workshops and keeping the team focused on the task at hand.

The next step is to take the top 10 or so stories and expand them in detail. A workshop has been scheduled, involving the same team for next week. The technical team are setting up environments and doing all the iteration zero tasks in the meantime, so we’ll be ready to start work with the workshop.

I’ll post another message explaining what happens with the next workshop – we’ve labelled it “story elaboration” and the intent is to expand on the stories so the team can start work on iteration one immediately after the workshop. The key user representatives will be collocated with the technical team for the duration of the project and there is strong management support, so the project should be set up for success.

Many Thanks to the team – you know who you are 🙂 

Posted by Shane Hastie

 

 

Tags:

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

 
 

STANZ 2010 – Who and what???

Someone recently asked me “if you could ask any person anything, who would you ask and what would you ask?” This was very thought provoking…and reading the discussion on the STANZ LinkedIn Group made me think about it too. Who and what? To assist I cast my eyes over my bookshelf, blog list, and magazine subscriptions.
Who would I ask and what would I love to hear them talk about?

Rex Black – metrics – best ones, quick wins, most effective

Michael Bolton – metrics – as above (I love to hear the variety of approaches)

Dot Graham – Automation

Capers Jones – estimation, metrics again (am I boring??)

Lisa Crispin &/or Tip House – testing agile!

Karl Wiegers (I know he does requirements – BUT….) – how to test requirements

DeMarco & Lister – Peopleware is a FABULOUS book – more on the soft skills and understanding how testers can work better.

Critical Thinking….anyone who can talk about how to expand my mental horizons and think “outside the square”.

Wow…and the list goes on!

Who would you ask, and what would you ask?

posted by Sharon Robson

 
Leave a comment

Posted by on September 17, 2009 in Project Management, Quality, Testing

 

Tags: ,

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

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: http://www.cio.com.au/article/205313/why_projects_fail_part_three_wrong_targets

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

 
2 Comments

Posted by on July 14, 2009 in Project Management

 

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