During preparation for a presentation on agile and agile implementation, I started to think about what to do when you cannot implement a full agile system up front. I decided I would go for retrospectives, simply because they represent the core idea of agile: to improve the way we work. Therefore, retrospectives will drive the process in the right direction, even without Scrum, kanban, Extreme Programming, or any other fancy agile process.
Improvement requires that you know what to change, and retrospectives can help you identify just that. When you know what to change and why you want to change it, you can look into Scrum, kanban, or lean and get inspired by the practices in order to find something you can experiment with for a while.
In order to get retrospectives to work, you must do them properly and regularly. You and the group you work with should identify one or two problems with the way you work. You all have to agree about why these problems are important to solve. The next step is to choose one of the problems and define a hypothetical solution. The solution is hypothetical because you do not know if it is the right solution. You have to define how to identify that it actually solves the problem, i.e., how you will measure that the change you introduced works and removes or at least relieves the problem.
Retrospectives should be performed at regular time intervals of at least every four weeks. There are two reasons for this. Firstly, it means you must keep the changes small. If the change seems big, break it down. A consequence may be that you are not able to fully solve the problem, but it is far better to make a small change and solve some part of the problem than to try to make a big change and fail. Secondly, it allows for agility in how you change your processes. When you change in one direction, new problems may arise, and you can take them up in due time. If the time span between retrospectives becomes too long it, is my experience that the effectiveness of the retrospectives decreases. I believe the main reason is the lack of focus on the improvements, which causes team members to return to previous bad practices and habits.
The single largest risk in performing retrospectives is that you could identify the problem and describe the hypothetical solution and related measurements, then just go back to your daily work without any of the changes being implemented, and the solution slowly disappears in the mist of daily tasks. To avoid this, you need two things: a solution champion and a visual representation of the measurements.
The solution champion is someone who takes ownership of implementing the hypothetical solution and following up on it. Consequently, the solution champion cannot do as much "normal" work because he or she now has this important improvement task. This may sound obvious, but in my experience, this is the main reason for not following through on improvements—no one actually was assigned the responsibility or time allocation to do it. A visual representation of the measurements is needed to provide clear feedback to all involved on the progress of the hypothetical solution. This enables people to act or comment on the progress.
The benefit of starting an agile or lean transformation simply with retrospectives is that the transformation will focus on the right problems, and you can avoid introducing new ones. If you implement a whole agile process framework (e.g., Scrum), the retrospectives often end up focusing solely on the newly introduced process and not the underlying problems. By starting with retrospectives, the practices you introduce are chosen because they solve a problem you all have agreed upon, not just because they are part of a process framework. This makes the practices more relevant, and the mere fact that you are trying the practices as a solution to a specific problem may make it easier to introduce the process and get working.