« Calgary APLN Meeting: PMI Framework and Agile | Main | Calgery APLN Meeting Slides Posted »

May 13, 2008

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834527c1469e200e5523b43268834

Listed below are links to weblogs that reference Agile Alliance Update:

Comments

Thanks for the kind words.

"post-agile as an expression for beyond agile seems a little self-contradictory me."

That reminds me of the Eagles song lyric: "You can check out any time you want, but you can never leave." :-)

-Jonathan

Hi Jonathan,

Yes, we are stuck in it forever! Aaarrgh!

Re-reading my post I see that my statement is also self-contradictory. “Post-agile by definition comes after agile”. All I was trying to say was, since agile promotes adaptation it should be able to continue evolving and absorb the good new ideas that come along. I don’t want to be stuck to a mummified manifesto or petrified principles (not that they are) but instead continue evolving.

I guess small changes can be absorbed via evolution, then every once in a while a major shift causes a revolution that replaces the dominant thinking. So far the discussions I have read around post-agile have been small changes that could be absorbed. I hope the next revolution is not a switch back to formal methods, but some right angled departure along a new avenue to explore.

Regards
Mike

Good points. :-) At any rate, we should talk one on one someday if you're curious about my thoughts.

Post-Agile (as in "post-capital A Agile" or "post-the Agile movement") is different from post-agile, as in "agile" in the dictionary sense. It's difficult to explain, and Jason Gorman and I will freely admit that there is probably a lot less to it than people think. Furthermore, we are all about getting results, and have both found that Agile practices, taken too far, often get in the way of delivering solid software. Furthermore, skill is an often overlooked factor. A skilled team can accomplish just about anything, no matter what the practice is. I mis-attributed a lot of early Agile successes I was a part of with the Agile process we were following.

Some people have left the Agile movement, retaining what they want to keep, and pushing forward. They don't want to be reabsorbed back into "Agile" proper, but want the permission to experiment more and not go back to BDUF or a phased approach (unless that works for them.) Post-Agilism is one idea, and one outlet to support innovation when feeling stifled. I've used the concept to help a team that had an Agile failure. Management wanted to return to the old ways that were ineffective because it felt safe, but post-Agilism helped the team retain the good Agile practices they were using when things went south. So in that regard, post-Agilism helped further the Agile cause in that company, because it helped the team reach their goals.

It is a bit irritating to have every neat manufacturing idea suddenly be called "Agile", even if it was called theory y or theory z management, or lean, or TQM or something else in the past. Or have the idea misconstrued that if you leave the Agile movement, you are against iterative, incremental delivery, high customer involvement, high levels of communication etc. You can get all of those things without being "Agile". In fact, people did it for years before 1999-2001. As Jason Gorman says, just because I don't like McDonalds doesn't mean I hate beef burgers. However, I do see some contradictory "post-Agile" marketing, like "post-Agile Scrum" or "post-Agile Lean" which muddies the waters further. That's what happens with terminology though. Terms get hijacked whenever money is involved. Jason and I are kind of an anti school of programming thought that wishes to embrace anything that helps us get the job done, Agile-approved or not. It's fascinating to look at software development practices from the mid-'60s, or to look at successfull BDUF, 'waterfall' teams for example.

I'm much happier being "Agile fluent" than being "Agile". My software toolkit diet is far more varied and balanced without worrying about Agilism anymore. But that's just me. If Agile processes are doing it for you, keep doing it. There's more than one way to deliver software successfully. As a tester, I try to pride myself in being as process and tool agnostic as I can be. If an Agile practice is working, great. If not, what do we do about it? Too many times we put Agile processes on a pedestal and keep repeating the same things that weren't working in the past without figuring out what we value, and how to use our tools and processes to help us achieve our goals. Post-Agilism is just one way I think about solving that problem. It's helpful for me, Jason and others, but confusing for many others. If I could communicate more clearly maybe that would help.

-Jonathan

Thanks for this explanation it helps me understand your view much better. I also agree we should chat face to face, we should have lunch sometime soon.

I think we are in broad agreement. We both just want to get better at delivering software, if that means abandoning our current approach and instead wearing silly-hats, I would be all over it. I too borrow from a selection of approaches as project and organizational circumstances dictate. I think you have to. Within the same project I often start off quite traditional until we have Feasibility done and then switch to a more iterative, incremental approach for delivery, flipping back to traditional for training and rollout.

I believe where our discussion lies is around if moving beyond Agile is post-Agile or just a continuation of being Agile. When I hear about teams who struggle with Agile, assess the situation, choose to keep the parts that work and abandon the rest, I see this as being Agile not becoming post-Agile.

To me agile is not something you do it is something you are. You do not have to follow x% of processes or activities to be Agile. However, this is really just semantics. I’m not so bothered with what we call it just as long as we continue to get better. Agile with a big “A” or small “a”, who cares, teach me how to be better.

Regards
Mike

"When I hear about teams who struggle with Agile, assess the situation, choose to keep the parts that work and abandon the rest, I see this as being Agile not becoming post-Agile."
Sure, but that's just part of the picture. What about using practices that would be considered un-Agile as well? What about teams that create strange combinations of practices, some of which most Agilists might find too "Tayloristic" or "waterfall" but it works for that team? I don't think the Agile movement has a monopoly on innovation, even though there have been some great ideas that have come out of it. I want to hear more stories of alternative ideas people have used to solve problems. Unfortunately, many of those ideas are labeled as "not Agile" on teams I've worked on. I got tired of the divisiveness and bigotry and decided to try something from without the Agile camp. There's nothing worse than seeing a team struggle, and have one member suggest something to help, only to be told: "That's not Agile!!!" and have the idea turned aside. After a while, I thought, "maybe they are right, but who cares if it is Agile or not?"

Maybe "formerly Agile" is a better description of me. Or maybe losing the "Agile" thing altogether would clear away some of the confusion. Some of us don't want to be in the Agile movement anymore, but still use some Agile practices, tools and ideals. Why do we have to be called "Agile" or a continuation of Agile? I'd prefer to just call the whole thing "software development" again, and forget about the "Agile" and "waterfall" ideals/strawmen. "Agile" was a good step in the right direction, now let's not get complacent. Let's build on that and improve. On that point, I believe you and I are in violent agreement. :)

A pure implementation of either Agile or waterfall is either very rare, or does not exist. On our real, live projects, we have limitations and have to make trade-offs one way or the other. Some "waterfall" teams I've been on did a lot of incremental work and had user experience influences, strong customer involvement, collaboration-friendly contracts and lightweight documentation. They were successful in shipping software that the customers valued. Some so-called Agile projects I've witnessed had little customer involvement (other than the product owner who drew the short straw), no end-user focus, and reams of documentation. They weren't successful at providing value. I expect we all fall somewhere within the continuum, either tending towards one direction or the other. I imagine few of us would be purely Agile or purely waterfall. There are other ways to look at this as well. What did we call iterative/incremental projects before the Agile marketing term was coined?

At the end of the day though it is mostly just philosophical. I think it goes beyond semantics, but it isn't a big deal. On real projects, you and I probably do similar work. I may help a testing team adjust to Scrum, or the whole team figure out how to manage backlogs better, or make decisions about priorities, what to test, etc. etc. If it gets people thinking about providing value to their customers and themselves, questioning their processes and tools, and experimenting to see what works for them as they try to reach their goals, then I'm happy.

Anyway, let's do chat about it face to face. :-)

-Jonathan

I think we are in violent agreement that the true value lies in continually looking for ways to improve, regardless of labels we apply to how we work. I also think we probably work in similar ways. Yes, let's chat face to face, but I wanted to thank you for the dialogue you have shared here as it likely useful to other people too.

Mike

Thanks Mike. I always enjoy chatting with you, and I like your work. Furthermore, your "No Glory in 'The Middle Way'" post resonates with me a great deal.

-Jonathan

The comments to this entry are closed.

AddThis Social Bookmark Button

Your email address:


Powered by FeedBlitz

Tracker

  • Google Analytics
Blog powered by TypePad
Member since 07/2006

May 2012

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31