Agile iconoclast or staid status quo?

Agile2007 Day 5. The best thing about this conference is that there is very little of the agitprop found at most conferences. Whereas the majority of conferences are vendor heavy, Agile2007 emphasized education and the sharing of ideas, experiences and passion around doing the smart thing in software development and project management. How refreshing. I found the whole experience invigorating.

One theme from the conference is that agile is hard to do because of the change involved. Every speaker I listened to mentioned the difficulty of moving to agile. Mike Cohn said it. Ken Schwaber said it. Gabrielle Benefield of Yahoo! said it. But they also said it was all worth it to see productive teams being successful.

Speaking of Mike Cohn, he gave an outstanding presentation on transitioning to agile. Some of his suggestions for success included using the scrum framework to help the executives transition the organization just as the software group uses scrum to help effectively create shippable software at the end of a sprint. In a messed up organization the executive team needs to create an organizational change backlog and sprint through these to help bring about the corporate changes needed to support the move to agile. This is similar to an example I heard from Roland Cuellar, Director, Lean-Agile Consulting Practice at CC Pace, about a group of lawyers who started using scrum effectively after seeing the results in the company's software group. Mike also talked about different approaches to transitioning to agile, from the conservative approach of a small seed team to the example of Salesforce.com where Mike helped transition 35 teams at one time.

Traditional software and project management methodolgies are hard to change because they incorporate lots of assumed knowledge and must do processes, just because we do it that way. It was so nice to hear all the experts and practioners of agile at Agile2007 say that moving to agile is a hard change, even a continuing challenge, but that they wouldn't do their work any other way now that they've seen the results. I'd say that this type of honesty is a pretty compelling endorsement to go ahead and investigate the pros and cons of agile for yourself and your organization. Going agile is a rigorous undertaking that takes passion and dedication, but it's worth it. VersionOne, a conference vendor, has some survey statistics on agile that support investigating further the possibility that agile might work for you. Find the survey here.

Diets don't change your habits, change is altering the way you do things. A diet works for a short time, but a real change breaks the habits that took years to create, one day at a time. Habits are hard to change, but the results are lasting and worth the effort. Agile is a status quo breaker. Iconclasts break molds and bring upheaval. Agile is madras plaid juxtaposed against an old drab khaki. Think Rodney Dangerfield on the golf course in Caddyshack. Be the Rodney Dangerfield in your organization and shake things up.

Make your plans now for Agile2008 in Toronto.

Go Agile, Don’t Fear the PMBOK

Agile2007 Day 4. There’s a wonderful Saturday Night Live sketch from 2000 where Will Ferrell shows the world how to really play a cowbell (you have to see it to believe it, your cheeks will hurt. Google "More Cowbell" on YouTube for a look) on the old Blue Öyster Cult hit, (Don't Fear) The Reaper. Now, you may ask, ‘What does Will Ferrell beating a cowbell have to do with agile?’ Well, my mind works in fun ways. Let’s just say that there were mini-cowbells on the tables at the Agile2007 banquet and they reminded me of the ‘More Cowbell’ sketch and that led me to thinking about some of the outstanding sessions I was able to see today. Like I said, my mind is a fun place to visit.

So, I started out this morning listening to Stacia Broderick discussing agile for traditional (read, PMPs and PMBOK followers) project managers. She did a great job of mapping the PMBOK process groups and knowledge areas to agile equivalents. She also pointed out that much of what is now considered agile draws on many of Edwards Deming’s theories about quality and production productivity, including his Plan-Do-Check-Act cycle. Stacia gave a great example of how a sailor will make a plan, but will adapt it based on winds and tides. She made the point that project managers need to take the same approach on projects: plan to go to a destination, but, through the use of agile methods such as continuous review, collaboration and communication, adapt your plan as needed and get to where you need to go without being rigid. Stacia also has a good article about the project manager (ScrumMaster) as a servant leader here.

Another fantastic session was with Sanjiv Angustine. Sanjiv presented an excellent overview on transitioning from traditional project management to agile project management (APM). According to Sanjiv, APM focuses on ‘project throughput, teamwork and leadership.’ This approach changes the focus for the PM from managing the flow of activities and puts the focus on ‘project context, not content' along with leadership that is based on commitments rather than commands. He had some of us participate in an eye-opening exercise to make vivid the change from a waterfall approach to an agile approach. Four people sat around a table and moved (after flipping all pennies first) 30 pennies from person A to B to C to D against the clock. Before person B could start their flipping, all the pennies needed to arrive from person A and so on. The first pass took 2 minutes and 38 seconds. The feedback was that there was pressure on the one person doing the ‘work’ and others became ‘bored’ waiting for their turn. The next round broke the penny flipping process down to more agile chunks by allowing the pennies to be passed to the next person in line as soon as the penny was flipped. The results of this agile example were impressive: 36 seconds to process the same amount of work. Comments from participates after the second pass included that they felt a ‘sense of urgency,’ that ‘they stayed focused,’ and that ‘(I) felt like a team.’ Although it was a simple example, it made the point that agile projects are more effective that a traditional waterfall project.

Michele Sliger presented an excellent session that addressed being agile in a waterfall environment. Current thinking puts the PMP and PMBOK right in the middle of the waterfall project mindset and, although this assumption is a myth, it does have enough validity to create the myth of truth for many of us. Michele gave a number of great tips on how to navigate everything from culture to contracts when adopting agile in the existing waterfall enterprise environment. An overarching key to success using agile methods in a waterfall environment is communication. Some of the good ideas that will help your agile project succeed in the traditional waterfall environment include getting a sponsor on your side, socializing agile in your organization rather than lecturing on agile, and invite and include ‘non-agile’ representatives to all of your agile planning meetings.

Michele is also working on a book with Stacia, The Software Project Manager’s Bridge to Agility, that I’m looking forward to reading when it appears in early 2008. You can look at many of the draft chapters here (one-time registration is needed). The origin of the book came from a wonderful four-part series, Relating PMBOK Practices to Agile Practices, that helped me see that being a PMP and having read the PMBOK didn’t preclude me from being an agile proponent.

So, don’t fear the PMBOK, just fill the framework with ‘more agile.’ ;-)

The views expressed on this blog are my own and do not necessarily reflect the views of my employer, Robbins-Gioia.

Agile Calms the Waterfall Whirlpool

Agile2007 Day 3. Today, I participated in an interesting workshop on Agile in the Federal Government. There was much spirited discussion about the challenges of getting agile methods into the government domain. There were also a number of stories of agencies (including the FBI and CIA) that want agile. One anecdote even mentioned an agency that recently made Scrum (the agile project management framework) a requirement in a request for proposal (RFP) that was sent out.

Waterfall development practices in the government were discussed and one person said that they didn't understand what made agile methods so special because they've been doing similar things to get around waterfall for 20+ years and didn't call it "agile." There was some interesting discussion around this idea of getting around the waterfall using 'stealth' agile. I thought of it less in terms of agile and more like Whirlpool development because the only way to really get things done in many waterfall settings is to do things under the surface of the churning water that the waterfall creates as it cascades off the cliff.

Jeff Sutherland (co-creator of Scrum) gave a compelling presentation on a number of fantastic successes in companies using Scrum. One example was really intriguing. It was a tech company that had certified everyone in the company (receptionist to CEO) in Scrum and were using this framework to drive the company forward. Jeff called Scrum a disruptive technology. Wikipedia describes a disruptive technology as "(a) technological innovation, product, or service that eventually overturns the existing dominant technology or status quo product in the market." Sutherland is talking about applied Scrum producing such large jumps in productivity that a smaller company can come out of nowhere to take over a market. He also mentioned a venture capital (VC) firm that will only invest in companies using agile methods. No agile, no money. That's one way to dam the waterfall and eliminate the whirlpool of project churn.

The views expressed on this blog are my own and do not necessarily reflect the views of my employer, Robbins-Gioia.

Agile Desserts

Agile2007 Day 2. Here's a tip: even when it's 95 outside, always bring a sweater, hoodie, or parka to your conference because there isn't any global warming going on inside. I think the A/C is set to 65 to keep all the folks with jetlag awake!

Lot's of really interesting sessions and workshops going on at Agile2007. It's so rich with information that I feel like I'm sitting at an expense account restaurant with the whole dessert tray sitting on my table! The biggest problem is being one person trying to see overlapping sessions. I've said a number of times during the conference that I wished I was Hermione Granger with her Time-Turner (see Harry Potter and the Prisoner of Azkaban) so I wouldn't miss anything.

Some of the most interesting information gathered from the conference is listening to others discuss their experiences with agile in the context of the session they have just shared with you.

One thing that surprises me here is the number of Apple MacBook Pros that are in use. Many presenters are running Windows XP using Parallels Desktop for Mac. Cool.

Bob Martin (Object Mentor) made a very interesting observation about Test Driven Development (TDD) in his presentation introducing Extreme Programming (XP). He said that TDD was the 'most profound' practice to use. He sung the praises about TDD and the increase in code quality due to the constant testing involved. If you are interested in agile methods, you might want to investigate TDD, but be aware that it is a challenging method to implement because of the dramatic change in coding practice that is needed.

Another interesting session was one by Jim Highsmith on Agile Project Management. Mr. Highsmith has so much experience and knowledge that it is hard to know where to start. He had many thought provoking things to say, but a couple stood out to me. One was to focus on user stories (requirements in agile - written in understandable language) that went across the various silos of technical focus. The idea is to work on the user story that begins to solve problems in a big picture way. He said it was also important to prioritize user stories and focus on the top three and to work through these first in any iteration. Highsmith also mentioned the idea that good agile practices cut features, not quality when schedule is constrained. This is different from the traditional approach to a project where quality is cut first.

Well, that's all for right now, I need to get back to the bonbons.

The views expressed on this blog are my own and do not necessarily reflect the views of my employer, Robbins-Gioia.

Agile Comes to the Mall

Today was Day 1 of the Agile2007 Conference in Washington, DC. Conferences are funny. If you come with a group of peers you can fit into the flow of normal patterns: you talk, you joke, you visit the Starbucks in the lobby of the hotel every 45 minutes. If you are a presenter, you are embraced and recognized. I recognized a number of the stars of the conference today and I admit I felt a little like SpongeBob at a jellyfishing exposition, "Hi Kevin, I'm your biggest fan."

It is a little different if you're alone at a conference. There is a period of awkwardness that must be worked through as you walk around finding the restrooms, checking the location of your first session, waiting for refreshments to be put out, and all the while acting a little like a clandestine operative sneaking surreptitious glimpses at as many conference badges as you possibly can without making eye contact or walking into furniture or other attendees.

Anyway, I think there is significance to the conference coming to DC this year. My feeling is that the more than 1,200 attendees who will go to the 600+ sessions, workshops, tutorials, and keynotes will represent an implicit and explicit recognition that agile has become more mainstream than alternative.

Although this conference may not be the Tipping Point for agile, it may be the Mall Point where agile moves to a recognizable destination where corporate tourists visit for an hour or a day and think they have gained deep understanding of something (agile) that seems simple, but is in reality very rigorous, broad, deep, and difficult to do well and to do right.

It seems to be a concern in the agile community (and a theme of some of the Agile2007 sessions) that those corporate tourists who will now try to use agile will not understand what the Agile Manifesto was really getting at and why it was such an important statement. I think there is a justified protectiveness around the philosophy of agile and I hope that everyone who wants to use agile methods really tries to understand the philosophy in order to affect real change.

The views expressed on this blog are my own and do not necessarily reflect the views of my employer, Robbins-Gioia.

Ted Williams was an Agilist

Welcome to my first blog post on A/agile. My disclaimer: I'm a proponent of A/agile, but not yet a paid practitioner. :-) That said, I'm a thinker and passionate about the subject I'm still learning about and I believe I can help add value to readers of this blog who might want to learn more about A/agile and project management. I welcome your questions and comments.

Since it is baseball Hall of Fame induction time, I was thinking about the processes and methodologies used by great ball players to make them successful. Do you think Ted Williams thought about a methodology for hitting? Probably not in project management terms, but he did have a definite process that he used to approach hitting a baseball and he continued to refine his process and methods throughout his career. Williams was blessed with ability and he refined his abilities through discipline and repeatable processes that gave him great baseball success.

So, what does Ted Williams have to do with A/agile? Would Teddy Ballgame call himself a Baseball player or a baseball player? I bet Ted would have said he was a hitter and a ball player and it didn’t matter how you put it, just throw the ball. The same approach needs to be taken when looking at A/agile methods and tools. If the tool can help you and your project, then study it, understand the tool and the underlying philosophy of A/agile and project management and then apply it as it fits your current project.

There are plenty of opinions, criticisms, and proponents of A/agile, but whatever you call it you need to realize that the concepts of A/agile have existed in various forms with and without a name(s) for decades. In my mind, A/agile is a set of tools that can help people, teams, and organizations achieve success. If there is something wrong with that, please let me know. :-)

See what Steve McConnell had to say about using Agile methods.


The views expressed on this blog are my own and do not necessarily reflect the views of my employer, Robbins-Gioia.