Lean Practice-based Software Development
Software process improvement can be disruptive, but it does not have to be. Through our practice-based approach, we give your software organization the ability to focus on and change only what’s needed—retaining those parts of your existing software process or approach that are serving you well. Practices provide packaged solutions to specific software-development problems. Use them one by one or in any combination required to suit the needs of your organization or project.
- One size no longer has to fit all
- Consistency is achieved through the standard practice library
- Flexibility is achieved by composing the appropriate practices for particular types of work
From Process to Practices
Treating processes as collections of practices is fundamentally different: instead of learning or adopting an entire process, practitioners learn about individual practices and adopt them incrementally to rapidly improve their ways of working. First, they select the most appropriate practices to address their needs and cope with the challenges they face. Then, they implement the necessary practices in whatever combination and at whatever speed suits them. Importantly, they can add new practices to their existing way of working without changing everything or throwing away the practices they already know and depend on.
Separating Governance Needs from Practitioner Needs
Software practitioners need be empowered to do whatever is necessary to build great systems. Management need visibility and control of what is being done. There is often a tension between these two needs – practitioners fear intrusion whilst management fear loss of control. A practice-based approach enables a separation of concerns between project activities and project governance. With practices you can not only create and combine any set of practices to meet your specific needs, but you can create and adopt any lifecycle that suits the governance needs of your project, programme or organisation. Many of our customers use the Unified Process lifecycle – for them, it’s time proven and it works. However many other customers create their own lifecycles (typically 2 or 3) to address the needs of specific project types within their organisations, for example exploratory projects, projects where requirements or architecture are stable or unstable, or maintenance projects.
Keeping it Simple and Light
Most process documentation is of the “written once and read never” variety. And yet for new approaches to be successful across a large community of practitioners, some level of guidance is essential. For people to be able to read and digest practice guidance it needs to be simple and light. All of our practices contain guidance presented in an easy card-based format. Using cards means that the guidance is concise and focused. The practice guidance focuses on the essentials: the things that you always need to do and the competencies required in order to be successful.