Tag Archives: IT

There’s Agile and there’s Agile, understand the difference!

One size does not fit every situation even in an agile world!  The focus of this new article is to identify the differences in management approach needed to maximize value in three different situations where an ‘Agile’ approach can be used.

For any Agile approach to achieve its promise, the upper echelons of the organisation need to become agile aware and adapt the way projects are initiated, funded and governed so that the project team can optimize their use of Agile processes to maximize the creation of value. Download the article from: https://mosaicprojects.com.au/Mag_Articles/SA1060_Agile_Spaces.pdf

For more papers on Managing Agile see: https://mosaicprojects.com.au/PMKI-XTR-010.php#Process1

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

De-Projectising IT Maintenance

Following on from my blog Agile is not PM, another interesting trend is the de-projectizing of IT maintenance. An article on page 25 of the November edition of PMI’s PM Network magazine, ‘Foolish Behavior’ detailed the operation of an IT shop supporting a major business. The shop used stable teams, ‘scrum’ to plan work on a monthly basis and ‘sprints’ to deliver weekly improvements. As far as I can see, the situation described by Mr. Keeler in his article is totally focused on routine operations. Stable teams working on dozens of minor objectives selected on the basis of an organisation wide prioritization is the anthisis of a project. Projects are delivered by temporary teams assembled to work on the unique project deliverable (as described in the Project Charter) and then reassigned to other work as the project closes down.

However, the substantial improvements in customer satisfaction demonstrated by Boreland and the Bank of Queensland demonstrate Scrum and Agile are useful product development and maintenance methodologies for many IT applications. The underlying principles would also be very familiar to the maintenance managers of most large facilities. A stable crew of maintenance workers, familiar with the plant look after the prioritized day-to-day maintenance issues and install minor improvements. This routine working environment only gives way to ‘project management’ when a major outage or change is required. Probably the major difference is traditional maintenance management tends to sit inside a functional organisational structure whereas ‘Agile IT maintenance’ seems to operate best in a matrix/collaborative environment.

Whilst in one sense this is a ‘back-to-the-future’ development, recognising IT as an enabler to achieve business success in the same way a plant is essential to a manufacturing businesses success. And whilst both the IT infrastructure and the ‘plant infrastructure’ need routine maintenance and upgrading; there is a key difference. The enhancement of an IT infrastructure involves far more creativity and offers far more opportunity than plant maintenance. Combine this with the idea of actively involving the users in the development process encourages synergistic improvements.

Whilst this is definitely not ‘project management’ there is definitely an emerging practice that has enormous potential to improve the day-to-day operations of many organisations with a large IT infrastructure. More later…..

Agile is NOT a Project Management Methodology

A range of IT commentators are confusing a product development methodology with project management. Agile is not an IT project management methodology any more than choosing to use pre-cast concrete in preference to brickwork is a construction project management methodology.

Agile is certainly a useful product development methodology for many IT applications and would probably be extremely useful in other situations such as developing training materials and many business change projects where most of the deliverables are relatively intangible. However this cannot turn it into a project management methodology.

Project management is the process of defining scope, deciding on methodologies, creating teams, and all of the other project management processes defined in the PMBOK® Guide. If agile is chosen as the product development methodology for an IT project it will certainly influence the way the project is planned, resourced and controlled but Agile itself is not ‘project management’. This is no different to the need to plan and execute a building project differently if all of the walls are delivered to site as precast panels compared to having workers build the walls in situ using bricks or blocks. If a project exists, project management is the overall controlling process not the selected work delivery process.

What is lacking in most commentary I’ve seen on Agile is any sensible discussion on using Agile within a project environment. The critical changes to scope management, change management, cost management and time management needed to effectively deal with the fluidity of Agile, within the constraints of a project, need discussion. Project Management is still about delivering optimum value based on a predefined framework of time, cost and output and managing changes within this structure.

It would seem many of the advocates of Agile are actually suggesting abandoning project management in situations where the client cannot really define its requirements and adopting a different form of management where conversations control the process development in a collaborative environment and the overall team’s focus is on achieving a ‘happy outcome’ for everyone. The primary constraint in this space is the resources capacity to deliver ‘sprints’ and the organisation’s budgeting process is focused on paying for a more or less stable team of people working consistently on improving the business’ IT infrastructure to service its operational areas.

This would suggest there are limitations to the traditional ‘project management’ paradigm (and I have always felt PM was a focused form of management – see Project Fact or Fiction from 2002) and the emergence of a different paradigm. If this observation is correct the real focus of discussion should be where PM works best and where the new collaborative ‘agile paradigm’ works best.

Comments are welcome and I will blog more on this idea later!!