Agile development techniques emphasize a powerful value system that increase productivity and effectiveness of teams, however, they become even more powerful when blended with the full project lifecycle methodology of the Unified Process.
I was recently invited to participate in a questionnaire regarding the Essential Unified Process (EssUP) and RUP which prompted me to look more deeeply into EssUP and reflect on the many variants of the Unified Process that exist.
Continue reading "Essential Unified Process and Research Questionnaire" »
With the increasing interest in Agile techniques such as Scrum and XP, I often come across clients and project managers assuming that these approaches alone are sufficient to ensure the success of their projects. In actuality, the Agile Principles are really a value system that help contribute to effective behaviors on a project. None of the agile techniques recommend dispensing with the well defined practices that govern effective project implementations such as risk, scope and change management (amongst others). In fact most of the Agile techniques found in current literature are intended to work within existing frameworks and metamodels, without which your projects won't succeed.
When I develop project plans and teach project management approaches, I frequently turn to the Metamodel offered by the Unified Process. What I like specifically about the Unified Process is that it breaks a project into four phases (Inception, Elaboration, Construction and Transition) that have clear entry and exit criteria that are easy to manage against. In addition the phases are well defined and relatively intuitive to most people (Inception involves scoping and structuring the project, Elaboration focuses on de-risking the project and developing an Architecture, Construction emphasizes the rapid development phsae of the project and Transition focuses on readying the application for deployment).
The UP also contains a number of useful 'disciplines' which reflect major workstreams in a project lifecycle. Business Modeling, Requirements, Analysis and Design, Implementation, Test and Deployment ebb and flow across the project lifecycle while Project Management, Configuration/Change Management and the Environment disciplines are focused on supporting the lifecycle in its entirety (these latter are found in the IBM version of the Unified Process called the Rational Unified Process.
The popularity of the Unified Process is reflected in its evolution into a number of forms including the Agile Unified Process, Enterprise Unified Process and even the Oracle Unified Process. IBM recently released an open source version called OpenUP which is based on its popular Eclipse Process Framework.
Over time I've come across a number of agile/lean techniques that support the disciplines I mentioned above and enhance these disciplines to make them more effective. Over the next few postings I'll offer a walk through on a discipline by discipline basis on each of these techniques.
One of the challenges of effectively implementing a large scale, enterprise iterative development program is that there is little in the way of literature on how to effectively scale iterative projects into a program. Most of the literature focuses on the 'relatively' well defined issue of managing a single software development project. Looking at Scrum, XP, DSDM and even RUP none of these approaches really address the challenges of implementing iterative development techniques across a broad number of software development projects that operate as part of a program.
While there is a good program management plug-in for RUP and Ambler's Enterprise Unified Process extends RUP beyond its project phases, there is nothing readily available that provides a lightweight and highly engaged program management office which applies some of the same principles of iterative development to a Program Office. Of course there is a well established body of knowledge around Program or Programme Management but these bodies of knowledge emphasize a program office focused more on administrative and financial oversight of a number of projects.
Large enterprise deployments to tens of thousands of users have 'long tails'. These tails represent the time and effort that goes into deploying an application into multiple separate environments for testing, training and ultimately transitioning into Production. RUP uses the Transition phsae to capture some of these activities but most large organizations have their own specific processes including 'black-out' periods, SOX and other compliance needs and the need to coordinates across multiple departments. Where many large organizations struggle with adopting iterative development processes is when they begin to examine the practicality of moving a release through the long tail of their deployment process. Since this tail often has an insatiable desire for detailed requirements (to justify purchasing expensive hardware or to satisfy Service Level Agreements with outsourced support organizations) it becomes enticing for the organization to move back to its waterfall approach (or it redefined iterative development as simply applying to the RUP Construction phase).
Tackling this challenge requires a thorough understanding of the organizational dynamics of large scale organizations and a willingness to educate the often independent groups which support the 'tail' of the deployment process. The first step is to adopt a more program centric view of how multiple projects can work together leveraging an approach such as the System of Systems pattern. The next is to develop a communication and awareness plan which helps support groups in the 'tail' better understand how iterative development practices work and what they can do to support this approach. I'll try and write up some specific observations of how to tackle these program level iterative development issues in the weeks ahead.