The following article, written by myself and my colleague, Matt Simons, was published in the December 2010 issue of the Cutter IT Journal and is re-produced here with kind permission. It was also the subject of a talk we delivered in Santa Clara.
The landscape is changing
Since the dawn of the software era, systems have generally followed a lifecycle of develop/operate/replace. For the type of systems our company, ThoughtWorks, specializes in (typically built over the past 10-15 years), organizations expect as much as 5-10 years between significant investments in modernization. And some of the oldest core systems have now reached 40+ years – far longer than the average life-span of most companies today!
IT assets are relatively long-lived largely because modernization often represents a significant investment that doesn’t deliver new business value in a form that is very visible to managers or customers. Therefore organizations put off that investment until the case for change becomes overwhelming. Instead, they extend and modify their increasingly creaky platforms by adding features and making updates to (more or less) meet business needs.
For decades, this tension between investing in modernization versus making incremental enhancements has played out across technology-enabled businesses. Every year some companies take the plunge and modernize a core system or two, while others opt to put yet another layer of lipstick on the pig.
Continue reading “Dealing with creaky legacy platforms”
I was reminded today of a presentation I’d put together to help project managers who are new to Agile understand how to use the ubiquitous “burn-up” or “burn-down” chart. Since some people seemed to like it I thought I’d share it with a wider audience.
Adopting a new development methodology is less about process change and more about attitude change. The binder is useful, but the mindset is vital.
Much of my work over the last few years has involved helping organizations “adopt” Agile. It is, after all, a poor, unloved orphan and needs to find a good home. The key to whether the new approach sticks doesn’t seem to be affected by how many checklists, process maps or charts of roles and responsibilities we provide; what matters is whether an organization can adjust their collective and individual attitudes.
There’s a great quote from the 14th Dalai Lama that says:
“If you don’t like what’s happening in your life, change your mind.”
Beyond the double meaning of “if you don’t like it, decide to like it” is the more important idea that to change your behaviors you need to change your thoughts.
Continue reading “Change your attitude and the process will follow”
I always struggled to see how what Lean teaches us about pull systems can be applied to software development processes. That was until I had an “Aha!” moment a little while ago helping a client apply lean and agile principles to their delivery process.
The big fat lie
I understand how queuing theory can help identify and reduce bottlenecks in processes and have used finger-charts and kanban-boards to do this for a while, but I still find calling this a “pull system” to be slightly disingenuous. All that’s happening is that more “stuff” is being pushed based on a trigger when certain buckets get too low. This reminds me of my annoyance with early technologies on the web that were touted as being “push” but were really just “repetitive-pull” (but not in a good way). I’ve never seen a software organization where the developers have said to the business or product people “we’ve got nothing to do, can you think up some new projects or features for us please?”.
Continue reading “Don’t push requirements – pull information”
Have you ever noticed how teams who are new to Agile often struggle if they attempt to adopt just one or two of the XP practices? And have you noticed how the solution is often to introduce more practices?
I had been developing a theory about the interdependence of various software development practices when I got the chance to work through some of these ideas in a session I facilitated with some fellow ThoughtWorks colleagues. We uncovered some interesting connections and an important positive feedback loop that is worth being aware of when trying to help teams adopt Agile. The session happened at least a year ago, but I’ve only just been prodded into posting the output.
My most recent project was helping a major online retailer to mature their build process as part of a wider effort to improve their IT effectiveness through the injection of development best practices.
When we came onboard manual intervention was needed for any of their builds or deployments to work and so it was rare for more than a couple of builds or deployments to be completed successfully in a day. Now we often have up to 1,000 builds running every day – what’s more the majority of them now pass!
This article looks at a few of the techniques we’ve had to put in place to enable this transformation and what we’ve learnt along the way.
Continue reading “Build Transformation across an Organization”
I’ve been looking at the Getting Things Done process for organizing all your tasks and projects for a little while now. Though I’ve only just bothered to pick up the book, rather than just guessing what’s in it via hints from other websites.
I’ve been trying to apply some of the principles to how I deal with work emails and have come up with a technique that’s been working pretty well since January, so I thought I’d share it.
A posting on Getting Things Done with Gmail started me off thinking about this. At the client I’m working for at the moment they use Outlook (I’ve used it for many years and am intimately familiar with the good and bad in it) so I’ve had to work with the tool in hand. I much prefer working with gmail, or before that the Opera mail client, which was probably the best I’ve used, since they have a simpler ability to tag / label mails in multiple ways, but if you combine a few tricks in Outlook you can get to a reasonable solution.
Continue reading “GTD with Outlook”