Posts Tagged ‘Waterfall’

Is my Prince now a frog?

Comments Off on Is my Prince now a frog?
February 26, 2014 · by Ray · Project Management

frog-prince2v2Is PRINCE2 still relevant in an agile world? Or like in the fairy-tale, has it lost its relevance and changed into a frog? Well, no… it is still very relevant for two reasons:

  • Certain projects do not require an agile approach
  • Certain projects prefer a blended (waterfall and agile) approach. It was seen in my last post that the term Water-Scrum-Fall has been termed to indicate that the market currently seems to prefer ( or pragmatically accept) such a blended approach.

PRINCE2 is not the only option when considering a traditional methodology but it is a popular one and one that blends in well with new Agile project methodologies such as the Agile project management framework  which is derived from DSDM.

PRINCE2 Structured Project Management

PRINCE2 is a formal, structured approach to project management. It recognises that there are three major levels of activities:

  • Direction (Management Sponsorhip)
  • Management (Project management)
  • Delivery (Solution development and delivery)

The major focus of PRINCE 2 is in management and direction. Delivery it treats as a black box because it may be internal or external. Prince2 does not dictate how delivery is  done but it does state the expected communication and deliverables.

A PRINCE2 project looks like the following:

Prince2-Process-Trans

In fact, the 2009 revision to PRINCE2 reiterated its underlying simplicity by recognising explicitly seven principles:

  • There is continued business justification for a project (or you should stop!).
  • There are defined roles & responsibilities (everyone knows what they should – and should not – be doing).
  • Manage projects by stages (bite-sized chunks are easier to track).
  • Manage by exception (don’t micromanage or meddle when things are going fine).
  • Focus on products when you plan (think things you can measure and tick off a list, not open-ended tasks).
  • Tailor the process to a project’s size, complexity etc.
  • Learn from experience! If that didn’t work last time, change it!

It doesn’t say anything about how you should build your products.The only things PRINCE2 says about making things is the following:

  • focus on products when you plan;
  • break down complicated products into smaller ones, until each unit needs around 5-10 days’ effort to build;
  • factor quality procedures into your building process;
  • have a mechanism to hand a product-to-be-built over to the technical team – a spec of some kind (PRINCE2 calls this a “workpackage”) – and a way to sign off built products that come back.

PRINCE2 and Agile as a Blended Approach

PRINCE2 can be used to manage the project and Agile  methods can be used to deliver the solution. The two methods are entirely complementary; they touch only in the definition of what constitutes a “workpackage” – and they even agree on how big that should be!

Project-Mgt-Frameworks3

 

A paper on integrating  DSDM and PRINCE2 is on the DSDM website. Another option is to use PRINCE2 for direction and use an agile Project management methodology  and solution delivery. Agile Project Management is an initiative which extracts the Project Management elements of DSDM Atern and makes them available as Agile Project Management – a certified approach in its own right. This can then be combined with popular Agile solution delivery approaches such as Scrum and XP. This is detailed in this Agile Proect Framework for Scrum document.

What about “Just Agile please”?

In some cases the requirement may be to go completely Agile. This is possible as long as the direction provided is agreed and sufficient for the company leaderhip.  Agile Project Management derived from DSDM (Shown in next 2 diagrams) or Disciplined Agile Delivery  (Shown in bottom diagram )may be used.

DSDM-Artefacts

 

Journey-so-far,-1-project-f

 

disciplined-agile-delivery

Can an elephant be agile?

Comments Off on Can an elephant be agile?
February 26, 2014 · by Ray · Business Solutions, Project Management

Who says you can’t be big and agile?

agile elephantLou Gerstner of IBM famously said “who says elephants can’t dance?”  Can big organisations act in an agile way? Do they have to throw everything (traditional methodologies) out and start again?  To be agile do you have to go completely Agile and use all Agile methodologies.? Most companies according to research seem to be adopting a hybrid approach. The term Water-Scrum-Fall has been coined by Forrester to describe waterfall processes at beginning and end and Agile (Scrum) in the middle.  It recognizes how many firms blend an approach of writing most requirements up front, using time-boxed sprints to code, and then falling back on traditional big-bang deployments.  Sure there are some companies that are fully agile and Agile but there are some that are fully waterfall but can still adapt sufficiently to their environment. Why? Because they have different problems to solve.

Different customers  require different approaches

Agile methodologies tend to be better in smaller and innovative environments. Waterfall are still best for very large scale project coordination and where features must be delivered at a certain time e.g a datacentre move.

  • Management need a business case. A new product development  requires investment and a return on that investment within a specific time. Management require a business case and a plan and a commitment to deliver. Sufficient planning and detail is required on what will be delivered and when.
  • Operations require predictability. They require new features at a specific time in a way that can be launched without causing outages, or downtime on critical services.
  • Complex projects need co-ordination and formal communication. In complex projects with multiple teams they will be dependent on each other to deliver specif items with specific features at a specific time.
  • Customers have their own preferences. They may or may have the time to be giving constant feedback
  • Are the requirements stable and known, or unstable and unknown?
  • Do critical and expensive resources require to be scheduled?
  • Development teams can only predict so much. The only risk free prediction is when it is delivered. Documenting the future may kill the future.

There is no one size fits all. The trick is to apply the right approach in context, according to the needs of business leaders and recognizing the pace that the organization can successfully absorb new ideas and new methods and if they are right for the problem in hand.

But approach is only a part of a successful solution

Regardless of approach the following parameters will have a large impact on the success or failure of a project.  If there is no management sponsorship then a major project will fail. If the business objectives are not clear then it will fail. The amount of information available upfront may dictate approach. Little information upfront may dictate  an agile approach…but it will probably also mean that only a little money is approved and that approval will be required after every increment. A company that is dominating its market and is deciding to spend some of its cash pile on entering a new market is in a much different position than a company that is a follower in the market and is trying to deliver a large customer contract.

It is more important to be agile than to be religious about Agile methodologies.

Parameters For Success
Market Position & Maturity Product Organisation Culture
Acceptability of Change Management Sponsorship Clear Business Objectives
Strong Customer Involvement Optimal Project Complexity Optimal Project Size
Team Skills Team Emotional Maturity Project Management Expertise
Tools & Infrastructure Information availability

 

Parameters derived from my own research and experience. Used the Chaos Manifesto 2013 for some input. (There are questions over the details of their research but some of the macro stuff seems ok)