The CEO of a financial services company had blocked off a day to take his management team offsite for a dedicated session focused on using agile to run the organization. After devoting the first half of the day to understanding agile practices and principles, the balance of the day focused on taking the specific initiatives and goals of this financial services company and translating them into tangible stories. These stories could be used to populate the company’s new Kanban board, one of the tools they would use to begin applying what they learned.
The second half of the day, however, was not as smooth and obvious as the CEO expected. He communicated his top three goals for the year confidently. The consultant running the session then recommended that the goals be adapted to user stories in an effort to teach the CEO and his team how to use this agile practice and develop a more specific definition around each goal.
The instruction was simple; a user story template was explained, an example was given and then the group discussed that the final task would be to assign a value currency and effort estimation to the story when it was complete. Everyone seemed positive and prepared to get this done. About 45 minutes into the first story, there was disagreement and confusion about how to define the goal and the acceptance criteria so that the team would accept that the goal had been accomplished.
If you are a current practitioner of agile, then this example may seem a bit extreme but it represents the majority of enterprise organizations across several industries. Agile is industry agnostic. As a methodology and as a change program, it is not influenced by the company’s main business. In most enterprise companies that have dabbled with agile, you’ll hear people say that “we are doing agile” or “we’ve done agile”. But how often do you hear a company tell you “we are being agile”?
The challenge we have with agile is the term itself. As with many terms and phrases, people typically hinge on the term/phrase itself and slowly separate themselves from the practices that make it up. Being agile implies more than change - it also implies disruptive change; the type of change that requires people to do things differently than they are used to.
Trends are positive in showing that agile practices are going well beyond the application development layer, where they have traditionally been used. Many organizations are now experiencing the same sets of practices across their entire organizational stack in IT and to some extent on the business side. In fact, consider that lean programs are reflective of the same sets of practices that you see in good agile programs. Therefore the link between the two is moving at a rapid pace in many enterprise companies that have seen the results that these efforts can bring.
Agile across the enterprise is a topic that has been written about during the last few years but has only recently begun to produce success stories to support it. Within the topic of agile in the enterprise is the emphasis on organizational change.
To get to the state of being agile requires a number of considerations. The two primary considerations are cultural change management and training agile teams.
When we consider introducing agile into the organization, we are speaking about a program level effort vs. a project. This means that it involves people across the organization and not just in an IT team. It infers that management teams at all levels will support the program, use the practices and lead by example.
The most successful agile projects are not the ones where process was followed to the letter, although that is important. They are the projects where the passion and commitment of the people involved exceeded the status quo, the traditional way of thinking and working. The best agile projects always involve people who are willing to disrupt the norm and overcome the barriers that change represents in the minds of many. It is more a mind-shift rather than a set of processes to follow.
Cultural Change Management