| If you are working on a project that is on the unsustainable development curve, the most important thing you must recognize is that you can't just "blow up" your current processes and practices. That would most likely lead to disaster. Next, you need to recognize that achieving sustainable development is going to take time, and probably more time than you think. You also have to recognize that you are going to have to make compromises and can't strive for perfection; you likely won't ever have the architecture you'd like or have tests in place for every single line of code. Just think about getting continually better over time, in tiny increments if need be. If you can, start with a small team. Then, use the successes and knowledge gained in that team to get other teams involved. You might want to consider moving people between teams if you can. New people added to a highly efficient team will be able to learn the new principles quickly. However, you need to be careful when moving people from the "model" team to other teams because they can easily get buried in the day-to-day reality of their new team unless they are strong, persistent leaders/coaches or can be moved in pairs or sub-teams. You might want to think of these sub-teams as a "tiger team", that can be added to any project and lead change by example. But these people must not think of themselves as better or superior. Unsustainable projects, or those on the path to unsustainability, are likely going to have a few key problems that are going to need targeting. Most likely, these will include aspects such as: Legacy code that is poorly structured and has many broken windows. Inadequate or nonexistent test coverage. Attitudes that result in the use of phrases like "ship to QA" or "throw it over the wall for testing." These are indicators of a defect detection culture, where developers are not doing enough testing themselves. Entrenched development practices and attitudes that are counter to what is required. The longer practices have been used, the harder it is to change them and the easier it is for people to go back to them at the first sign of trouble or stress. Defect rates that are unsustainable and increasing. Bureaucratic project management practices that emphasize planning and tracking progress against the plan. A lack of understanding of the current development problems and visibility into their magnitude.
Where to Begin Assuming that you have buy-in to change and have decided on your approach (training, consultants, etc.), where do you begin? Start by analyzing the mindset of your organization and mapping it against the four principles: continual refinement, working product, defect prevention, and design emphasis. Given that your early goal is going to be building wins, the following practices can be used to produce results quickly: You can get an errant project back on track quickly using the agile project management practices simply by beginning iterative development, tracking your velocity, using daily standup meetings, and retrospectives. Start ruthless testing by emphasizing unit tests for new code and, if you can, by putting safeguards in place such as system level tests to catch regressions sooner. Introduce simple design and refactoring. If you aren't already doing so, make sure your product is built nightly (completely, from scratch) and that you are using a configuration management system. Pay attention to your design practices. If you do a lot of up-front design currently, don't stop doing design because you don't think it's agile. Don't get hung up on simple design and emergent design. Start with frequent rapid design meetings and architectural reviews. Make sure you have a defect tracking system in place and that you are rigorously tracking defects. Then, start collecting some metrics to find out what kind of defect trend and backlog you have. This will help plan your next steps to help get defects under control. As you become familiar with the new practices, use your retrospectives as a way to review the practices from this book (or any other good source) and introduce new practices as you see fit.
The Three Phases of Change There are three phases that a change initiative goes through. Each phase has its unique challenges and pitfalls. It helps to be aware of which phase you think your change initiative is in so the team can have realistic expectations and goals. In the initial phase, the challenge is to get started and to develop the first wins. A common failure in this stage is to have expectations that are too high and then to give up when they aren't met. Enthusiasm has to be high in at least a core group of people to make a difference. It may be a good idea to form a guiding council to channel the initial enthusiasm. In the second phase, the challenge is to work through the inevitable peaks and valleys of enthusiasm and results. A common failure in this stage is to assume the job is done, wrap everything up, and then a few months later realize that too many old behaviors are coming back. The third phase is one of ongoing maintenance. The main goal in this phase is to simply ensure that the keystone principles and practices are in place and that there is continual learning and improvement. Probably the most common failure in this stage is to lose discipline on a keystone practice such as retrospectives so that opportunities to learn and improve are missed.
|
|
