Increasing Business and Technology Throughput

Agile development techniques leverage cards in a variety of ways.  Tools for estimating, placeholders for conversations even task management devices.  This is a quick exploration of the many ways in which cards can be leveraged in an Agile Development project.

If you've been using agile techniques in your development process at some point you've come across the use of 'cards'.  Mike Cohn and his company, Mountain Goat Software, have introduced the idea of a Planning Poker game to assist in estimating effort.  Ron Jefferies emphasizes the 3 Cs, Card/Conversation/Confirmation , as a mechanism to manage requirements and facilitate business stakeholder/developer collaboration.  David McLean recently created an online version of this tool at his website, www.cardconversationconfirmation.com.  I've consistently used cards as a task management tool to manage work and provide a kanban style mechanism of identifying priorities and provide a visual radiator on progress.  All of these techniques use basic index cards (although these days you can get quite a bit fanicer with custom planning poker cards).

One reason, index cards are so useful in managing complex software development processes is because they're so simple.  Index cards are readily available (I've personally driven to many Office Depots to grab cards prior to facilitating planning sessions at client sites), they require little in the way of training, they're highly tactile and they're inexpensive. 

A frequent response to complex problems like software development is to find a comprehensive 'solution' to manage all of the myriad complexities that get introduced with writing software.  Features like a "database of requirements with an index of attributes", a detailed history of estimates, forecasts and actuals, versioning of every change made to a requirements by author and time... the list goes on.  Solutions like Requisite Pro, Doors and Caliber RM all come to mind.  All of these features have merit and there are legitimate times when a project might require some of them.  However, in most software development efforts the most important goal is creating working software.  Index cards become one of the most valuable tools for managing this process. 

This might sound heretical for a project manager but on many of my projects I didn't spend much time analyzing estimates and actuals.  At the end of an iteration I simply gathered all the completed cards, put an elastic band around them and they became another brick in the wall of our software development process.  If someone wanted to know what had been done from one iteration to another, I would weigh the two bricks in my hands and offer an assessment on whether velocity was increasing or not.  My focus was on enabling the teams and increasing their productivity.

Cards also have other uses.  A colleague of mine once said that at his software development company they used the the old cards from previous iterations and projects to wallpaper their meetings rooms.  I'd like to see someone do that with ReqPro!

Posted by Bryan Campbell at 08:25 AM | Permalink | TrackBacks (0)

A well defined practice of agile projects is to conduct a retrospective at the end of each iteration.  These support continuous improvement and most projects eagerly embrace the idea.  Unfortunately, they can quickly lose their effectiveness when they become boring or predictable.  If your retrospectives are running out of steam try these techniques to re-energize your retrospectives.

Agile development emphasizes continuous improvement along the lines of the Japanese concept of Kaizen which focuses on improving the entire process and its end results.  One of the most important aspects of these Agile techniques is the Retrospective.  Retrospectives are intended to gather the entire team (including product owners and even sponsors) together to discuss what went well and what could be improved for the next iteration.  The intent is to provide a safe opportunity for all team members to share their perspective on what's working and what's not.  For most agile project participants this can be very empowering and it introduces a powerful communication and collaboration technique to enable teams to increase productivity and take pride in their work.

Unfortunately, most teams get little direction or support beyond the idea of having a retrospective at the end of their iterations.  Generally, they start well but over several iterations attendance of product owners start to dwindle, many of the same problems get revisited every retrospective, the sessions either become rife with highly charged/emotional discussions or get bogged down in unactionable or questionable value problem areas ("We need more snack food in the room").

A big reason for these problems is that the teams don't receive any guidance or support in running their retrospectives.  Here are some tips on keeping your retrospectives working smoothly:

1. Establish a facilitator for your retrospective: This person should have experience and training in facilitation and understand how to maintain the right level of energy in a retrospective.  There is a wealth of information on effective facilitation techniques but a good book on the topic is Agile Retrospectives: Making Good Teams Great by Larsen/Darby and Schwaber.  You can review a Google Tech Talk presentation on YouTube.
2. Give your retrospectives 'themes':  After the initial excitement of the first few iterations most teams can benefit from having a focus area for their retrospective.  Topics like "How Can We Improve Our Teamwork" or "How Can We Increase Code Quality" help focus discussions and can break out of the 'We've discussed this before" syndrome that can accompany retrospectives.
3. Get participants engaged:  One key to re-energize your retrospectives is to get participants moving and participating.  Have team members write sticky notes with improvement suggestions and put them on whiteboards.  Have the team spend time moving the stickies into categories.  Use the Fist of Five to facilitate voting on these techniques.
4. Change things up:  If your retrospectives are losing their energy and benefits, try moving them to a different location.  Holding one outside on a nice day or have a Build a Sundae theme with some ice-cream and condiments can re-establish interest levels.

These are only a starting point for re-energizing your retrospective and there are lots of good blogs like David McLean's which offer advice and suggestions. I'd be interested in hearing how others are managing their retrospectives too.

Posted by Bryan Campbell at 02:18 PM | Permalink | TrackBacks (0)

Agile software development has existed in some form for almost ten years and while it's awareness and benefits are gaining greater market acceptance it's also becoming clear that Agile itself does not provide any better answers that the ideas that had proceeded it.  In fact, the time has come to start thinking of Post-Agilism and the next wave of ideas and approaches that will prepare and support software development into the future.

I presented a topic to the Houston Rational Users Group the other night on Scaling Agile.  As I prepared for the presentation and afterwards discussed with several colleagues our experience with agile and software development it became clear that a new movement in software development is starting to form.

For the last 20 years my career has involved software development (in fact if I include all of the software development I completed on my Apple II e/c in High School you could say I have close to 25 years of software development experience!).  The last 8 years has been focused on iterative development techniques and what is now widely described as Agile.  I came to my understanding of software development and IT in general steeped in a tradition of large process frameworks from the PMI/SEI and RUP.  I leanred and applied the Zachman Framework in my early Enterprise Architecture efforts and eagerly absorbed the V-Model as a mechanism to manage projects and their complexities.  As a project manager, these tools and techniques were invaluable in understanding how to manage the myriad of complex parts that comprise a large project.  My early experiences in project management involved introducing time-boxed, iterations and techniques like Domain Modeling and System Sequence Diagrams. 

In 2001 I had an opportunity to apply XP to a project and became familiar with terms like YAGNI - Ya Ain't Gonna Need It, Design Patterns, Unit Testing and paired programming.  Later I leveraged story cards to manage tasks and established Information Radiators to provide visibility, I saw the benefits of Test Driven Development and Continuous Integration.  I read about Scrum and leveraged Daily Stand-ups, introduced burn-down charts and began to leverage retrospectives with my projects.  About three years ago I started introducing Executable Requirements (Fit/Fitnesse) into projects and Feature Driven development,  All of these techniques were valuable and over the years I've been able to refine most of them through practical experience.

However, I applied all of these techniques within the context of a larger project management framework.  Classic PMP components like budget management, communication, and resourcing needed to come from somewhere,  Deployments required coordination with other projects and release windows.  Government standards like HIPPA or SOX had to be addressed while also ensuring that integration testing was coordinated with other systems and sometimes other organizations.  I learned early on that not receiving early involvement from Enterprise Architecture teams and Network Operations could delay a project more than not getting well defined requirements.  The Unified Process helped me manage risk across project phases and structure work across disciplines with roles and responsibilities.  The agile techniques I mentioned above seamlessly integrated into these broader models and the results were tangible.

This is the new face of Agile as I see it, an agile that embraces the value system of the Agile community but within the context and realities of getting something done in large enterprise organizations.  In the least few years though, I've come across a number of agile experts (or agilistas) who have 8 to 10 years of experience in agile techniques but little awareness (even at the broadest levels) of discplines outside of Design and Implementation.  I'm frequently surprised at the level of dogma that surrounds their interpretation of Agile and the lack of tolerance for anything outside of the realm of Design and Implementation.  Most have little appreciation for different roles on a project let alone artifacts or awareness of different stakeholder needs.  Increasingly agile is becoming a marketing term and it's being leveraged to justify poor work habits and an exclusively developer centric perspective on building software. 

I'm not alone in these observations and I've noticed others starting to write aobut Post-Agilism like Jonathan Kohl and Jason Gorman.  Philippe Krutchen recently wrote a very interesting piece called Voyage in the Agile Memeplex which discusses agile as a culture and the effects this has on software development and effective communication.

It's time to once again start looking at software development as an engineering discipline, one that requires a balanced perspective which leverages the experience of the past with the new ideas of the future.  Post-Agilism is already underway and it's time for the industry to begin adopting these ideas.

 

Posted by Bryan Campbell at 12:27 AM | Permalink | TrackBacks (0)