In the Collaborative Lifecycle Management (CLM) project we have declared three imperatives for improvement in order to increase our agility with a goal of continuous delivery: culture, process, and tools. Of these three things, culture is, in my opinion, the most difficult thing to change because it’s less tangible than processes and tools and because culture is often deeply ingrained in an organization and a team. Consequently, cultural changes can take a long time to implement. This is the first in a series of posts where I’ll discuss some of the important cultural issues and changes that we’ve tackled in the CLM project.
Modern business is chaos
Do you ever feel like you’re working in a world of total chaos? I am often reminded of a headline that jumped out at me from the cover of the January 2012 issue of Fast Company magazine in which they declared that “Modern Business is Pure Chaos.” I like to think of the chaos as change, complexity and confusion in various parts but change is one factor that no one can deny. The world does seem to have become more complex and more confusing but the adage that “the only constant is change” has been around for a very long time.
The agile movement in software development is a response to dealing with change. The complete headline from Fast Company declared that “Modern Business is Pure Chaos. But Those Who Adapt Will Succeed.” You can see the cover here. In the agile way of doing things we adapt by decomposing big tasks into smaller tasks, doing bits at a time and then repeating or iterating. So instead of PLAN-DESIGN-DEVELOP-TEST-DEPLOY, we plan-design-develop-test-deploy-plan-design-develop-test-deploy, and so forth. Every time we repeat the cycle we must make adjustments. The key to making those adjustments is retrospectives.
A retrospective is where you look back and ask “What went well?” and “What didn’t go well?” and then try to figure out a concrete set of improvements you can make to help things go better next time. Ideally you do retrospectives regularly. Perhaps at the end of every sprint or every release.
It scares the heck out of me when I hear of a team that is not doing retrospectives. How important are retrospectives? Let me put it plainly in a way that might hopefully suggest that if you don’t do retrospectives that you really should be: If you don’t do retrospectives it suggests that you’re perfect. Things are so good that you don’t need to improve. Either that or you live in a world where there is not much change and you don’t need to adapt.
Tracking continuous improvement
In the CLM project we have a lot of people and a lot of teams so we do our retrospectives at many levels. Small teams, including component teams, and the feature teams and run teams we’ve been writing about recently, do their own retrospectives and then the results from these bubble up to retrospectives in each application/product. What’s most important is that anyone and everyone should have the opportunity to voice their opinion and especially to raise problems. We capture each retrospective in a retrospective work item such as this one that captures the CLM 4.0.4 retrospective. In a recent change we’ve been documenting specific issues as pain points like this one that came out of the 4.0.4 cycle. Each pain point is then broken down into specific improvement actions that are intended to reduce or eliminate the pain. We use custom work item types to track each of these different aspects of our continuous improvement effort and this allows us to document and monitor specific data points. For example, we’ve started to measure our confidence for addressing each pain point.
It’s all about perspective
If you’re moving forward then you need to be looking ahead but you also need to occasionally take a quick glance behind and see where you’ve come from so you can learn from each and every effort. It’s one of the most critically important things you can do.Adrian Cho
Program Director, Continuous Delivery Evangelist, Author of The Jazz Process: Collaboration, Innovation, and Agility