More from Agile 2006

So far the conference has delivered on the expected level of information\content and discussion of the sessions. I have been attending sessions geared more toward project management and the aspects of different approaches as opposed to more developer specific topics. There’s a large variety of topics and focuses to choose from. The conference proper runs four and half days and has 30 different sessions\day, so it’s likely there is something for everyone. The sessions range from traditional speaker presentations, to workshops, to experience reports where agilists present things they’ve learned in their projects.
All in all, the general consensus of the people that I’ve talked to is that they all have found value with the conference. This is notable considering the varied backgrounds, markets and experiences represented.

Agile 2006 Initial Thoughts

I’ve always enjoyed those moments when you realize “Wow, why didn’t I do this sooner?!” These moments are usually accompanied by the feeling that you’ve found something that will help you to do things a lot easier or more effectively in the future. This was my initial reaction to my attending Agile 2006 in

Minneapolis.

The conference is well attended (a little over 1100 at current count.) The attendees, based on the limited sampling of my conversations, come from all backgrounds and organizations. Developers, managers, owners and testers are represented. As a case in point, at lunch I sat between an instructor from a university in Haifa, Israel that uses an agile approach in teaching and a manager for an organization in Orlando that helps document living languages that a currently not documented; projects with about a 35 year life cycle.

If you are a student of the game, and always looking at ways to get better at what you do, then I highly recommend attending these events on at least a semi-regular basis. It’s hard to tell what will happen when the conference attendance grows to thousands (in about two years based on past growth.) I doubt it will be the intimate gathering that some current attendees describe when talking about previous conferences. But it is agile, it will scale and it will adapt.

It’s cool when a client inherently understands an agile practice and uses it in ways you hadn’t thought of.

Visionpace is working with a client that I was previously employed with a couple of years back. They need some clarity on the size of their project and want to make sure that their developers are focused as much as possible on the new development, and minimizing changes to the current application.

Since their environment was already quasi-agile, it was pretty straightforward for them to understand the benefits of putting enough process in place to help achieve the goals they wanted while not taking away from the communication and model storming that had always worked well for them. We conducted a user story session and had a Visionpace resource lead a beachhead iteration, and then walked them through the iteration planning and user story tasking. Once we tasked out the user stories we discussed the layout of the task board and how the tasks progress across the board during the iteration. The agreed that creating the board was something that they could do and I told them I’d stop back later in the week to check in.

This company’s war room is located in an office that was converted to a conference room. They have a large table, some comfortable chairs and even a video gamming system for stress relief. The war room also has a large window that looks out into the main office and developer cubicles. This detail is important for two reasons. By making this conference room the war room, the importance of the work at hand and the overall health of the project was easily visible to everyone in the office, and it overshadowed the niceties of things like the video gaming system.

This window also provided another benefit for the project. One of the principles of the company directed that the window be used for the iteration task board. So the columns for the task board were written on the glass. His logic was that he really didn’t need to know what the tasks were related to a user story. What really matters to him is are the tasks being implemented on a regular basis, and is the iteration on track. By putting the tasks on the window using sticky notes, he could look at the window and see where the groupings were at any pointing the iteration (e.g. mostly in the backlog a the beginning of the iteration, spread out midway through, and in the tested column towards the end of the iteration.) 

I thought it was a brilliant idea: Easy to do, easy to understand, easy to implement and effective.

Game Software Development Becomes Agile

Here's an interesting look at the Agile Process in the context of game software design and development. Rory McGuire explores some of the difference between the "traditional" Waterfall method and the Scrum method of building software. He goes into some depth in terms of the advantages of Agile vs Waterfall and how it is or may become a strategic advantage for those game companies who exploit its benefits. Read it  here: http://www.gamasutra.com/features/20060628/mcguire_01.shtml