Once, I was hired at a big company as a team lead with a mission to create an agile team from a group of twelve skilled people. It was hard to transform the group (80 percent of whom were consultants) into a self-organized agile team consisting of 80 percent company employees, some of them offshored. This setup was a major success for me and my agile mentors as we transformed from a bunch of developers to an agile team, but I wasn’t able to celebrate because I had a problem. I was pushing too much self-organization onto the team, and one year of low (but increasing) velocity combined with stepping too hard and often on my boss’s toes, was fatal for me. My boss had to repeatedly explain to the CIO why we did not show the expected results.

Today, this company utilizes agile processes and is doing fine, with whole teams offshored. It was my mistake to not adequately communicate the investment needed. What could I have done better in my agile implementation? If I could have a new try, I would have implemented the six steps to agility discussed below, and, as the results started showing, spread the word in the company to keep the company engaged.

1. Decide if Agile Is Right for Your Organization
First of all, I should have been more convinced that agile was the right thing for this particular company.The agile mentor is one tool for building up this knowledge if you are not sure or need facts or success stories to support your approach. The mentor can help you build confidence in your agile practices. Note that we differentiate the agile mentor from the agile coach. The coach is a part of the project who is initially 100 percent allocated to it in order to provide hands-on support. Over time, the coach reduces his allocation to zero when the processes get easier as the team gets better; ideally, the team members should become mentors. Agile consultants may have problems reducing their presence, but doing so shows they are true agile coaches.

The agile mentor, on the other hand, is the  person you can tell everything to and no one should care about him except you. The mentor builds up your confidence as an agile manager and helps you take small agile steps toward your self-organized team and your new role as an agile manager. You must be open to advice from your mentor, who has no stakes in your organization. I suggest you have her sign a non-disclosure agreement, because you will be telling her all of your business secrets.

Regarding my own predicament, I should have gotten an agile mentor early on in the project. I also should have tried harder to convince management that we needed to adopt agile and stood up for our low velocity at the board meetings. Now, a year later, my agile mentor told me we were way ahead of our competitors in agile adoption, but for me it was too late.

2. Get Managers’ Buy-in with Data
When I gained confidence, I should have knocked on my managers’ doors in an attempt to get their buy-in with facts and figures. The State of Agile Development Survey 2010 (VersionOne) states that the top two reasons for companies not fully adopting agile methods are: “management opposed to change” and “loss of management control.” This sums it up well, and we can only hope that as managers, we dare to be pioneers who see the benefits from being agile managers who build up the team over time. Your company must embrace the agile stuff as an investment in sustainable human capital, as well as have a long-term plan to address this opportunity.

As a manager in the middle of the organization, you must be responsible for this “company buy-in,” not the doer or the CIO. You can call it a “middle-and-out” approach instead of the traditional “top-down” approach. Make sure you knock gently on your managers’ doors. Start in January, so you have time for the implementation to take place before your upcoming Christmas bonus is set—it takes time to build an agile team. Beware of management’s problems with the agile implementation. We managers don’t want to commit to agile because we will lose power and, possibly, our Christmas bonuses if the transition to agile doesn’t go well.  Managers are the real agile bottlenecks in the organization. Our fear of agile causes us to believe that implementing it will be chaotic, and it can very well be if discipline is not applied. Do you dare put your bonus at stake?

3. Get an Excited Team; Get Rid of the Slackers
So, with my new confidence that we were doing the right thing and with my manager’s approval, I should have formed my newteam. My old team was still around, but were they ready for this agile stuff?  Most of the team members were excited about this, but a couple of them were not. Some of them did not see the point and were there only to work their eight hours.

Then, I discovered the biggest defect in agile: It is assumed that people, by default, are skilled, disciplined, and willing to self-organize. The real world isn’t so.  People with different skills, cultures, and social frameworks are assembled for a short time to produce a result, aka a project. Some people know that they will be working elsewhere in six months, so why should they bother doing anything other than what’s in the specification?

4. Empower Your Team into Self-organization by Example
With an engaged team, I would have gone to the next stage in the agile evolution, which involves taking small steps over time and pulling from the team instead of pushing my practices. Lead the team into self-organization by being an example. If you act like you want the team to act, you don’t have to put up ground rules. A crowd of people cannot transform to an agile team in six months, or even a year, if they don’t want to do so or they don’t have the tools for the transformation. The urge for self-organization must come from the team’s own desires, like the need to feel acceptance, the need to learn new things, and the need to work in a stable environment, not from a manager who has read a management book.

Do you dare to let go of the planning, budget, and documentation? You must do so, in part anyway, but take it slow—let the team earn your trust. Do not force the team to self-organize, offer book recommendations or take a sudden vacation for yourself. If they don’t get the message and prove it with a team-goal defined by them, perhaps you should reconsider this agile stuff, do some coaching, or in the worst case scenario, get a new team. Next Christmas, you will be rewarded for your courage to build a true agile team when the ROI tells it all and you are improving business instead of micromanaging. (Note that I don’t equate rewards with money here; rewards should be fulfilling your intrinsic desires such as competence, autonomy, and relatedness [Deci, Ryan 2004]).

5. Apply Discipline if not in Place Already
We were now a self-organized team, but self-organization itself is not enough to say we were an agile team. It can very well be chaos if we let go of our control. We need to apply discipline as a counterweight. Discipline is a negative word I hate to use, but in this concept, it stands for following the teams’ statutes: To be on time, live up to promises, and follow the checklist we have for our process. Imagine being on an airplane waiting for the pilot to tell us that boarding is completed. When the pilot comes running up the stairs wearing jeans, stubble, and an iPod, you think about disembarking, right? When we define discipline in the project, we can start building up trust that promotes the power that later can be transformed.  We need competence.

The formula Competence = skill * discipline was first stated in the book Management 3.0 by Jürgen Appelo, and it sums it up well. No matter how good the pilot is, if he doesn’t have discipline and do his checklist in a timely manner, his competence will be zero.

With Mr Appelo’s competence formula in mind, I want to extend it into my law for how and why to set up an agile team:

How I apply Jürgens rule to make it an agile team::

agile team = competence * 5 to 7(my ideal team consist of five to seven members) + time (invest in time for the team to organize)

And then I apply it to the workflow that tells us why we should do it:

agile team > trust > empowerment > effectiveness > ROI++(where > means enables)

6. Spread the Word to Keep the Company Engaged
Even though I finally had my agile team producing good ROI, I should have initiated my agile crusade in the organization outside the IT department in order to get the real value from agile, as the whole company works in the same fashion. Marketing, HR, and accounting  are also deeply affected by an agile implementation, and they must be a part of what is happening to IT; otherwise, it will only be an IT-related initiative. Agile’s real boost comes when everyone has the same culture. In this sense, agile is not a development practice, but rather a business process. I recommend small implementation steps, but, in some cases, an out-of-the-box implementation can be more effective.

Why don’t all of us managers start having a weekly session where the topic is process improvement? Developers call it a retrospective, but do not try to copy development best practices—make your own. The first session’s topic can be “How do we speed up lead time from an idea to a result.” The HR guy perhaps says we should hire more people. The IT guy says we should buy better tools. The accounting guy says that we should first show green figures and then act. The marketing lady wants to have everyone in the company participating in her ideas on new campaigns and you, as a wanna-be-agile-manager, claim that we should be more…agile. It takes courage, but you can do this agile journey if you just take your time understanding why it should be done and you can argue for it. Once you do so, the process starts. There is no right or wrong way to implement agile, as long as you reflect and improve your processes.  If you feel that agile and your organization are not a fit for each other, you at least have tried, and when some agile guru knocks at your door you will know what you are talking about.

In Retrospect
So, in retrospect, I should have done things the other way around. Despite the empirical evidence in the VersionOne survey that shows that agile software projects are successful and result in higher ROI than traditional projects, it is very hard to implement agile in an organization with only a top-down approach. You need total buy-in from the organization and a competent team. This can’t be accomplished in six months, so we need early buy-in from the shareholders on the agile investment.

A final piece of advice from me as a manager to you as a manager: Do not try agile if you can’t take the heat and the investment. Go with the second best—just copy others. Stay floating with your nose over the surface, but do not swim. Make your competitors take the risks, and learn from their mistakes. But if you are just a little bit curious, I recommend you order new business cards without a title and go and sit with the team.