Tag Archives: Agile

The maturing or ‘agile’

kitten-yogaA deliberately provocative article on Linked-In asks the question is ‘Agile Dead?’; a discussion on how various aspects ‘agile’ invented by different individuals and groups are fading from prominence follows.  Agile is not my area of expertise but the article seems designed to generate attention without really saying anything new.

What the article did prompt in my thinking was the question ‘What is agile?’. Concepts vary from:

  • The Agile Manifesto (which is basically 101 common sense) created to overcome the failures of rigid IT development that required a 100% complete fully detailed plan before people really knew what the problem was (often referred to as ‘waterfall’ development but nothing like the original ideas in the waterfall concept).
  • Through to the agile anarchist community who’s mantra seems to be ‘trust us all of our teams are above average’ and we will make you really nice software without any discipline (a concept that ignores the mathematical fact that 50% of any group have to be below average….).
  • Then there are all of the various ‘agile’ methods from ‘Scrum’ to ‘XP’.

Ergo ‘Agile’ or ‘agile’ can mean virtually anything to anyone.  In contrast to all of these specific variants, I would suggest at its root ‘agile’ is a concept or philosophy rather than a methodology or process; useful philosophies rarely ‘die’.

What is emerging I believe is a gradual understanding that the false concepts of ‘command and control[1] and ‘certainty, based on a fully detailed plan[2] are slowly disappearing from management thinking (although there are still plenty of recalcitrant ‘fossils’ embedded in far too many management structures) – detailed planning months or years in advance of the work, done at a time where the work is imprecisely understood cannot control an uncertain future regardless of contract conditions and the exhortation of management. These ideas are slowly being replaced by an adaptive approach to projects that engages stakeholders and focuses on actually achieving the stakeholder’s objectives and realising benefits, ie, an ‘agile’ approach.

Every project and every project management system can benefit from some elements of ‘agile’ (which overlaps with many other concepts such as ‘light’, ‘lean’, and ‘last planner’. The key tenets seem to be:

  • involve your stakeholders,
  • trust your team,
  • don’t waste time planning in detail things you don’t have detailed knowledge of[3],
  • adapt to changing circumstances, and
  • wherever possible avoid a ‘big bang’ approach – iterative and incremental developments mitigate the risk of catastrophic failure.

The agile manifesto certainly highlighted these important concepts but it did not invent them. These elements of fundamental common sense are ignored in far too many situations. What the agile manifesto and the subsequent changes in attitude have done is refocus on the importance of people and relationships in any project.

On the ‘Agile front’, many of the ridiculous excesses promoted by consultants and experts are certainly fading into obscurity. Executives are learning that ‘agile’ is not a cure all ‘silver bullet’ it needs pragmatic management and proper planning the same as everything else, it just the way planning and managing is done that differs; for more on this see: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

Certainly there has been a realisation that the agile anarchist’s concept of ‘trust us’ (and their abandonment of any pretence of strategic planning and documentation) really does not work. An appropriate degree of planning, coordination and documentation are essential to achieve success, particularly on larger projects and in the longer term when the inevitable updates and maintenance cut in.

In summary, if ‘agile’ is a philosophy that prioritises people over rigid process, and it will change and adapt over time; it’s not ‘dead’ but it is evolving into a pragmatic management process. Certainly some of the narrowly defined concepts and methodologies branded as ‘agile’ are failing and being abandoned as ‘passing fads’ and new adaptations are emerging, but that’s normal. The core underpinnings of the original Agile Manifesto are still alive and well.

___________________

[1] In the 1950’s Peter Drucker identified the need for a new way of managing ‘knowledge work’, see: http://www.mosaicprojects.com.au/PDF_Papers/P070_A_Simple_View_of_Complexity.pdf

[2] “All models are wrong, but some are useful” (Prof. George E.P. Box), and every estimate used in the plan is wrong to a greater or lesser degree, see: http://www.mosaicprojects.com.au/WhitePapers/WP1051_Cost_Estimating.pdf

[3] For more on ‘rolling wave’ planning see: http://www.mosaicprojects.com.au/WhitePapers/WP1060_Rolling_Wave.pdf

Advertisements

Workflow Management

Many projects involve repetitive elements of work that take some inputs, run them through a series of processes and deliver an integrated output.  Standardising these elements of project work can create efficiencies and minimise errors.   A couple of examples include normal ‘sprints’ in an Agile project and the monthly updating of the plans and reporting in a major project. Workflow management sit one step above individual processes (particularly standard operating procedures) linking them into an optimum sequence of work.

Workflow management means to oversee the creation of a deliverable from beginning to end. The management aspect is to be able to identify the people who need to be involved in each process within the work flow and to ensure the ‘flow’ allows for input from all required parties in the right sequence. The key questions that need answering to create a productive workflow are:

  • What is the optimum sequence of processes?
  • Who needs to be involved in each process? This includes knowing what inputs are required to start the work and what outputs are produces to finish the work.
  • How to keep the momentum going within each process and the overall workflow (and the timely identification of blockages)?

A workflow can be simply designed on a piece of paper (or white board) to show the flow, who is responsible for each process and how the tasks are accomplished; or automated.

 

An example of an automated workflow management tool from http://www.comindware.com/tracker/

An example of an automated workflow management tool from http://www.comindware.com/tracker/

The key advantage of developing and using a workflow is you can expect similar results from the accomplishment of the work at each iteration, even if the people involved change. It reduces errors and provides consistent results.

Agile projects use the concept of ‘done’ at the end of a sprint. A common definition of done ensures that the increment produced at the end of sprint is of high quality, with minimal defects. Teams define the series of steps needed to reach ‘done’, and implement them routinely through each sprint. The steps to get to ‘done’ may include:

  • Code Complete
  • Unit tests written and executed
  • Integration tested
  • Performance tested
  • Documented (just enough)

Build these steps into a workflow and everyone benefits – particularly if the workflow is reviewed and updated to incorporate learned experience on a regular basis. The art is to keep the workflow as simple as possible but not so simple that it becomes simplistic.

So next time you wade through the tasks needed to create your monthly report or any other repetitive job within the overall management of a project think about documenting the work flow – it will pay dividends over time.

PGCS 2014 Update – I’ve been proved wrong!!

G-C_SymposiumThe Project Governance and Controls Symposium 2014, Canberra, is in full swing with wall-to-wall interesting presentations!

The focus of this post is the presentation by Stephan Vandevoorde on the work he is involved in at Ghent University, Belgium focused on developing  processes for the validated testing of project control tools entitled ‘If Time is Money, then Accuracy is Important’.

The problems with studying the effect of project control processes in live projects are many, the most significant being:

  • The control function generates information that influences management action causing different outcomes.
  • The ‘Hawthorne Effect’ where people being ‘observed’ change behaviour because they are being observed.
  • The uniqueness of each project, its team dynamics, luck, and the overall operating environment making replication of an ‘experiment’ difficult.

As part of their on-going work to validate Earned Schedule (ES) the Ghent team have developed a set of project networks using different topologies to emulate schedules ranging from those that are largely sequential, through to those that have a high level of parallel working.  The models are updated with a range of 9 different progress options leading to a total of 2.8 million unique data sets. This resource provides a unique test bed for evaluating the effectiveness of various predictive and preventative tools and techniques.  For more on this valuable resource, which is available for research, see http://www.or-as.be/research/database

One of the earlier studies (on a smaller simulation) focused on testing the effectiveness of various techniques in predicting the final schedule outcome of a project. And this research has proved me wrong!  In a blog post following last year’s PGCS ‘Earned Schedule comes of Age’  I lamented the fact that a detailed study proving Earned Schedule (ES) was significantly better at predicting project completion than the traditional Earned Value SPI had not taken the extra step and also demonstrated its predictive effectiveness compared to traditional CPM.  My paper Why Critical Path Scheduling (CPM) is Wildly Optimistic highlights the issues but lacks statistical validation.  As it happens, the ‘missing’ studies had been done and the outcomes presented by Stephan showed the results of a 2008 study by Prof. M. Vanhoucke (also of Ghent University) that demonstrate the superiority of Earned Schedule as a predictive tool designed to complement the true focus of CPM which should be the optimisation of resources and workflow (rather than the projection of the overall project completion – for more on this read my paper).

ES Table

So the basic research has been done, the results are conclusive and based on the research the effective controlling of projects needs a combination of CPM, EV and ES for optimum results!  The research frontier is moving towards effective early indicators such as the ‘P factor’ and intervention and with the data tools now available, statistically  significant analysis becomes feasible.

With the steady stream of papers validating Earned Schedule, I hope the flow of misleading information from a few die-hard traditionalists in the USA is finally extinguished and comments from leading authors such as Quentin Fleming and Joel Koppelman in the  4th Edition of ‘Earned Value Project Management’ (2010), that ‘The authors do not endorse [earned schedule]. Nor have they ever read any scientific studies that support [it]’ disappear.  It really does not matter what Fleming and/or Koppelman have bothered to read, making misleading statement like this helps no one.

The challenge is developing tools and techniques that help manage projects in an environment of increasing complexity – and as one of the other presenters, Stephen Hayes from the International Centre for Complex Project Management (ICCPM), traditional tools such as CPM and EV are important, but simply not sufficient in the emerging domain of complex project management, or  as my paper to the PGCS suggests, Agile projects.

Project Governance

Corporate governance is defined as aligning as nearly as possible the interests of individuals, the organisation and society. Good governance is good business!

Project governance is a sub-set of corporate governance, focused on systems that ensure the right projects and programs are selected by the organisation, and the selected ‘few’ are accomplished as efficiently as possible. Projects that no longer contribute value to an organisation should be terminated in a way that conserves the maximum value and the resources reallocated through the portfolio management process to more valuable endeavours.

Project Governance Structure

The framework for effective project governance is laid out above, and is an executive management responsibility. Sponsors and the Portfolio Selection/Management processes provide the key link between the executive and the working project and programs (for more see our Governance White Paper).

The focus of this post is to look at the pre-selection activities that inform the portfolio selection processes. One of the key conclusions to be drawn from the Ombudsman’s Report discussed in my earlier post Cobb’s Paradox is alive and well  was that many of the projects that contributed to the $1 billion in failures were set up to fail – the projects had absolutely no chance of delivering within the announced parameters: the inputs to the portfolio selection process were grossly flawed (or were non-existent).

This appears to be a wide spread issue. Most project management standards such as ISO21500 and the PMBOK® Guide start with an approved project and a business case or similar that defines what has to be accomplished; this is the end of the portfolio selection process outlined above and is assumed to set realistic and achievable objectives.

What is missing, are the steps leading up to this point; the life of a ‘project’ starts with an idea, need, opportunity, requirement or threat (the ‘concept’). The organisation assesses and studies the ‘concept’ hypothesises options and solutions and frames a proposal that becomes the foundation of a future project. These key investigative elements of a project generally sit under the portfolio umbrella developing information to allow a proper decision to be made. In mining this can represent exploration, feasibility studies, ‘bankability’ studies and concept designs which between them can cost $millions, leading to project funding. Importantly, this ‘Front End Loading’ (FEL) is seen as the key to a successful mine in most major mining corporations.

Similar problems exist in major infrastructure projects, defining a solution to prison overcrowding can involve building a new major prison, building several smaller prisons, extending current prisons, changing the way criminal justice system works to reduce the need for prison places, or a combination of the foregoing options (substitute University/hospital/school, into the previous sentence to see just one dimension of the challenge). However, unlike mining, most government and many corporate organisations see effective ‘front end loading’ as unnecessary.

Other organisations use the process to formulate definitive solutions to problems they have no real understanding of (typical in ICT) and then pretend the defined solution has no associated risk (because it is defined) despite the fact the full dimensions of the problem the project is supposed to solve are still unknown, and are frequently changing over time.

The challenge, requiring informed judgement and effective governance is recognising which development processes suits what type of ‘concept’:

  • Sometimes, the ‘investigation’ requires a significant amount of work (eg, a bankability or feasibility study); this work may be treated as a project in its own right, and is time, cost and resource constrained with a defined deliverable (the report).
  • If the work is expected to flow forward and will only be stopped in exceptional circumstances, project phases work best, with some form of ‘gateway’ or transition review.
  • In other circumstances, studies are undertaken as part of the portfolio by corporate or PMO professionals with no dedicated budgets, assessing multiple proposals as an ongoing process, but once a concept gets the go ahead a project is created and a budget and resources allocated.
  • Other concepts (particularly problems) cannot be defined and an ‘agile’ approach is needed where elements of a partial solution are developed and put into use developing new learning that will then allow the next module to be developed in a progressive sequence. However, whilst this may be the most suitable and cost effective way of developing an effective solution, budgeting in a traditional ‘iron triangle’ concept of fixed cost, time and scope is impossible.

The challenge is recognising which type of project is being proposed (based on Project Typology), and then deciding which type of process will develop the best input to the portfolio selection process and what level of uncertainty (risk) is associated with the proposal once developed. Certainty is not important, what matters is appreciating the extent of the risks and the likely benefits, so an informed investment decision can be made. Most ‘game changing’ initiatives involve high risk, high reward projects that create a totally new future!

OGC Gateway™

The OGC ‘Gateway Reviews’ is a flexible process that addresses this part of major projects from the client’s perspective:
Gateway 1 = Business Justification, options identified and appraised, affordability, achievability and value for money established.
Gateway 2 = Procurement strategy, will the proposed strategy achieve the project objectives?
Gateway 3 = Investment decision, based on realistic project cost information (eg, tenders or bids) can the business case be confirmed from both the cost and the benefit perspective?
Gateway 4 = Readiness for service. The completion of the project work and a reassessment/confirmation of the expected benefits as the deliverable is put into ‘service’.
Gateway 5 = Benefits evaluation. Did we get what was expected now the project’s outputs are being used?

Summary

Most of the risks and rewards associated with a project or program are determined long before the project manager is appointed; if these decisions are wrong (or non-existent) project and program management cannot resolve the problem.

The role of effective project management is to deliver a realistic and achievable outcome efficiently; if the parameters for the project are unrealistic in the first place, the best project management can do is stop the situation deteriorating further! As far as I know, none of the various BoKs and methodologies, including the PMBOK® Guide has a ‘miracle’ process that will magically transform an impossible set of objectives into achievable set of objectives. Wishful thinking is not an effective substitute for effective project governance!

What is Agile?

Agile? Sourced from http.yogadogz.com

Agile is not a project management methodology but Agile principles can and should be applied to the management of projects and in the right circumstances the various forms of Agile offer an effective way to develop software. In their original design, Waterfall and the various forms of Agile are software development methodologies, not project management methodologies, and effective project management adapts to the processes being used to develop the project’s deliverables.

One common misconception among IT professionals is the assumption that the PMBOK® Guide approach to project management and the waterfall software development methodology are synonymous. Nothing could be more wrong.

Certainly you can manage a waterfall development using the PMBOK® Guide processes but nothing in the PMBOK® Guide mandates developing a fully detailed project plan before starting work on development. All the PMBOK® Guide requires is the current phase is planned before starting work. This is absolutely compatible with the Agile approach to iterative development.

Another misconception is that any new software development is automatically a project. Projects are temporary endeavours; this means temporary teams. If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work, for more on this see: De-Projectising IT Maintenance

With these misconceptions cleared, there seem to be two key areas for discussion.

What are the differences in the way project management processes are applied in an Agile project compared to a waterfall project? Some thoughts:

  • There is the need top select the right projects for Agile, for more on this see: Selecting the right projects for Agile
  • There is a need for a much lighter “touch” managing an Agile project; for more on this see: Managing Agile Projects
  • There is a need for a higher level of trust in managing Agile teams, for more on this see: Advising Upwards
  • There is a need for robust change management and configuration management to track the evolution of the Agile project
  • There is a critical need to develop the correct strategy and architecture at the beginning of the Agile project

Can traditional project management learn from Agile? Some of the trends in Agile seem to have wider application in any project involving knowledge work, including:

  • The need to trust knowledge workers more than manual workers
  • Success measured by customer satisfaction rather than quantitative outputs
  • The need to keep the client involved

Our discussion paper Thoughts on Agile looks at theses questions in more detail. The paper is a ‘work in progress’ aimed at business managers who are new to the concepts of Agile (ie, it is not intended as an Agile manual for IT professionals). Any comments will be appreciated. The paper can be downloaded from: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

The Project Delivery Strategy

One element missing in much of the discussion around project management is a focus on optimising the project delivery strategy.

At the project level, strategic decision-making focuses on the way the project will be structured and managed. Choosing between using Agile or Waterfall, pre-fabrication or on-site assembly, won’t change the required project deliverables but will have a major influence on how the project is delivered and its likely success.

One size does not fit all; simply following previous choices ignores opportunities to enhance the overall probability of the project meeting or exceeding its stakeholder’s expectations.

Some of the key steps in designing a strategy for success include:

  • Familiarization with the overall requirements of the project and its stakeholders
  • Determining the key elements of value and success for the project
  • Outlining the delivery methodology and getting approval from key stakeholders
  • Developing the project’s strategic plan based on the available know-how, resources and risk appetite of the stakeholders (including the project management team)

The problem with implementing this critical stage of the overall project delivery lifecycle is that it crosses between the project initiators and the project delivery team. Both parties need to be involved in developing a project delivery strategy that optimizes the opportunity for a successful outcome within the acceptable risk tolerance of the individuals.

Unfortunately, the opportunities to engage in discussion and planning for project delivery are difficult to arrange. Frequently contract documents effectively prescribe a delivery process, and/or the client and senior management don’t know they need to be engaged at this critical stage of the project lifecycle.

Maybe its time for a change…… chose the wrong strategy and the project is destined for failure!

Selecting the right projects for Agile

I have just read an interesting article by Bob McGannon on selecting the right IT projects for Agile development. Bob is a Founder and Principal of MINDAVATION, a company providing project management training, consulting, keynotes & coaching services throughout North America, Europe, the Middle East and Australia.

Here is a précis of Bob’s guide to creating an appropriate filter for determining which projects would benefit from the use of Agile processes.

  • An eager sponsor willing to conduct frequent reviews and evaluations of the evolving product.
  • Ambitious, knowledgeable and available business representatives – The Agile process is purposefully collaborative.
  • Minimal time to verify product viability: its power comes from its ability to produce quickly, adjust consistently to new knowledge and business change but only if the learning can be understood, interpreted and absorbed quickly.
  • Minimal business exposure if the product produced is broken; it would be high risk to put a piece of functionality into a production environment if an error in that product would have a substantial impact on the business.
  • A willingness to consider a very different approach; the ability to invest in a different work and management approach is necessary for the project stakeholders.
  • The ‘DNA’ to deal with a bit of ambiguity. Priorities are consistently reassessed and work sequences changed.

The full article can be found at http://www.mindavation.com.au/articles/may10_intellections3.html

Bob’s approach is closely aligned to the ideas discussed in Mosaic’s White Paper on Project Strategy; see: http://www.mosaicprojects.com.au/WhitePapers/WP1038_Strategy.pdf; one approach to every problem seldome dilivers optimum outcomes.