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.
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?”.
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.
I’ve often found that it’s much more effective to show clients what their problems are, rather than just telling them. Recently I’ve ended up using GraphViz as a great tool for high-lighting complexity that needs to be addressed.
At the client I’m currently working for the complexity of the build scripts was getting out of hand. I wanted to goad the customer into prioritising some simplification work. So I turned to GraphViz to depict how complex the build was. The build we’re using is a large, centralised, Ant script that builds about 10 different applications. It manages everything through the process of compile, test, package and deploy.
I found the handy ant2dot.xsl tool that uses XSL to transform an Ant build file into a DOT format graph representing the flow and dependencies between the various build targets.