The Agile Conundrum

Written by Brad Robbins

If you’re like me, you have read and listened to vast sources of information on both predictive project planning methods and Agile techniques.  If you’re in the business we’re in here at Solution Q, you’re even more predisposed to it.  And finally, if you are going or have gone down the Agile route from a more traditional project structure, you’re probably numb and wearing glasses by now.

So yes, there is lots of information out there on this topic.  In many cases, traditionally the content was coming from the perspective of one passionate side of the argument or another.  More and more we see perspectives coming from the middle, speaking about the virtues of both approaches.  And in my opinion this is a good thing as both approaches do have strengths – and like all things in life – compromises.  A good example of this kind of perspective was written by Kathleen Hass on the blending of Traditional and Agile Project Management.

I would like to share our experience and perspectives on the topic of transitioning from traditional to Agile management practices.  Call it the initial results of our own ongoing case study – lumps and all.

We explored the idea of moving to Agile about 18 months ago when we were starting to plan a major new product platform.  At that same time we had a Development Team Lead with some interest in Agile and a desire to lead the charge on his project.  So we started down the road of running this smaller release project using Agile concepts while we were in the very early discovery phases of our larger platform project.

As the “owner” of these projects, I was an interested and very committed participant watching this unfold on two very different projects.  The initial results of our first Agile project were extremely encouraging.  As the project sponsor (or “product owner” in the Agile vernacular) I felt very engaged in the project – both in terms of input as well as visibility into its progress.  I was required to be directly involved at minimum on a weekly basis, which I committed to as part of this project anyway.  But the active engagement and meetings – both formal and informal – naturally lead to much greater participation.  Additionally, we focused very clearly on tasks and features based on priority with an assumed hard release date.  Every sprint – initially 1 month intervals – we had clear goals up front, and clear results at the end.  Now, our results and achievements didn’t always meet our goals, but at least it was all visible, and I never once got surprised.

At the same time, the other much larger, more nebulous project was beginning.  This project was still in its very early days and in fact had a much smaller team initially.  We had defined a fairly broad discovery and R&D phase to allow for some technology decisions to be made, and to get some of the required but less visible “fundamentals” in place.  This sub-project was not managed using Agile practices.  Throughout this initial project we struggled significantly with understanding where we were and when we would be done.  In comparison with the other project that was running in parallel (the Agile project), this one seemed like a black hole.  Clearly Agile must be the difference – or so that was the easiest conclusion to jump to!  And now for the rest of the story…

As we finally finished up our discovery sub-project (traditional) and published our first product release using Agile methods, we re-aligned our teams moving forward.  The majority of our resources moved over to our new platform project and a smaller group stayed on our current technology.  We established a Scrum project (our Agile methodology of choice) and updated our processes and development tools accordingly.  This included implementing a Scrum template, clearly defining some new roles and establishing some ground rules for those roles and the project in general.  We would have a Scrum meeting every day and decided to commit significantly to the Scrum concepts.

A few observations and revelations that came about pretty quickly:

We experienced the usual human divide; some people on the team jumped on board easily and enthusiastically and others struggled with the transition or pushed back.  Everybody eventually got on board. I think the team mentality forged, as part of Agile/Scrum facilitated that.

We gathered some momentum out of the gate.  While change is often difficult for many people, I have also found that it can be just what the doctor ordered to light a fire under smart, capable people who have become a little complacent – and some of us were guilty of that.

As a product owner, I committed to not only being involved in Sprint Planning and Reviews but also attending as many of the daily Scrum sessions as possible.  This was the best decision I could have ever made.  It immediately overcame one of the biggest apprehensions I had which was going an entire sprint (iteration) “blind” and then getting surprised with the progress or lack thereof at the end.

Since much of the discovery and foundation was done in the previous sub-project, the process of defining Product Backlog items (our high-level features and characteristics) and then prioritizing those became extremely valuable.  Regardless of where and what kind of project I work on in my future endeavours I will use this technique as part of my planning processes as it reminds you to think about business value to the customers you are serving, and this is never out of place.

 A couple of other things happened that reminded me a project is still a project, Agile or not.

Even within short sprints, we initially over-estimated how much we could accomplish within a given time-box.  The benefit of short sprints is that you see this quickly and can react in near real-time, but you still don’t accomplish miracles given the same human and financial resources.

We run a business, and businesses require planning outside of your projects. BUT often your projects are key inputs back into management planning.  So while everyone around the management table supported our teams approach and was enthusiastic about the work we were undertaking, we still needed to answer the age old question – when will it be done and what will that include?  Don’t let anyone fool you.  Agile does nothing to answer those questions, posed together, any better than any other methodology.  Nor should you expect it to.  It does however allow you to work towards a deadline (real or self-imposed), and challenges you to constantly prioritize requirements knowing that change is inevitable and scope is your variable.  If you can’t accept a product that is not going to contain certain features or meet certain specifications by your deadline, you have some decisions to make.  Does this sound familiar?

Now before Agile purists let me know that I am not entirely converted, you’re right.  We’re not all the way there and I’m not sure if or when we will be.  I do believe however that our hybrid approach has served us well and gives us some invaluable lessons learned that will help us make the right decisions as we evolve further.

What key things did we learn in retrospect?

First, the initial discovery project was a struggle, NOT because it was using traditional methods as compared to Agile, but because it was by its nature all about overcoming many unknowns and answering many new questions, some of which we couldn’t even anticipate up front.  And more importantly we didn’t have a good scope defined against which to measure in the first place and we let too much time go by without getting some clear visibility on progress and status.  Classic mistakes that can impact any projects success.

Priority, focus and short time-boxed delivery cycles are great practices under any name or in any methodology.  Even if you are planning and running your project using a predictive, waterfall structure, early and constant delivery and feedback increases customer engagement, input and satisfaction.

Finally, your success ultimately comes down to your people.  Specifically, putting the right people on your team in the right roles – or as Jim Collins would say “getting the right people on the bus and then putting them in the right seats”.  This is true because high quality, focused employees and consultants are generally more productive than their lesser counterparts, and they also make better decisions more often when they come to the inevitable forks in the road.  They have a better sense of when to communicate, when to raise flags and identify risks and issues, when to protest bad management decisions or assumptions and when it’s time to just put your head down and “get it done”.  Of course we are more likely to succeed if we were fully stocked with superstars.  What project team wouldn’t?  But Agile practices do NOT rely on you having the best people more than any other methodology – as is often discussed – but it sure reminds you that it is as much about people in the end as it is methodology.

Brad Robbins, Vice President Product and Customer Management. Brad is a founding partner of Solution Q, a Project Portfolio Management (PPM) software solution and professional services company.  He holds a B.P.E from McMaster University in Hamilton, ON.   Brad has spent the past 15 years in the IT services and software industry in a variety of capacities.  With Solution Q, he has been responsible for operations, product development, engagement management and successful implementation of PPM software and services.