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 firstname.lastname@example.org . 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!
Related ItemsWhat 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.