Agile Primer Series

Where do I start?

In my last post, I discussed some of the frustrations and problems software engineers encounter when dealing with organizations that are “going agile” as it has come to be known. We also discussed the heavy burden borne by leaders and management when supporting the plight for becoming an agile organization. As interesting as that is to talk about, the focus of this article is on the process from the perspective of the grass roots, or the worker’s point of view. Let’s jump right in.

Where do I start?

Perhaps an over-hyped topic, but one you can’t afford to dismiss is where to start when thinking about building momentum for the adoption of agile at your organization. Perhaps you’re in an older or larger organization, and a waterfall method of software development is prevalent. Or perhaps, like many of us, you find yourself in a workplace where leadership doesn’t quite understand the value of being agile, while they have allowed the adoption of some parts or pieces of more-or-less agile processes, like Scrum or Kanban. Maybe your organization has no formal software development processes, and yet feels like it has too much process, and therefore progress is continually elusive.

Whatever the case may be, getting started with agile from the grass roots is a challenging proposition, to be sure. Here are a few questions to ask yourself and others around you before you get too far into things:

1. Is there an existing process? If so, how subject to change is that process likely to be?
2. Are there specific goals that can be accomplished or problems that can be overcome with the adoption of an agile process?
3. How successful have previous “reforms” been, and how is change usually perceived in the organization overall?
4. Is there anyone in the organization with authority or pull who would support me?
5. Are there others in the organization with experience in agile practices or first-hand knowledge of an agile process?

There are many more questions, so feel free to think of some of your own (share them with us on Twitter).

The idea here is to engage your mind first in how big a job it will be to encourage organizational change and win hearts and minds to your cause. Additionally, you should begin to get a feel for how likely you are to be successful in this endeavor, and to find out what your limits are. If there are things you can’t do or overcome yourself, find someone to help you. Find many someones, in fact. The more you bring into the fold and win over, the more you can share the responsibility.

Conversely, if you have answered some of these questions and realized things are in a pretty bad state of affairs, and your likelihood of a successful outcome is very low, you may need to do some evaluating. And at least knowing this up front, if you decide not to pursue the effort any further, you have wasted nothing and hopefully have not become overly discouraged.

One final note: If the answers to some of these questions are particularly discouraging, you are very likely in the wrong place yourself. As sad as it may sound, the very best thing you can do for yourself in that situation is get out while you can. Companies that you know will never change, and that have no interest in improving, becoming more efficient, having happier and more loyal employees, and being among the most coveted places to work simply don’t deserve you. It’s important to recognize that some organizations cannot be fixed. If we allow ourselves to be deluded into thinking every workplace has great promise and potential for reforms and improvement, we can become very disillusioned. This has happened to me once or twice, and I don’t recommend it to anyone.

What are some first steps?

Once you’ve passed the analysis stage, and feel confident there’s some hope (good for you!), it’s time to get to work. Set some expectations for yourself up front. Know that this will be a very long and arduous process, and it will be easier to give up than to move forward. Hopefully, based on your analysis and asking some tough questions, you’ve gained a sense for the likelihood of your success. At this point, you should be diligent, and not give up easily.

As mentioned earlier, your first step should be finding allies. I can’t stress this enough. As I mentioned in last week’s post, Mitch Lacey’s book The Scrum Field Guide has some excellent tips. Read it. Right now, if you haven’t. But one tip is to find an ally among senior management, someone with pull or authority. I recommend someone who is not just a leader in title only, but someone who many in the organization respect and admire. It will be much easier to win others to your cause if you are supported by a true leader. You will need all the help you can get, and you will need to be seen as legitimately working for the company’s best interests. This is something only someone with influence can help you with. If no such person exists, you may need to go back to the analysis step, as you likely missed something.

Another thing to get you started is to begin the process of educating others. If you haven’t yet educated yourself, it should go without saying that you need to start there. But assuming you have a strong working knowledge of what being agile looks like, some prevalent processes that support this ideal, and how it works in general, you should begin disseminating this information to others. One of the big mistakes I’ve been a party to is not getting supporting members of the software development process on board and understanding what agile is, how to achieve it, why it matters, and what benefits there are in pursuing it. For example, one of the primary roles in the Scrum process is the product owner. Many organizations have this role, but few have the scrum version of it. Without the product owners understanding agile software development, it will be impossible for true agility to be achieved or many of the goals of an engineering organization for that matter. Start by educating these folks on agile, and make some allies in the process.

Building the movement

Once you have an ally or two, including one in upper management, you need to create some momentum for your cause. In my experience, the idea that an entire organization is going to adopt agile overnight is not feasible. Instead, start with a single team or a single project.

One example I can cite is in a previous company, the entire engineering organization adopted scrum as formally as they knew how. While some of the processes and practices were adopted (really only a few of the most prevalent ones), the organization failed to achieve any sort of agility. Sure, there were a few examples that almost seemed to achieve some higher level of success for a few months, but nothing really developed. Our problem? We attempted to adopt agile a) without understanding it, b) with the assumption we were unique so we needed to customize the process, and c) most importantly, all at once. This resulted in a fairly long running systemic failure to achieve agility, as the organization can’t adapt when they see no examples of success and have built no true understanding of how it needs to work.

As I mentioned, the alternative to this is to start with one team, or one project. In most organizations, projects seem to encompass more than a single team, so the project level seems to be the best place to do a trial deployment of agile.

Once you have a single focus among the team(s), the next thing to do is to unify into a single tactical unit. As I mentioned, it seems most projects end up encompassing multiple teams. But in order to execute with agility and efficiency, you have to unify. That means the combined project team must fall under the maximum recommended team size. Most studies and expert advisors would say the ideal team size is around 10 people on the higher end. If you combine two or three teams, you may end up with 12 or so people, and that may be fine, but any more than that and the project will suffer for it. In my experience, combined project teams end up being 20 to 30 people. This just will not work, and the project will actually move along slower because of it. So keep it under 12, ideally 10 people. And make sure those people understand they are to execute as a combined team, not individual teams or individual team members.

Demonstrating success

With the support of your ally in upper management, you should be able to get a trial run of agile established. Whatever actual process you adopt at this point should probably not be dogmatic or highly specific. Meaning if the project team wants to experiment with a process other than Scrum, such as Kanban, Lean or XP, let them. A team that is able to adapt based on the needs of the project is already learning to be agile, as process is the most fundamental proof of agility. But keep in mind, at no point in this trial run should you play fast and loose with the rules of the process you’ve chosen. Save that for later, when the team has mastered a process and demonstrated its effectiveness.

What should be happening as the project progress down this track is an increase in momentum, efficiency, and progress. Following the tenets of agile, and a solid team-based approach, you should be seeing dramatic improvement. Use something like sprint retrospectives to analyze this aspect of team performance. If improvement and increased speed are not being achieved, the team is likely road-blocked. Utilizing your ally in upper management is essential here. Road-blocks and impediments must be eliminated with prejudice in order to achieve a truly successful outcome. Finishing the project more or less on time is not success. Demonstrating to the rest of the organization that being agile provided a framework for an on-time under-budget project that exceeded customer expectations is the goal. If there are still people in the company that observed (e.g. were clued in before hand) this process and still aren’t believers, you may not have a successful outcome. You can always try again at this point. Though going back to the education step may be helpful here as well. But assuming people are watching and see the gains demonstrated in the project, the organization should be shifting its collective mindset, and a more wholesale adoption of agile can begin.

Wholesale adoption

Even at this stage, taking it slow should be of utmost importance. This is not the point where all 27 other teams in the organization jump on the bandwagon and attempt to adopt agile. Instead, focus on replication of the success demonstrated in the first process. Choose two teammates or sub-teams (that formed the larger project team) and move them onto separate projects combined with other teams, to form new project teams. Again, keep the overall team size reasonable. If that’s not possible, break the project up somehow, just don’t ruin the success you gained previously by making it impossible to repeat it.

Each of the teams or teammates who were essential in the original project should take leadership roles in the new projects, and lead them to additional resounding successes that can be demonstrated. If this can be done a second time, with two teams simultaneously, the effect on the rest of the organization will be profound. It will probably not be a question of “Will it work?” any more, but a question of “How do we get that on our team?” For every group or team that asks this or other similar questions, you know you’re ready to replicate again, at an even larger scale with more teams in parallel. If your organization is particularly large, it probably wouldn’t be a good idea to push too hard, and force wholesale adoption quite yet. But for most companies that have maybe four to eight teams, wholesale adoption should be your goal at this point.

Conclusion

In summary, start with gaining allies, especially those who can support you with some level of authority. Follow up with education, and gaining more allies outside of the engineering organization itself, for example in the product owner group. Move on to a trial run, and indiscriminately neutralize impediments to guarantee a successful outcome. Finally, replicate the process, creating new leaders and experienced veterans of agile each time you do so. Eventually, you will build a lasting legacy and will have impacted the company’s bottom line in a positive way, not to mention earned the respect of many who said it couldn’t be done.

This time, we covered a lot of general advice and ideas for approaching a grass-roots adoption of agile in your organization. Many volumes have been written on this subject, so further reading is recommended, as we have barely scratched the surface of agile, let alone your role in it at your organization. But hopefully you’ve gotten a sense for how you might get started, and what success looks like. And remember, if you’re not in source, InSource!