The short answer I'm hearing is this:  because they need to get better results and what they hear about Agile resonates with the problems that kept them from achieving results for their business customers.   I have to agree - what I hear is resonating with me as an exec;  as a PM who knows where the bodies are buried on past projects and hears practices that make sense.  What I hear also scares the beejeepers out of me in a few areas in terms of what has to change to get the FULL benefit of it all... But I also see (and have already gotten validation) that you can take baby steps and start getting value pretty quickly too.

A note:  My next few posts will be just that, posts more than articles, as I partake of the firehouse that is the Agile 2008 conference.  As I said in my previous post I'm here to find out how much I already knew about how to be agile and truly Agile as well as get many specific questions answered by the practitioners here.  I'll post particular answers and interesting points as I get them and find time to write coherently between the rush.  Then when I'm back, I will be processing everything and writing a few articles about key areas that are burning questions to me and others wondering what to do with all this stuff and whether to do anything and what it would mean to HOW they do things!

My first personal question was:   how much of all this did I already know and use on projects and how much is new - and should be paid attention to  (why should any of us consider doing Agile?)

ANSWERS so far:   Yes, it's been a long time since I have operated in the seemlingly-totally-reviled waterfall method and I have used some of the practices now under the Agile umbrella.  But one thing that's very clear is that using an iterative timeboxed development approach on a project is not necessarily going far enough to take advantage of what Agile methods are trying to offer.  Agile calls for not just doing iterative development and test cycles, but also specifically delivering usable, SHIPPABLE code-- that delivers real business value e.g. particular featuers--  at the end of each pretty short iteration...(Which I also knew and we've actually done some of that too.) 

But Agile practices include the admonition to have teams work this way ALL THE TIME, in a rhythm that delivers the benefits of frequent delivery of new stuff to customers and overall a new way that teams function to get very good at that, bringing about a new level of that P word that executives use, PREDICTABILITY.  (Not predictability by creating a big long schedule that you then proceed to make, but predictability in terms of your customers knowing that you will deliver value to them at regular intervals - and being able to predict those iterations or intervals better and better.

There is a lot more to Agile principles and practices to go along with this and make it real.   Achieving all of this has really interesting and sometimes mindblowing implications for the project manager role (which I am going to have to think about more) and for how team members function together. More on that in future posts.

In the meantime, I'll close this one with an initial answer to the second section of the question - is this Agile stuff in all its glory and practices worth paying attention to?  My personal answer is Yes.   And I hear it echoed here talking to people, including heads of development organizations who are already in the thick of it.  They chose to pursue Agile and try it out, because they felt the old way was not delivering value to their customers fast enough or predictably enough  (and painlessly enough!    They swear that their teams are happier.  That alone is worth pursuing further, which I will.)  Along with different ways execs and presenters here have talked about their own Agile toes-in-the-water or deep-dives, situations that led them to do it, and what they're getting out of it.

I hope this is a service to anyone in our membership who's wanting to improve how they go about projects to get the results they really need for their businesses...  I just want to lay out what i hear to help others know what's out there and what results people are having.  Let me know if there's anything specific you are wondering and reasons and results!

Cinda

Comments

Just as waterfall is never truly time-boxed sequentially (a good deal of the tasking is done in tandem) isn't Agile in some ways part waterfall? One would think, for example, that solid requirements are necessary in order to avoid wasting money on concepts that never make it into the final deliverable. Your thoughts on the topic are appreciated. Thanks.

Agile seems to me to be primarily based on effective communication and staying on top of changing requirements and status. These methods have always been used by experienced project management professionals, but now we call them "Agile". I've always thought that the human aspects of projects deserved the most attention. Looking forward to exploring the human side of this methodology.

Thanks for the article, I look forward to further updates. I'd be interested to hear how the testing cycle fits into the agile process.

I agree with Kimberly's views on Agile about effective communication. The con side I've seen is the constant pressure to deliver on every iteration - resulting in faster burn out on the human side. Developers/Designers often complain of shorter focus on the feature in hand being pressed upon by the Product Owner towards the sprint demo, while the long standing architectural work for the design backbone has lesser attention and take backseat which could be risky for the release of the product.

Unfortunately, agile is not quite as simple as "time-boxed delivery" as Cinda points out. There are many, many tensions within the agile development methodology just as there are in any PM environment. All of that said, from my experience, the agile methodologies, when implemented with a couple of key issues covered, produce a much better product with less gnashing of teeth and much more business value.

Elias:
Having a good understanding about what problem you are trying to solve is essential for any methodology (my interpretation of “solid requirements”). Approaches that take an iterative and incremental approach to developing solutions to those problems, such as agile methods, incorporate the fact that we do not understand as much at the beginning of the effort as we would like. To mitigate that risk, establish a high level picture of the problem and solution, and then flesh out the details of small bits of it at a time, then use the knowledge gained during that effort as you work on the next small bit. A critical aspect of that is picking which bits to detail out first, in which case you consider which bits deliver the most value, and focus on those first. The difficult thing being, of course, understanding how you define and measure value in your particular situation.

Kimberly:
Agile is quite a bit of “what was old is new again” in the world of software development. Perhaps the thing that makes it unique is the way the techniques are combined and surrounded with a focus on value and principles that stress the human element. Alistair Cockburn is the member of the original authors of the Agile Manifesto that has done the most work in this area.

Jinx:
Testing exists throughout the entire agile cycle. The best way to explain it is to introduce Test Driven Development a frequently used agile technique. This is the idea that before writing any production code, you write test code that you know will fail, then you write production code to make it pass. Some teams even go so far as to persist their requirements as tests.

Prasanna:
As with everything, iterative delivery is best when practiced in moderation. The focus on delivering at the end of each iteration was meant to provide a more useful means of demonstrating progress and encouraging feedback. It certainly does not preclude having an overall idea of what problem you are trying to solve. Architectural work, also when practiced in moderation is certainly important and something that should be done, but at a barely sufficient level, and it too can be built up incrementally. Start with a general overview understanding of the architecture and define bits of it as needed, not spending an inordinate amount of time doing so. As agile methods mature, you will see more discussion of this approach.

Kent, thanks for chiming in. I'll add my two cents on some of these questions.

On whether Agile is really different than what some of us have done before e.g. "iterative development".

Two points that made an impact on me: the Scrum practice of establishing a set rhythm for the iterations ("don't just do iterative development, do iterations at a set frequency e.g. every 2 weeks or every 3 weeks, to get the team into a rhythm. Time is fixed. Scope gives, release what works at the end of each iteration.") I can personally identify with the value of establishing such a rhythm, it adds extra discipline and a "regularity of expectations" to the work of the team.

The other place where Agile goes further than what I had previously practiced as iterative development was in having tight timeframes throughout which the code WORKS as a whole. "Ability to ship at the end of any iteration". No longer periods with a bunch of piecemeal code, all coming together in a magic integration time down the road, .....no "iterative cycles" that just end in a quasi-working demo or spiral model cycle that is more vaguely about conquering a particular risk. Working code. You can ship it if all you did was add a feature or two. Start to work that way. Felt to me like a more focused, more tightly wound version of iterative development than my past experiences.

Note that I don't think any of us are looking to have a religious argument about all this. "What's really Agile, what's not." We just want to know 'what's new' that we may not have tried before so we can take a look at it! Above are two aspects I took away from the Agile conference to think about for our environment.

NOTE: I received a member question about how scope control is handled in Agile... If any of you are interested in that topic, my answer and Kent's comments are provided here:

http://blog.projectconnections.com/executive_view/2008/08/how-scope-con-1.html

I’m excited to see where this goes, Cinda. Good stuff.
As for Elias’ and Kent’s discussion of “solid requirements,” I’d add that agile conceives of software development as being closer to new product development than manufacturing. What I mean by that is agile doesn’t pretend that every requirement can be staked out at the beginning. Instead, it understands that the features that need to be in the product may not be apparent until the team is well into the development lifecycle. To find out where you’re going, you have to get going first. This is really valuable because it forces a team to make decisions and dive in immediately. When teams spend too long haggling over requirements, they risk letting them go stale or unused… so you can see how the mandate to create a potentially shippable product each iteration is an important one.

Agile Programming

All, I am currently writing a paper/book (not sure how industrious I will get) that will layout a failry exhaustive comparison and mapping of many methodologies. Naturally Agile Management will be one of the topics.

Personally, I have found that the methods used should fit the situation, to me that is Agile.

I will be following this thread with interest as I work through the develpment of my "product".

I must tell you up front that I beleive Agile Mangement/Programming is nothing new, and I really don't understand what the big deal is.

One thing that does bother me about the "official" Agile curriculum is the "Scrum Master" certification. Please explain to me why Agile needs a "Scrum Master"? Why can't it be a "facilitator" or a "task master"(that doesn't sound good)? Sometimes it just seems that we try to show how special we are by applying special words. I mean even the "big" software producers develop their products around business language.

Hi Al,
I will agree that the title "Scrum Master" is rather silly (in fact some that teach the Scrum Master Certification course even make it a point that they think it is silly). From what I can remember, the creators of the method chose the term Scrum Master because they wanted to differentiate the role from the traditional Project Manager role (or at least their perception of the role based on run ins they had with Project Managers).

Their vision of the Scrum Master is someone who coaches the team and helps them with the process, but does not assign tasks, does not hassle the team for status, and does not make the vast majority of the decisions - that's the role of the team. So facilitator could been an appropriate replacement for the title of Scrum Master, but "Task Master" would be a considerable misrepresentation of what the Scrum Master Role is intended to be.

In this case perhaps words were chosen to show specialness, but I think it is more likely to encourage a new way for some to think of the role. (I say some, because I know several people who manage projects that already act in this servant- leader type manner.)