Don't just do agile. Be agile.
AdrianCho 110000D4JA Comments (2) Visits (6847)
If you're thinking about embarking on the journey of agile transformation you should be clear about why you want to become agile. The goal of being agile is to handle change. How would you handle change which, by the way, is often of the unexpected variety? At the very least you would not fall apart and stop operating. However it would be more desirable that you capitalize on it. As jazz trumpeter, Miles Davis, said, "There are no mistakes in jazz--only opportunities."
If you're working in an environment in which everything is routine, every project is like the last one, there are no surprises and everything is predictable then you don't really need to be agile. As it turns out that is not the reality for most businesses today. On a recent cover of the magazine, Fast Company, they proclaimed “Modern Business is Pure Chaos.” If there is one constant in today’s world, it is change. Military conflicts, the global financial crisis, and emerging economies are just some of the products of a volatile environment characterized by aberrational events, sudden shifts, and rapid emergence. You must be agile in order to survive and thrive in such chaos.
With this realization, many people, teams and organizations are on the path towards becoming agile. Yet many of them will go through the motions of changing without ever fully realizing the promised benefits of agility. J.D. Hildebrand calls these people “agile slaves.” These are the people who have adopted all the trappings of the agile movement. They use agile tools, follow agile processes, study agile education and perhaps they even have agile certifications and titles. Yet they are still not agile.
While agile tools and agile processes can make a big difference, they are completely useless without agile people. Agile people constantly think about being agile. Their individual actions are performed with agility and they enable their team to act with agility. When everyone in an organization can perform in this way you can have an agile organization.
Let me share two prerequisites to agile culture. Firstly you must be highly aware. As an individual you are aware of your own actions. If you write code then you constantly check your code to ensure it does everything it should and doesn't do anything it shouldn't. Usually that means testing. You don't throw it over the wall to someone else to test. You test it yourself. Since you'll probably be testing that code a lot you'll want to write tests that can be run repeatedly. The individual awareness required by a great software developer is not unlike the that possessed by a great musician. When a trumpeter produces a single a note she is constantly listening and making minute corrections to ensure the note is in tune and sounding just like she wants it to. Individual awareness is required to attain virtuosity in any discipline.
However a group of virtuosi must work together to realize the benefits of their collective talents. If you work in a team you must possess team awareness so that you are highly aware of what your team members are doing. You must know what they are doing and what the team as a whole is doing and you must understand how your contributions affect the team’s results. In music the combined result is the sound of the ensemble. As the great jazz pianist Oscar Peterson said, “It’s the group sound that’s important, even when you’re playing a solo.” In software the group sound is the build that integrates everyone’s contributions. Bad things happen when software developers do their own thing without regard for others. There may be build-time errors, run-time errors, integration defects, poor performance, or a host of other problems that can result from a lack of team awareness. Remember that the goal of being agile is to react to change. Change can come from within a team. If someone changes an interface, removes an entire package or implements a complex feature that will require guidance for users, others must react appropriately.
Of course awareness is only half of the equation. In a jazz band, one musician can listen intently but if his fellow musicians fail to communicate effectively, there may be problems or at the very least, missed opportunities to innovate. In a software development team people must communicate effectively. They must act authentically, openly, clearly and communicate in a timely manner so that their colleagues can quickly and easily react to changes from within the team. On the projects I work on at jazz.net, we have worked toward this goal by doing all our software development work in the open. All our defects, enhancement requests, plans and builds are published on our site and anyone can provide feedback and interact directly with the development team.
Finally, there is the awareness of what happens outside of the team. Just like musicians who are constantly aware of their audience and how they are reacting to the band’s performance, a software development team must constantly solicit and react to feedback from stakeholders and customers. If there are competitors they must keep tabs on them. Teams must be aware of what’s happening in their organization, in the market and must generally look out for change that originates from outside the team.
This individual, team and situational awareness must be ever-present. People can’t just have heads down or buried in the sand. It’s not enough to just “do work.” When change is constantly occurring within a team and around a team everyone must be ready to react. Celebrated jazz pianist, composer and bandleader, Duke Ellington, said, “The most important thing I look for in a musician is whether he knows how to listen.” If one jazz musician remarks that another jazz musician has “big ears,” it’s a compliment that means the person is constantly aware and ready to respond to change. Those are the people you want in your team.
A second prerequisite to being agile is to be willing to change. That’s right. In order to handle change you must be willing to change. This means you must be continuously improving. That begins with the notion that what you’re doing now may not be the best method. Taiichi Ohno, originator of the Toyota Production System, wrote: “There is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it’s all over.” Many companies have a term for such standard work: “best practice.” Best practices are usually defined when they are found to be effective in a particular circumstance. The danger is that some will assume that these practices should be applied equally in all circumstances. Yet if change is a constant every situation may be different. Most activities are sufficiently complex that there are many constantly changing factors. Not only must any set of best practices be applied uniquely to each activity but their effect must be monitored over time. To do otherwise may lead to degrading performance as circumstances change and people fail to respond appropriately while taking false comfort in practices that might have been the best choice at one time but now require re-consideration.
To improve you must consider how are you doing. That awareness I mentioned before is the beginning of a cycle in which you capture data. You then analyze it and produce useful information that is the basis for making decisions and you then adjust accordingly before acting again. This is precisely the continuous cycle of execution that would be employed by the trumpeter I mentioned previously. In a software team one of the most important ways in which improvement occurs is through team-wide retrospectives. Ideally this happens at the conclusion of a sprint or iteration. At the very least it happens at the end of a development cycle. Teams ask themselves three simple questions: “what went well, what didn’t go well and what concrete actions can we take to improve?” Open and frank discussions are paramount to realizing the benefits of this process. If you never do this you’re basically saying you’re perfect. In that case I wish you good luck.
Becoming agile is hard. For many people, teams and organizations it involves a major cultural change. Tools and processes and the other agile accoutrements can help you be more agile but first you must adopt a culture of agility throughout your team and ideally throughout your entire organization.