Welcome to Agile Colony. These are my thoughts, opinions, experience and viewpoints about Leadership, Corporate Culture, Agile Software frameworks, Technology Trends and other various aspects of Business Technology.

 

Book Review: Managing Agile Projects - Kevin Aguanno

Kevin Aguanno’s “Managing Agile Projects” is a must read for the modern project manager.   Notice that I didn’t say Scrum Master or Agile Guru.  No this book is refreshingly unbiased and although written for an Agile audience, pays tribute to the incorporation and value of some traditional methods.

Kevin’s book illustrates project management from a 360 degree viewpoint where he disputes the need to be polarizing with just one way of doing things when it comes to project or program management.   The book explores the empowering and self managed aspects of agile frameworks while also counter-balancing with the need for some process, some understandable controls and some necessary policy when projects scale or when more traditional planning exercises can benefit an agile project and are worth the early investment.

The book effectively straddles both the world of the Agile-purist and the Traditional detailed planner giving credit to both, but it answers and provides direction to solving the one, big question we face in software projects, “Are traditional methods working effectively and if not, how can Agile improve delivery?”

There isn’t an Information Technology shop in the world who doesn’t face this challenge.   Kevin’s book is a great tool in the arsenal to help provide some of the answers to moving the needle closer to a satisfactory solution for all of us who want to do it faster, better and cheaper.

Give it a read.

At work I’m considered the Agile Evangelist by some and “Agile Boy” by others.  Yes, I was once called, “Agile Boy” by a colleague.  You know those colleagues right?  There the ones that think “Agile is the Devil!”.
They are also the folks who truly believe Agile and Lean methods require no project plan; in fact some believe Agile preaches no planning at all.   This is a common misunderstanding that traditionalists hang their hats on to knock Agile down a few pegs in favor of BDUF (Big Design Up Front) projects.  
The truth is that Agile demands that a project vision or feasibility develops into a plan and that plan provides enough data for the business (business, not I.T) to make an informed decision towards validating that the vision should have some form of investment placed behind it and we should start an initial iteration or proof-of-concept to further validate our initial plan.
Agile requires more planning than any methodology known to software project management.   The message in the Agile Manifesto of “Responding to change over following a plan” is intended to mean, “plan, build tests, analyze, design, code, validate tests, demonstrate working software” REPEAT.  They never intended to infer that we sit down and start coding our way in the dark.  Conversely, there are Agile purists that believe you should.  Both extremes contribute to the great many software projects that fail.
So repeat planning?  Yes, over and over again to tighten the vision into demonstrable product over a period of time-boxed iterations or sprints.   That’s the agile premise.    The PMI (Project Management Institute) embedded a similar construct in the PMBOK several years ago.   They call it, “Progressive Elaboration” aka.  learning as we go which all projects despite methodology inevitably do regardless of planning accuracy, and “Rolling Wave Planning” which is simply, take what you learned from the last “wave” and plan again, reforecast and tighten up your project timeline.
Sometimes we want to believe something instead of investing a little time to understand it because it feeds our innate desire to avoid change.   Change is good, especially in Technology fields; it’s impossible to avoid.  
Speaking of change, did you notice in the 4th paragraph of this blog entry how I mentioned, “build tests” before coding?  There’s another concept that causes I.T. “faith wars”…more on that some other time.

At work I’m considered the Agile Evangelist by some and “Agile Boy” by others.  Yes, I was once called, “Agile Boy” by a colleague.  You know those colleagues right?  There the ones that think “Agile is the Devil!”.

They are also the folks who truly believe Agile and Lean methods require no project plan; in fact some believe Agile preaches no planning at all.   This is a common misunderstanding that traditionalists hang their hats on to knock Agile down a few pegs in favor of BDUF (Big Design Up Front) projects.  

The truth is that Agile demands that a project vision or feasibility develops into a plan and that plan provides enough data for the business (business, not I.T) to make an informed decision towards validating that the vision should have some form of investment placed behind it and we should start an initial iteration or proof-of-concept to further validate our initial plan.

Agile requires more planning than any methodology known to software project management.   The message in the Agile Manifesto of “Responding to change over following a plan” is intended to mean, “plan, build tests, analyze, design, code, validate tests, demonstrate working software” REPEAT.  They never intended to infer that we sit down and start coding our way in the dark.  Conversely, there are Agile purists that believe you should.  Both extremes contribute to the great many software projects that fail.

So repeat planning?  Yes, over and over again to tighten the vision into demonstrable product over a period of time-boxed iterations or sprints.   That’s the agile premise.    The PMI (Project Management Institute) embedded a similar construct in the PMBOK several years ago.   They call it, “Progressive Elaboration” aka.  learning as we go which all projects despite methodology inevitably do regardless of planning accuracy, and “Rolling Wave Planning” which is simply, take what you learned from the last “wave” and plan again, reforecast and tighten up your project timeline.

Sometimes we want to believe something instead of investing a little time to understand it because it feeds our innate desire to avoid change.   Change is good, especially in Technology fields; it’s impossible to avoid.  

Speaking of change, did you notice in the 4th paragraph of this blog entry how I mentioned, “build tests” before coding?  There’s another concept that causes I.T. “faith wars”…more on that some other time.

Agile Community of Practice Members Showcase Their Creativity...

Great PMI Today article featuring creative videos from various teams documenting their discovery and success stories with Agile development practices.