Going Agile

Monday, December 18, 2006

Depth of Penetration

The last nine months have been interesting for me. Upon reflecting, I was able to, without authority or mandate, convert a chaotic and stuck development group into a functioning Agile team, push adoption into other development groups, and witness those changes become entrenched in the organization. The success has been self-evident to the point where the head of dev now runs every project as a Scrum project - even the small 1-2 person projects.

I realized how entrenched Scrum has become when I was perusing the white boards after a cross-management strategy meeting. What I also realized is how boxed in it has become. It is no longer an insurgent movement spreading thru stealth and success. It is a known commodity. The down side is that people's view of this has been formed. And it is viewed solely as a development process. As much as this was initially and at it's heart a development process, it is also meant to scale across the entire organization - from product definition and business analysis to deployment and operations (well, perhaps not all the way to operations). Now that people have that opinion formed where Scrum fits only into dev, it will be more difficult to penetrate deeper into the organization.

I definitely need an outside proselytizer to teach and explain organizational Scrum. I also need a position where I can be heard by upper management across groups or a proxy mouthpiece to function in that capacity for me. Until then Scrum is stuck at the walls of dev with limited penetration into the test/QA group via a handful of sympathizers. Mostly because what they're currently doing is onerous, poorly functional, and doesn't deliver timely results.

Monday, December 04, 2006

Playing nice with others

You may have noticed, but I don't always like to play nice with others. Not that I'm a "My way or the Highway" type, I just have a lot of faith in my experiences and techniques. That and other people are generally stupid, but I digress.

The reality is that working with others is a job requirement, and often the most difficult part of the job. Working alone, while efficient, is not an option. I've had to spend the better part of the last two weeks working with the new test lead assigned to our project to bring all our work items in compliance with the theoretical work request process that the process gestapo has been wasting tons of money and time on working hard to implement. While this process has been in development for almost a year and continues to fail at providing anything useful, he (our tester) is being forced to work with it, so I need to be a good citizen and help him do his job. This is part of trying to build my consensus team and redirect what they're asking for into something more like what I require.

For a while I was trying to get everyone on the other side to start working within our tool (ExtremePlanner) since it satisfied all their purported requirements and alleviated the need for arduous status meetings. They unfortunately were unwilling because the request didn't come from on high. Also, I have to acknowledge that I failed to move quickly enough in pushing Agile deep into the organization. We now have yet another layer of project management bureaucracy being added which will require new navigation techniques. In my defense, I lacked the official capacity to effect change, so it has been an uphill battle. For future endeavors I plan on negotiating for more formal acknowledgment of this capacity and/or work to completely absorb as much of the testing/quality and product ownership groups into a tighter partnership with development. Having group separation leads to fiefdoms and infighting and makes drastic transition (which is what moving to Agility is) incredibly difficult. Too many interests seek to maintain the status quo of failed policies to allow broad, quick adoption. That or I need to identify an Agile champion to work with in these other teams.