Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally. In some cases, management may even be hostile to the concepts and practices of Agile methods. If you are interested in Agile, you don’t have to give up hope (or look to switch jobs). Instead, here are some tips to start using Agile methods even in hostile environments.
Some Agilists claim that the retrospective is actually the key to being Agile. In some ways, this is also the easiest practice to introduce into an organization. Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“. These are retrospectives that can be done in 15 minutes or half an hour. Try to do them with your team weekly. If you are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting. If you are “just” a team member, you might have to get some modest amount of permission.
So why would it be good to do a retrospective? Because it’s a high return-on-investment activity. For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning. Here are a couple more articles about the importance of retrospectives:
Although I strongly recommend starting with retrospectives, sometimes that’s not the best
way to start. Myself, my first formal Agile environment, I started with the Daily Scrum. Another time less formal, I started with Test-Driven Development. In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months. This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders. This is the practice-by-practice approach. Start with a simple Agile practice that you can do without asking anyone for permission. Make sure it is a practice that makes sense for your particular environment – it must produce some benefit! If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start. If you are more business-oriented, then maybe consider user stories or one of the Innovation Games. If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.
It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another. If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.
Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy. This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”. This is an opportunity to do Agile. Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.” There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support. In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it. Don’t talk about it.
The “just do it” approach requires that you have some influence. You don’t have to be an influencer, but you need connections and you need charisma and you need courage. If you don’t have at least two of those three, you shouldn’t try this approach. You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works. Here are a few comments on Stealth Methodology Adoption.
There’s nothing like working with a band of rebels! If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work. Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans. Of course, you need to actually execute some of your plans. Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.
But, like any rebellion, you really need to trust those you work with in these early stages. Lacking that trust will slow everything you do possibly to the point of ineffectualness. Trust means that you have, for some time, a formal vow of silence. Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.
|Talent Development Centre subscribers can get 25% off Agile training! Visit www.worldmindware.com and use promocode EPR-25-CSM-MV4A for Certified ScrumMaster courses and promocode EPR-25-CSPO-QE7X for Certified Scrum Product Owner courses.|
About the Author
Mishkin Berteig is the President and Co-Founder of Berteig Consulting Inc. He has been training, coaching and consulting for organizations adopting Agile methods since 2001 and is committed to helping individuals, teams and organizations apply Agile methods. Mishkin is a Certified Scrum Trainer, and qualified to deliver OpenAgile and Agile Project Management training. He has developed and delivered Agile training both in public and in-house seminars for over 3000 people in Canada and abroad. Courses have been as short as three hour intro-style and as long as five day boot-camp-style, and audiences have ranged from junior team members to senior executives. He has also assisted organizations of all sizes to make the transformation from traditional methods to Agile/Scrum methods (Extreme Programming, Scrum, Lean, OpenAgile). Assistance includes Agile Engineering Practices, Agile teamwork, Agile project and product management, Agile management and executive management.