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.