Skip to content

what are agile planning methodologies ?

“Plans are worthless, but planning is everything.”
— Dwight D. Eisenhower

The above quote is one of my most favourite quotes, and personally I think it more than adequately describes the approach you should take to a software development project.  I would have to admit that very few projects I have been involved with have ever panned out the way they were expected to when the projects initially started out.   Despite what most of the profiles of people on LinkedIn tell you, I have yet to see any software development project ever complete on time, on budget and deliver what was expected.  To be brutally honest, this is normal in any creative planning phase.

 

In my early 20's and  for a period of 8 years I founded and ran an Industrial Heavy Duty Anti Corrosive coatings  company, which provided me the opportunity to work on over 100 industrial projects.  In my opinion, working on construction projects is probably the best experience of project management available. If there is an industry that has solid experience of how to manage a project its construction, due in part to the human race constructing buildings for 1000's of years! Despite this length and breadth of experience, very few construction projects successfully complete on time and budget. However, they always deliver what was expected!

 

It was during this time, I learned to appreciate the level of planning and preparation that went into construction projects. The scheduling and synchronisation of literally hundreds of different activities and trades an average project requires.  The planning and preparation for a building project could take far longer than the actual construction time.  Despite this effort, I still had to attend numerous site meetings where plans had to continually be altered and rescheduled to cope with a number of different variables that come into play during the course of the project.  One thing which rarely ever changed or mostly everybody tried their utmost to avoid was end date, the main reason why was that this usually incurred heavy penalties.

 

I also learned just how  difficult a task  it was to co-ordinate and plan the day-to-day activities, priorities and responsibilities of over 70 staff and to satisfy customer commitments. In reflection, I can now see that I had actually implemented a form of agile project management on a daily basis.  It was probably something close to Kanban, in which I solely focused on the Work In Progress (WIP) and the continual monitoring of progress.  I was forever in a planning loop in which everyday would require a new plan aimed at accomplishing the perfect utilisation of resources the maximum amount of efficiency and profit.

It was also during this time that I learned the value of being able to draw on experience from previous projects,  to be able to plan more effectively for future projects.  I was able to quickly estimate, given the dimensions of a building how long my teams would take to paint, and more importantly the resources and costs.   I never really required the detailed estimates for my daily planning activities for allocating resources.  I could use just ball park estimates to not only estimate how long it would take to do the job, but I could also use these rough estimates to gauge the progress of a job.

 

“Genius is 1% inspiration, 99% perspiration”

Thomas A. Edison

When I started working as a Software Developer, I was shocked at the inability of most software teams to be able to derive rough estimates for a project.  Most of the projects I became involved in during the early years, were large scale enterprise projects which seem to have teams of people whose core responsibility of deriving estimates which were frankly really way off the mark.  I had the opportunity to work within these teams and see for myself the incredulous efforts they put in place to derive their absolutely meaningless estimates.

Urban legend has it; Edison made a thousand prototypes before his first bulb lit up. Later, he added that many of life’s failures are people who did not realize, just how close they were to success when they gave up. I recently finished reading, [amazon text=The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win&asin=0988262509], which I found not only enlightening, entertaining and hilarious, but also scarily reminiscent of  organisations and projects  I have been engaged  over the years.

 

I have recently read the results of the Standish Group 2015 Chaos Report , which indicates a trend from previous reports and recent survey, how smaller projects have a much higher likelihood of success than larger ones.

 

Due to the increased adoption of agile practices over recent years, the report also compares project outcomes between agile and traditional waterfall projects.  Across all project sizes agile approaches resulted in more successful projects and less outright failures.

 

Following favourable results of the report, there will undoubtedly be increased adoption of agile project management methods. However, there is no one size fits all approach due to the fact that  Agile, Scrum and Kanban each have their supporters and places where they do well.

 

Personally I have found that software development project planning often works best when we use a sequential combination of them, appropriate to what is currently happening on the ground. I have previously blogged about, Is your Project Agile, Scrum or Kanban ? and thought I would dig a little deeper on this issue here.

Agile Planning

Agile is by far the most comprehensive. It provides a structure that begins with project vision / conceptualisation, and goes as far as a celebration when the job is over, and retrospective discussion afterwards. However, the emphasis on daily planning meetings may dent freethinking, and even smother it.

 

Scrum suggests to  ‘forget all that bureaucracy’. There is a job to do and today is the day we are going to do it. Although the core Agile teamwork is still there it ignores macro project planning, and could not be bothered with staying in touch with customers. If using Scrum, it is best to give those jobs to someone else.

 

The joker in the pack is Kanban, It believes that rules are there to substitute thought, and that true progress only comes from responsible freedom. It belongs in mature organizations that have passed through Scrum and Agile phases and have embarked on a voyage towards perfection.

 

A great book on this topic [amazon text=Agile Estimating and Planning&asin=0131479415]

Despite the reliance on methodologies and frameworks,  there can be no substitute for human leadership, especially when defined as the social influence that binds the efforts of others towards a single task.

 

This is my main gripe with the software development industry, in that from my experience it appears we tend to put too much faith in a process or methodology to overcome good old fashioned human leadership.  We tend to believe that introducing all sorts of new tools, processes, frameworks and methodologies that our projects will become successful.

 

I am a firm believer in agile project management methodologies and have had the opportunity to have practiced most of them on a number of different technology projects. However, what is often the root cause of failure in agile projects is the lack of  clear and transparent communication and collaboration between human beings.

Latest posts by Gary Woodfine (see all)
Tags: