This week I wrote a useful utility and taught some Python to a peer, attended a really great work session and a rough estimating session. I did some WIP management activities with my team, I broke the application, I worked with some awesome partners, went on a bit of a refactoring binge, devised (with partner) a grand strategy, and got stuck on tiny little problems I couldn't see over. This has been an awesome week.
We have been doing some big refactorings, moving big and critical chunks from one module to another, and dealing with the fallout. I don't know how to tell you how important the tests in our code base have been. I would have spent all day lost without them. We would move a component, build, resolve build troubles, rinse and repeat. Finally, at end of day, I got all unit tests and fitnesse tests turning green, EXCEPT for a few that won't test because they do horrible things and need remediation. When our tests failed, it was not because the tests were bad (exception, one was pretty iffy) but because something was wrong. The compiler and tests made our work less scary and troubling. It was still scary and troubling, but would have been overwhelming otherwise.
I and some of my colleagues transitioned this team to Agile only 2 years ago. It is amazing how deeply some of the team members grok Agile now, and a little frustrating how some people and some circumstances have not really come up to the same level. Frustration is not failure, though. There is light bursting through here and there.
I've also been checking in as a coach, testing the prevailing winds, looking for the problems that keep us down, looking for the ways to improve our work system, looking for moods issues. We're in a pretty good place, actually, by numeric measures. Some parts of the code base are very well-tested and quite simple, and others are becoming so. There is still some amount of legacy code produced every day, though, and that is a bit disheartening to those who really want to see only improvement (I'll cop to being one of them).
Our biggest challenge is that there is some big work coming to some ticklish areas of the code, and we'll be under pressure to deliver. This is our first real chance to test our Agile mettle against a really formidable foe.
Jeff and I just released the "Why Agile" card at AgileInAFlash. Two years into the transition, I want to make some comparisons on how we rate today v the original situation.
Improve Customer Involvement has improved the least. We have a great guy playing the role of Customer, but largely the representatives for the customer don't join the team. Some of them have found more engaging ways to provide specs (screenshots, videos, etc), and have made themselves more available for discussion. It is still not what it could be. With one notable exception, our Customer players are all surrogates. All but one of the surrogates live on the other side of the building, across a hallway from the developers, and are not really involved in daily work. This is actually a problem that affects morale and development performance. Finding a way to bring us all together would bring profound changes to the product, I have no doubt.
Increase Quality has come a long, long way. Like any SAAS player we always want better performance, and like any SMB growing larger we have a few issues from time to time, but overall quality is way up and the testing practices are better all the time. When I ask product management or sales or support, they tell me that it is a whole different world from the product of 2008. We haven't reached the "everybody loves us" stage yet, but we have come a long way.
Simplify Releases is happening. They used to have nightmares about release nights, and now they're more like annoyances. We still have code freeze and pre-release ceremonies, but we're not 100% covered in tests yet, and we put a lot of features in each month. We will continue to need some regression testing and some exploratory testing for a while yet. Issues that made code hard to deploy keep getting eliminated. It's a new world compared to our starting position.
Increase Operational Awareness this one hasn't come so far. We don't have the information radiators I would like to see, but the card wall is being used, and people tend to have a pretty good sense of what is in progress, finished, or unstarted. The big priorities are posted on pillars and doors so we can see them. Stand-up meetings help us keep track of each other. It could be better, but it is a good start. Actually, the operations staff have herereally smoked us in this regard. We know more about servers and their problems than ever before. We have moving graphs and charts updating constantly on large-screen displays in the office. There are alerts in email, and people stopping by the developer pairing stations. They're doing a tremendous job.
Drive Down Risk could be better. We tend to fall back to producing whole big features, rather than staying incremental as we should. I know, breaking down stories into valuable verticals is tough business, but all-or-nothing leaves a strong chance of "nothing." Our demos do collect feedback, and often are valuable working sessions (ours was this week). Testing and pairing also help reduce developer myopia and its resulting code diseases. But still, we're not incremental as we should be, and that leaves us at risk more often than I'd like.
Reconnect With Geek Joy is there, but we still wrestle with this. Sometimes we don't feel better, even though we are better. A times wrestling with legacy code (even new legacy code) frustrates us. Sometimes we don't have the level of success we might like. Yet I am so encouraged when we can do big things under sufficient tests, and when we find people making far-ranging improvements, when we have consensus on big design changes, and when we demonstrate working code. There is energy around performance and quality. We enjoy solving problems, and we enjoy cleaning code, and we take pride in not leaving silly duplication behind. I enjoy this job, and am happy to be doing it. We are making a difference to each other and serving customers as better than we could before. This job improves me, and that's joyful.
I know, my readers may want to hear how I totally transformed the company and how all of our problems vanished in 6 weeks or less, but that's not always how it goes. Real change takes time, and not everyone "gets it" all at the same time. New hires, old cliques, old barriers, old policies, old politics, new features, new customers, and new technology keep things challenging. Pressure to release pushes people back into old bad habits. There is a swirling cloud of chaos, but it keeps moving in a desirable direction overall.
Maybe we're still struggling a bit, but that's what growth is like. Watch this space. Maybe next year I'll show you how much further we've come.