Summary: Lean-Agile, the Senior Developer, and Progressing toward Maturity Sometimes, as a coach, you encounter a team who knows their domain really well. They have been developing applications in this space for a long time. They may not see the need to change to a new method, when the usual approach has worked just fine, thank you. Agile just seems foreign to senior developers who know their domain really well. They may resist. They probably do not understand why they need to change and have little incentive to do so. They have to climb a fairly steep learning curve to get out of their old habits. It takes a while for teams to become efficient in Agile. Our experience shows that the first few iterations may actually be less efficient than using the more traditional approaches, until the team’s mindset starts to change. Rod Claar's rule of thumb is For a team to get truly proficient in agile, it will often take the same number of iterations as the number of stable members on the team. Thus, if you have 8 members on your team and you are doing 4 week iterations, you can expect the team to be truly proficient in about 8 months. They will certainly start making progress sooner, but won’t be rock-and-rolling until later. As a coach or a ScrumMaster, part of your job is to set expectations. It is crucial that you caution the team and the management about how long it will take them to get efficient, so that they do not lose heart. This is especially important if they have been exposed to some of the hype that can surround Agile. There are several reasons for this. Lean-Agile is all about continuous process improvement. You will be making changes and tweaks to your processes all the time; you can expect major tweaks as you start out and are still learning. Lean-Agile is about adapting to a context. What works in one team and one context will not translate exactly to another team and another context. That is why we teach principles and give descriptions of practices in other places and then coach teams in how to work it out for themselves. Adults take time to unlearn approaches before they can learn new approaches. Transition is hard. The more they understand the motivations to change, the easier it will be for them. Senior developers often see problems sooner This is both good and bad. Based on their experience, they can identify problems that they know will come up and can move to solve them more quickly. But they might try to build solutions that anticipate problems that might arise in the future. The problem here is that those problems may never come up and you end up with applications that are more complex than is required. One common example is building general frameworks. How many times have you seen developers build elegant frameworks that allow subtle and varied ways to interact with an application? They can be nightmares to maintain. And yet the developers become enamored of their solution and end up spending lots of time and building in lots of features that are rarely, if ever, used. In Lean-Agile, this is called “Waste”. The overuse of design patterns is another good example of this. Now, frameworks are good and design patterns are good, but we prefer to see them built and used based on an evolving understanding of the environment. The requirements should give you the hints about what is needed next. You want the requirements to “pull” the framework, rather than pushing a framework on a system. Scott Bain discusses this in his new book on Emergent Design. Rod thinks the same could be done for Emergent Database Design: the interface between systems needs to emerge over time. A series of conversations with Rod Claar This show begins a series of conversations with Rod Claar, a Senior Consultant with Net Objectives. Rod is a Lean-Agile coach and a trainer in design patterns and test-driven design. He has worked with many clients as they begin their journey into Lean-Agile approaches. In this podcast, we will cover: Lean-Agile Meet
