Jan 062016

With the new year comes actual change, not just resolutions. Case in point: This is my inaugural post as the new practice director for Agile Product Management And Software Engineering Excellence here at Cutter. I’m excited and honored to take on the position, particularly at a moment when both Agile specifically, and software development generally, are going through some big, big changes.

Before we get into that topic, let’s talk about New Year’s traditions from around the world. Many of us are still settling into our work after the holiday break, so it may not be time for the thoughts to be too profound, or the wording too dense. Trust me, by way of metaphor, we’ll get back to the real topic.

Dishes1Many New Year’s traditions, not surprisingly, symbolize renewal. In Denmark, for example, people shatter their old plates and dishes. (We assume they have replacements.) In many South American countries, your first underwear selection is supposed to influence your fate for the coming year. Red, of course, is the color you choose if you want amor, or you want your amor to be more caliente. The Japanese believe that smiling at the beginning of the year increases your luck. Or perhaps, if you are a Japanese person traveling in South America, it will increase your chances of getting lucky, assuming the person at whom you’re smiling is wearing the right-colored underwear.

For many people, deciding to go Agile was a similar ritual of renewal. Without knowing exactly what the Agile future would bring, they wanted to influence it in the right direction. The change from Waterfall to Agile — or, to be honest, in most cases, the shift from not having any formal methodology to adopting Agile — is meant to be as clear a break from the past as the second the ball reaches its perigee in Times Square on December 31st. The old order ends, and we celebrate the beginning of a new order.

And then we discover that real change takes a lot of effort and commitment, much like the determination necessary to keep going to the gym after February or March. Some people have a harder time than others living up to their commitment. Sadly, in some cases, they give up. The chance to try again exists, happily, but we might need some encouragement to make the attempt. (If the metaphor isn’t obvious, I’m talking about the organizations, such as the heavily-regulated types, that face a tougher challenge with Agile. I’m also talking about the organizations, of which there are many, which fail at their initial Agile experiment, and then struggle to start again.)

Another period of time passes, and we realize that, as well as we’re doing, we can still do better. Fortunately, Agile is a foundational change that makes it easier to live up to next year’s commitments. We remove some of the silly obstacles to delivering software because we have improved the pace at which we build and prepare it for production. We can get more ambitious about delivering better experiences with customers because, with each sprint, the team learns a little more about the customer. We can start cleaning up technical debt because we can assess the impact that the debt has on our productivity, and we can build into our micro-plans the incremental steps needed to reduce that burden.

Just as a commitment to live a healthier life may make it possible for us to do the previously unthinkable someday, such as climbing a mountain, Agile makes it possible for us to do more than we have before. That’s why, as much as a mouthful as the title of our practice area might be (Agile Product Management And Software Engineering Excellence), it’s actually a very good way of describing the relationship between Agile and other software innovation concerns: because we decided to do Agile, we can address other concerns more effectively.

Not everyone is Agile, and that’s worth remembering. I often feel that the Agile community is a little too eager to celebrate, while many organizations still struggle to make the transition to Agile. (Not everyone needs to, but by now, the question should be, Why not do Agile? instead of, Why do Agile?) While we build on our success, doing amazing things like continuous delivery, Agile UX, and the like, we also need to understand how to help people get on the Agile regimen in the first place.LoonyDook1

I have the great privilege of working with some of the people with the greatest skill, experience, dedication, and sheer brain power on these questions. Take a look at the list of people in the Agile practice area, when you have a moment. Quite an exceptional cadre of experts for both helping people become Agile in the first place, and then build on their success to tackle other software innovation challenges.

The other New Year’s tradition I’ll mention, before closing, is from Scotland. Every year, people dive into the icy waters of the Firth Of Forth to raise money for charity, in what they call the Loony Dook. All the good Agilists I know, including the ones with whom I work, perform their version of the Loony Dook, gladly diving into frequently inhospitable circumstances for the best of motives.


Tom Grant

Tom Grant is the former Practice Director of Cutter Consortium's Agile Product Management & Software Engineering Excellence practice. His expertise lies in software development and delivery, with a particular focus on Agile, Lean, application lifecycle management (ALM), product management, serious games, collaboration, innovation, and requirements.


 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>