In my last article, I shared details about three forms of agile disciplines: dynamic systems development method, scrum and extreme programming. In part two of this two-part story, we’ll explore several more agile methodologies: Rational Unified Process, Kanban and lean software development, feature-driven development and Crystal.
Rational Unified Process
Rational Unified Process or RUP is an object-oriented and Web-enabled framework that supports development and development processes deriving from IBM Rational. At the heart of the portfolio of Rational products is Rational Rose, a common modeling tool that uses the Unified Modeling Language (UML) to produce visual models of software architectures, databases, application requirements and reusable assets. RUP itself provides guidelines, templates, and examples for the various aspects of program development.
RUP serves the same function as the open source OPEN Process Framework or other object-oriented software with development tools, templates and processes that allow you to combine the procedural aspects of development. For example, you might merge defined phase, stages, techniques, and practices with other elements of development like models, documents, documentation and code. All such elements are tied together within a unifying framework, hence the name, “Rational Unified Process.”
RUP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development:
- Inception;
- Elaboration;
- Construction; and
- Transition.
Developers organize each phase into a number of separate iterations that must satisfy defined criteria before the next phase is undertaken.
Inception. At this stage the project manager states the project’s business case, and the team decides whether the project is worth doing or is even possible. This phase is important to the RUP process, since it’s where team members formulate the scope of the project and determine whether they have the resources required to be successful.
Elaboration. At this point the developers take a more granular look at the project to determine its foundation and architecture, and then they evaluate the architecture in relation to the overall project environment. The “stage” developers also analyze the risks associated with changing the scope of the project or adding new technologies or solution approaches while the projects is underway.
Construction. In this phase the team has completed development work for the project. The entire source code is written, and the application is ready for testing to determine whether the project delivers the requirements identified in the inception phase.
Transition. At this stage the delivery team performs fine-tuning. These final adjustments can be based on functionality, deployment experience or end user feedback.
In RUP, you produce only what is useful and required, similar to the extreme programming model. Within RUP the team updates the development plan throughout the process. Both RUP and XP methods seek to develop a system of best practices in software development.
Kanban and Lean Software Development
Kanban is another framework for managing projects in an agile fashion. Organizations use Kanban to manage the creation of products with an emphasis on continual delivery and on not overloading the development team.
This methodology came from the approach used by Toyota in its production system for “just-in-time” delivery. While manufacturing automobiles differs greatly from software development, you can apply the approach to managing either a production line or a software development project.
The approach between engineering, manufacturing, and supply side management dates back to the 1940s. Toyota optimized its engineering process by modeling how grocery stores would keep their shelves stocked with just enough product to meet consumer demand. This practice focuses on the optimization of flow between functional groups.
By looking at how supermarkets maintained just enough inventory — not too much and not too little — and the savings gained by optimizing the efficiencies, Toyota brought a new concept to its manufacturing floors. When a team who is assembling a car’s component (such as attaching the dashboard to the frame, for example), they give a card or a “Kanban” to each other signaling the need to pull more materials so they can continue to be productive. The idea of just-in-time ordering ensures the timely flow of materials to those who need them and sets the most efficient pace for each group.
Kanban is based on three basic principles:
- Visualize what you’re doing today (existing workflow). Participants have visibility into all the action items for each group.
- Limit or manage the amount of work in progress (WIP). This regulation helps to balance the flow of work to avoid outstripping those who are downstream from the actual work. It discourages teams from starting or committing to too much work at the same time.
- Enhance flow. When tasks are finished, the team works on the next highest priority task or project. This next activity is pulled from the backlog and put into the process workflow.
Kanban promotes and makes visual continuous collaboration on activities. It encourages active, ongoing learning and improvement by defining (and continually tweaking) the best possible team workflow.
By applying this process to software teams, Kanban matches the amount of work in progress to the team’s capacity to deliver. Kanban gives technical or solution teams more flexible planning options, faster output, clear focus and visibility throughout the development cycle.
Kanban teams focus only on the work that is actively in progress. Once the team finishes a work item, they pull the next work item off the top of the backlog. In response to customer need or team requirements, the product owner can reprioritize work in the backlog without disrupting the team, since those changes are outside the current work items in progress.
You might find it useful to add time estimates to each card to help quantify the work effort in each phase.
Lean Development, Estimating and Planning
Lean software development is an iterative agile methodology originally developed by Mary and Tom Poppendieck. They felt that software development was a continuous learning process based on iterations of code writing. Lean software development acknowledges that software design is a problem-solving process that calls on technical teams and developers to “surface” or expose problems and use what they learn throughout the development process. The success of lean is that the software is measured in fitness for use and not in the conformance of that software to requirements.
Instead of adding more documentation or detailed planning, software teams can try different ideas in writing and developing code. Presenting models or mockups to the end users and getting their input streamlines the process of gathering stakeholder requirements. Running tests as soon as the code is written optimizes the efficiency and reduction of defects needing more testing.
Lean software development focuses the team on delivering value to the customer and on the efficiency of the “value stream.” It emphasizes those approaches or mechanisms that deliver that value.
The main principles of lean methodology include:
- Eliminating waste;
- Amplifying learning;
- Deciding as late as possible;
- Delivering as fast as possible;
- Empowering the team;
- Building in integrity; and
- Seeing the whole.
Lean methodology eliminates waste through activities such as selecting only the most valuable features for a system, prioritizing those selected features and, finally, delivering them in small batches. Lean focuses on the speed and efficiency of development workflow and relies on rapid and reliable feedback between developers and stakeholders.
Lean leverages the concept of work product or deliverables being “pulled” via customer requests. It focuses on individuals or development teams and their ability to make decisions, because research has shown this to be faster and more efficient than hierarchical flow decision-making.
Another important aspect of lean is the efficient use of team resources. Making every team member as productive as possible is the overriding goal. Lean seeks to improve efficiencies through the completion of development being accomplished with the fewest possible intra-team workflow dependencies.
When using a lean approach to software development, there’s strong encouragement to create automated unit tests at the same time the code is written, increasing the efficiency and validation of that programming.
Some of the tools of a lean software development process are:
- Daily standup meetings;
- Cumulative flow diagrams;
- Virtual Kanban systems;
- Visual controls;
- Small batch sizes/single-piece flow;
- Retrospectives; and
- Operation reviews.
Lean can leverage other frameworks, which means you can implement lean with other software development processes and methodologies, such as scrum or test-driven development (TDD).
Feature Driven Development
Feature-driven development (FDD), another variation on the agile theme, is a model-driven, short-iteration process for delivering technical solutions. This method was borne out of a need to focus on the key features that stakeholders wanted and to have the technical teams emphasize development efforts that align with this.
Jeff De Luca created FDD, and major contributions and influences came from Jon Kern, Stephen Palmer, M.A. “Raj” Rajashima, Lim Bak Wee and Paul Szego. If you do some online searching, these contributors have posted great writing, comments and whitepapers embellishing upon the process and use of FDD.
With FDD, you start by shaping an overall solution and then you continue with a series of iterations. These iterations usually run two weeks and focus on “design by feature” or “build by feature.” You keep each iteration small to help produce results that are the most useful to the customer. An FDD team designs all of its development processes around key feature implementation using these eight practices:
- Domain object modeling;
- Developing by feature;
- Component/class ownership;
- Feature teams;
- Inspections;
- Configuration management;
- Regular builds; and
- Visibility of progress and results.
FDD best practices guide the programming team to follow “regular builds” and “component/class ownership” so that scaling for large development projects or programs is more straightforward than other approaches and is more useful to larger teams on cross and interconnected projects.
FDD as a development methodology differs from other methodologies in that it has very specific, short phases of work, which are geared to each feature identified by the customer. Key phases within FDD are:
- Domain walkthrough;
- Design;
- Design inspection;
- Coding;
- Code inspection; and
- Promote to build.
Crystal
Crystal is a family of agile software development methodologies developed by Alistair Cockburn and based on his 10 years of research, where he studied the properties of successful projects. This research showed two key elements. First, the properties of projects changed based on the number of people involved. Second, the “criticality” of the project, ranging from loss of discretionary money to the loss of life, had a direct impact on the team and their success.
The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of agile methodologies. Some examples are Crystal Clear, Crystal Yellow, Crystal Orange, and others, whose unique characteristics are driven by several factors such as team size, system importance and project priorities.
This Crystal family addresses the realization that each project might require a slightly tailored set of policies, practices, and processes to meet the project’s unique characteristics.
Crystal is not “all or nothing.” Teams using other agile frameworks such as RUP, XP or other methodologies can “borrow” useful techniques from Crystal Clear. Similarly, if you’re using the Crystal Clear method, you can also leverage from other methodologies.
Crystal introduces the importance of people and communications, and it encourages teams to adjust the techniques used in a project to the characteristics of that particular project. While other software development methods, particularly other agile methods, stress the importance of people, the Crystal family puts an emphasis on people and communications as its organizing principle, with most of the properties and techniques based on strengthening that process.
The following chart references the right Crystal method starting point for a team.
Along the X axis is the size of the team. As a team adds more team members and gets larger, it moves to the right along the x-axis, indicating the increased difficulty of managing the process through face-to-face meetings, forcing the increased need for coordinating teams by documentation, development practices and tools.
The Y axis addresses the system’s potential for causing damage. The lowest damage impact is loss of comfort, then loss of discretionary money, loss of essential money and, finally, loss of life.
Essentially, the graph uses the team’s size and the impact of the system being developed to identify the corresponding Crystal methodology. Each of the different methodologies has a set of recommended practices and a core set of roles, work products and techniques for how to work.
The key tenets of Crystal incorporate teamwork, communication and simplicity, as well as reflection to frequently adjust and improve the process. Like other agile methodologies, Crystal promotes early and frequent delivery of working software, high user involvement, adaptability and the removal of bureaucracy or distractions.
Next Time
I hope this overview has given you a taste of the various concepts that are important to the disciplines of agile. Upcoming articles will address risk management in agile and then dive into the use of Microsoft Project tools for working within agile.
If you saw an example or template that intrigues you or that you find useful, please reach out to me directly at Tim.Runcie@Advisicon.com. I’d love to share these with you and help your continued journey with Microsoft Project and project management and agile disciplines.
Image Source
