Agility; is it a culture, a mindset, or a set practices? In one form or another, this is the question that many are attempting to answer in order to realize Agile's promise. Agility is of course all three, but the one to focus on is mindset. Changing culture sounds to foreboding to seriously consider pursuing, and focusing on practices alone misses the point. Agility is a way of thinking; a way of taking a fresh approach to persistent issues. To realize the promise of agility, we need to start shifting our mindsets about how we engage and lead teams. Here are three key mind shifts to help us started.
From Constraining Change to Embracing Change
The traditional mindset is that change is bad, even feared. It is a sign that we are out of control. The traditional mindset is to work in ways that constrain change, control scope, and ruthlessly focus on staying the course. How has that worked out? A quick look at Jim Collins' 11 Good to Great companies shows us that three, Philip Morris, Gillette and Circuit City, are now gone. A fourth, Fannie Mae, is now government owned. More examples abound. How has Kodak, Polaroid, or Blockbuster fared over the last 10 years?
With agile techniques well established in the software development domain, there is a growing discussion on how to bring the those techniques to other problem domains. "What types of projects are suitable for agile?" is a common question that many agile proponents, including myself (Not Suitable for Agile?), are attempting to answer.
With agile principles and values becoming more widely accepted at the team level, a natural conversation heard in the agile community today is how to move beyond that. How do we grow agile organizations and agile enterprises? What does an agile organization actually look like? Not surprisingly, the answers remain elusive. Agile teams vary greatly in makeup and practice, all the while respecting a common set of principles and values. We should expect the same for agile organizations so rather than looking for a precise definition we should observe some common characteristics.
Ricardo Semler's Seven Day Weekend paints a great example without ever using the word agile. He describes his company Semco as a democratic organization where employees at all levels are engaged in all aspects of the business. From deciding their own jobs and salaries, to deciding what work to do, to deciding to open or close plants, to actively participating in board meetings. All information is made available to all employees and they are implicitly trusted to deal with it appropriately.
Hindsight is said to be 20-20, but is it really? Isn't there a bias to hindsight? Psychologists tell us that using our hindsight we all tend to see events that have occurred as more predictable than they really were. So when we want our agile teams to reflect on the past, just employing the teams' collective hindsight is not what we want.
In an agile world, retrospectives are about an open and honest examination of the past in order to shape the future. We want to understand past events both good and bad, and also how our emotions influenced those events. It is a learning experience. It is learning from experience. How can the team get better, accomplish more, collaborate more closely, solve issues more quickly, and deliver business value sooner? This is the art of retrospection.
I've finally been taking the opportunity to try out the Pomodoro Technique that Tony Akins so ably explained to Agile Leaderhsip Network Houston in March. I suppose the fact that it took three months for me to do this should have been my first warning sign. What I've found has been both enlightening and disheartening, and it has pointed out pretty clearly just how un-focused I can be with my own time when I don't have the obligation of meeting a client's needs and expectations.
Also published in the February 2010 edition of the PMI Houston newsletter Project Landscape.
Agile adoptions often generate this question from senior management and without a good answer, the adoption of agile practices and values on an organizational level will never happen. What makes the answer hard is that many benefits of agile are less tangible than many senior managers are comfortable with. So just why should senior managements care about agility?
As agility becomes more widely practiced, more people and organizations are giving it a serious look and we are seeing more of what Geoffrey Moore (Crossing the Chasm) would call the Early Majority starting down the agile adoption path. It is important that this new group of adopters has the right aim in mind.
Agility in of itself is not the goal. I may want to be more physically fit, but setting that as a goal is not likely to make it so. Setting a goal to ride 50 or 100 miles in the upcoming charity bike ride event is more likely to be achieved. An agile adoption needs to start with some set of improvement goals. Want to improve the alignment between your business and technology groups? How about getting your products to market faster? Perhaps being more predictable in delivering your projects? Getting a better return for your projects? Maybe improving the morale of your teams and retaining your current employees longer? Launching an agile adoption to "become agile" is not likely to produce much in the way of desirable results. First we should set expectations. What are we trying to improve? What will we achieve by that improvement? How will we know we are making progress?
Page 2 of 2