PM Articles > Executive View > How do we know whether our teams need Agile, and how do we go about it?

How do we know whether our teams need Agile, and how do we go about it?

by Cinda Voegtli

This week I’m at the Agile 2008 conference in Toronto along with Kent McDonald. I’m here to learn more about what the world is referring to as “Agile development” and “Agile project management” for my own edification, as well as to guide Agile content additions to the site for our members and subscribers. I’ll be posting a few more blogs this week as I get my questions answered. If you’re interested in Agile – or interested in knowing what the heck it is and whether you should care – I hope you’ll read on to see what I’m after at the conference. At the end of this post you can even post or email in questions you have about Agile, and I’ll see what I can do to get them answered.

By way of background, Agile development and by extension Agile project management, refer to a specific set of principles and techniques for achieving more successful development projects.  Here is the Agile Manifesto for software development, put together by a number of “founding members” of the Agile community.

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

Definitely some interesting implications for how to manage projects according to that manifesto!   While the words resonate, they conjure up way more questions than answers.   (If you want more background on what Agile is, see the related links at the bottom of this post.)

So we’re at the conference – and actually with 3 different “user perspectives” in mind:

  • Kent’s much greater experience with formalized Agile,
  • an executive colleague’s total lack of initiation into Agile in practice at all,
  • and my own situation somewhere in the middle.

I believe that over the years I have been informally introduced to key parts of what is now formally called Agile. I have become aware over time of “named facets” of agile methodology (e.g. Scrum, extreme programming) but have not used them all personally and I’m not on top of all the prescribed details on how to do those things. My entire background has not been purely waterfall development, however. I recovered a waterfall-planned project using iterative time-boxed development cycles 13 years ago. I knew about and used stand-up meetings years ago. I have built iterative variations of companies’ stage-gate processes and coached managers on how to think more agilely even if their current company processes screamed sequential waterfall phases. I’ve helped teams build customer feedback into their development cycles. All of this without suddenly changing what we called everything….

So here I am with the following questions in mind:

To satisfy my personal curiosity: How much of Agile have I actually used in the past and just not known what it’s now called? For finding new stuff that would really help our company’s teams: What philosophies, constructs/frameworks, techniques are there that I have NOT been aware of that could deliver dramatic improvements to how we do things?

For helping translate this out to our readers for their use:

Start from scratch? As I noted above, I’ve had experience showing teams how to be more flexible within whatever established process they had (rather than throwing out everything and starting over with totally new framework). I’ve seen it work sometimes and not work well enough others. So I’m curious to hear whether the consensus from people who’ve adopted Agile. Are we advised to “throw out the old process binder” and start from scratch, vs. taking a more evolutionary and experimental approach to introducing Agile techniques? When they’ve seen an evolutionary approach be successful, are there any particular “must dos” to achieve that success, and pitfalls to avoid? (Must be! What are they?!)

Agile on large projects: I can envision small Agile teams. I wonder a lot about how all the practices translate to larger efforts. Yes, Agile techniques used in all the sub-teams… but Is there anything special about how to “go Agile” at the interfaces between functional groups, sub-teams on a large program etc.?

Agile and PMOs: Does going Agile cause a PMO to have different functions for any reason? (I can’t right off see why it would, since I view Agile as a way to organize work, have people work together better etc. I’d assume that PMOs still have project duties, coaching duties, methodology responsibilities. But I also sense that the more developed Agile world talks about many things as if they’re a totally new ballgame. So I want to know, what IS different from the PMO viewpoint and why?

Agile-specific tools - optional or required? I see lots of tools companies in the Agile space. I am one of those people who tells PM newbies “If your boss thinks the way to adopt project management is to start by using MS Project, run for the hills." What’s the Agile storyline on tools - how important are agile development and management tools to being successful at agile development? What are the tools vendors delivering? What tools have people adopted that they DID think was absolutely key?

My colleague, a VP and general manager type, asked me to find out the following:

How does an exec know they need Agile? "I’m coming from a totally newbie perspective, do not know anything about Agile other than a little reading I’ve done recently. As an Exec or senior manager, what symptoms would I see that would indicate I need to look at Agile rather than work on improving how we operate within our current phased approach? I.e. if I have the typical project problems - often late, over budget, and never totally works to plan - how do I know that only Agile can save the day?"

How to test Agile out? "How can I test without disrupting what I already have going on, to see if Agile will help?"

Terminology and Processes: "I find myself interested in whether I could be a ‘closet Agilist’ rather than an overt practitioner who uses the correct jargon. Call me stupid, but I find all ‘branding labels’ [not just Agile’s] like Scrum, TQM and 6-sigma etc. a little overwhelming and disconcerting. While I like some of the principles I’ve read about, I would probably like to have them as guiding philosophies rather than feeling like I have to change everything in my organization to get the benefits. DO those experienced with Agile think that the only way is to totally throw out my existing phase-based process frameworks, change all our internal terminology etc.?"

Those are our questions about Agile. What are yours?  Feel free to post them below, or send me an email at . We’ll track down answers, and write about them for everyone’s benefit as we go forward. 

Kent has his own list of wonderings and will be posting his own blog entries this week and after the conference here. So check back to our blogs if this subject is of interest! More this week as we hit the sessions!

Cinda Voegtli

Related Items
What Is Agile, Really?
Kent McDonald discusses his Words to Lead By and the seven strategies he believes will change project management for the better.

Agile Overview and Core Methods
This paper by ProjectConnections Director of IT Content Kent McDonald provides an overview of the key historical statements created by members of the agile community to codify the value set and principles shared by agile software development and agile project leadership methods. It includes some of the history behind the creation of these statements and suggestions for applying these values and principles in a non-agile environment.

What Makes a project "Agile"?
Is the team "Agile," as they claim, or are they using that term as a cloak for a lack of discipline? One way to know is to observe what drives their activity: do they do what is cool, or do they do what the customer values?

Agile Methodologies: Age-old Ideas in Fancy New Clothes
Do exotic new names make age-old best practices easier to swallow? A scrappy project manager will happily oblige.

What Does an Agile Project Plan Look Like?
Would you know an agile project plan if you saw one? Kent McDonald compares agile planning practices to traditional PM.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

I'd also be interested to see the answer to the question: 'Ok for small, but what about the large projects?'

We tend to talk about waterfall as being strictly sequential. I have seen multiple early/demo/test releases of software being used within a completely joint co-located customer/ supplier/ user team to de-risk and optimise aviation (flight sensitive) software projects structured using the waterfall approach. So are waterfall and agile really exclusive of each other?

The manifesto recognises the need for contracts/ processes/ documentation but aims to weight the collaboration/individual etc aspects. So is there really a difference here? Aren't they saying simply that sound project management needs the former as its framework but eventual success is dependent on project managers exploiting imaginative approaches, with optimum input (collaboration/ ideas/ help/resource etc) from the customer and effective use of a range of soft skills to energise individual and team contributions?
i.e. isn't agile simply an approach project managers like yourself have used for many years in some form or another but now dressed up with terminology? - a response perhaps to some unimaginative 'project managers' who have simply followed process rules in the past?


Hi. Thanks for posting. Great question. There were a number of sessions on how to use Agile in the large and I writing up a few takeaways from that to post later this week.

As to the rest of your question about Agile, similar to mine, "is this all new or old stuff with new names"... The answer i came away with is "some of both". There are techniques and attitudes I truly have employed in the past without calling it "Agile". But I came away with a much greater understanding of some key new-to-me "must dos" of Agile that bring some unique discipline to team delivery (among other things). I am working on writing up a concise expression of what I came away with there.

When I post more on your questions later this week, I'll update this comment with the links.

Thanks again for posting, glad to hear what others are wondering, and glad to know I wasn't the only one wondering "What's really new?"


I received a member question about how project scope is protected in Agile.

I've posted a detailed answer here.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.