The Agile Heart of the Unified Process

Using RUP as a Scaling Framework for Scrum

One of the common complaints I hear about the Rational Unified Process is that it is too prescriptive and document focused. An often heard complaint about Scrum is that it does not scale to large projects and you never quite know where you are going until you get there. What if we could leverage the best of both methodologies? What if we could deliver with just enough structure and documentation to scale the project but maintain the collaborative, human centered approach of Scrum?

Agile projects begin to break down at scale. This is due to Agile's dependence on human interaction to transmit information between team members. Agile practices such as collocation and pair programming place a premium on human interaction and rely less on artifacts and formal handoffs. The problem is that as the team grows, information does not get communicated to everyone. It becomes more and more difficult for everyone to share a common understanding of the system. There are greater separation of concerns as members begin working on different aspects of the solution. Some degree of documentation is necessary to keep everyone on the same page.

The secret to scaling Agile lies in doing just enough up front planning to ensure the teams understand the big picture of the product they are creating and have defined the significant mechanisms of communication between the various subcomponents. The RUP provides an ideal framework for helping a collection of small teams define what needs to be done in support of a large scale Agile development effort.

Inception

The goal of Inception is to minimize business risk. This means that you have to understand the vision for what you are trying to create, have a high level understanding of the requirements, and have defined the characteristics of the systems architecture you intend to build.

Begin Inception with a single Scrum team. The team should at a minimum have a ScrumMaster, a Product Owner, an Analyst, a Quality expert, and an Architect. The product backlog will include the features necessary to create the Vision, Use Case Inventory, and Candidate Architecture. It may be necessary to include features in the Inception backlog that prove key aspects of the business vision.

Inception is the least code focused of all the RUP phases. This is due to the requirement to have an idea of where you are going before you begin the project. Since Inception is the least focused on creating working software, and without working software the team is not mitigating risk, it is in the team's best interest to make decisions quickly and get on with the business of delivering working software.

Key artifacts you may want to consider include: the vision, use case inventory, candidate architecture, risk list, and a high level project schedule.

Elaboration

The goal of Elaboration is to minimize technical risk. This involves choosing the smallest subset of features that will prove out the significant technical assumptions made during Inception. At the end of Elaboration, the system should be fully functional with the subset of features you have chosen to build. The system should be fully tested and the team should be confident that the architecture is stable.

During Elaboration, you may still have a single Scrum team. It is likely that you will add several more senior level technical folks to help begin building the system. The product backlog includes the features necessary to prove the application architecture and to deliver any non-functional components required to build out the system. It is important that the Elaboration backlog contain features the team will need to collaborate at scale. Source control, build environments, automated testing infrastructure, instant messaging, and collaboration software should not be overlooked when preparing to scale an Agile team.

Key artifacts you may want to consider include: a use case survey, descriptions for architecturally significant flows, an architectural description, the architectural prototype, and the results of executing tests of the architecture.

Construction

The goal of Construction is to mitigate logistical risk. This is where the bulk of the software is created and where the Agile team really begins to scale. The core team that helped build the foundation of the system during Elaboration is broken up to seed the newly created Scrums. Each team is organized around a major component of the architecture or a significant feature set within the overall scope. Each team is a complete cross-functional entity that is responsible for delivering its part of the system. These teams are coordinated by a master team that includes a more senior ScrumMaster, Architect, its own technical staff, and the Technical Leads and/or ScrumMasters from the component teams.

At this stage, the backlog is completely feature driven, progress is extremely measureable, and the teams are focused on delivering the bulk of the business value to the customer. As is true during every phase, the code delivered at the end of each Construction iteration is fully tested and integrated with the rest of the system.

Key artifacts you may want to consider include: use case descriptions, supplementary specifications, designs, code, tests, test results, training materials, and user documentation.

Transition

Transition is focused on mitigating deployment risk. This phase deals with training and hand-off to the customer, final user testing, and resolving any issues that were not caught earlier in the process.

During this phase, the team should be able to scale back down to a single cross-functional team or two. The backlog is related to the remaining documentation, training, and defect resolution features remaining to get the product in the hands of the customers.

Key artifacts you may want to consider include: installers and data conversion plans, customer surveys, and an outstanding defect list.

Conclusion

To scale an agile project, you must have enough of a vision to help the team understand where the project is headed. You must understand enough about the scope and size of the project to help the business understand what they can commit to market. You must have enough of a plan to help the team understand that they are on course or if corrections need to be made. You must have enough of an idea of the solution you are going to build such that teams can work independently from each other and converge on a coherent solution.

The RUP provides a process framework for helping the team understand how and when to scale with Agility. Careful use of the RUP artifacts, UML, Process, and Process Mentors can aid the team in coming to a common understanding of the evolving system. Documentation should always be used to faciliate communication, so used carefully, these tools can become a powerful contributor to overall team success. Subscribe to Leading Agile

Covey's 4 Disciplines of Execution as an Agile Framework

Stephen Covey, in his bestselling book "The 8th Habit: From Effectiveness to Greatness", outlines four disciplines, that when consistently applied, result in high performing organizations. The Agile movement is based upon a value system and specific core practices, that when consistently applied, result in high performing software development organizations.

Establish Wildly Important Goals: A team can only focus on 1-3 things at a time and be successful. The more goals we add to the list, the lower our chances of delivering any of them. Make sure you are focusing on what is really important.

Agile teams partner with the business to establish a goal for each iteration. The goal is established to deliver the highest value to the business and mitigate the most risk. Every member of the team is collectively responsible for delivering on the goal of the iteration.

Translate Strategy to Tactics: So you know what your goals are, now what are you going to do about them? For an organization to be truly effective, leadership must help the team translate the lofty goals into meaningful action.

Once the goal has been established, Agile team members volunteer for specific work that will contribute to the meeting the team's goal. These work items are immediately decomposed into tasks and the team members self select these tasks. This becomes the detailed work plan for the iteration.

Create a Compelling Scoreboard: High performing teams play to win. If someone is going to win, you have to keep score. A scoreboard that clearly demonstrates team progress toward its goal generates excitement and enthusiasm. A scoreboard motivates.

Each iteration ends with an increment of the product that can be reviewed by the business. Delivery of working software is one lead indicator the team is making progress. Other lead indicators are the number of story points (or possibly ideal engineering hours) the team was able to get accomplished during the iteration. Agile teams often create burn down charts to show the rate of progress against their ultimate goal of delivering a complete system. Because these measures are based on real software delivered to the business, they are accurate indicators of the overall health of the project.

Hold Each Other Accountable: Accountability is the key. As individuals, we have to understand that there are others that are counting on us to deliver. There must be some consequence for failing to deliver. Shared accountability drives performance.

Agile teams are accountable. Accountability begins with the iteration planning meeting. This is where the team recaps what was accomplished in the previous iteration and plans what it will do in the upcoming iteration. The team must demonstrate its progress and show what it will do to meet the overall objectives of the business. The team members are also accountable to each other during the daily standup meetings and retrospectives. Most importantly, Agile teams are accountable for delivering a complete working solution that meets the needs of the business.

Agile is framework around establishing a culture of empowerment, lifting the individual, and tapping into the vast reservoir of human potential and creativity. Agile is a foundational set of principles, coupled with a ever evolving toolkit of specific practices, for focusing the team on what is most important to the business, working with the business to decide what tasks will deliver on that goal, establishing measures for key lead indicators such that the team always understands its progress, and encouraging a culture of trust and accountability that will ultimately drive performance. Subscribe to Leading Agile

Does the Agile Project Leader Exist?

What better way to get a blog on Agile Project Leadership kicked off than to challenge the very assertion that there is such a thing as an Agile Project Leader. Is the idea of an Agile Project Leader even a valid concept? Could we not make the case that Leadership is Leadership no matter what the context or problem domain? If we are going to use the word "Agile" as a modifier in front of the words "Project Leader", what does it really mean? What new information are we trying to convey about that person? What does it tell someone about you that they did not already know?

Let's break down the phrase "Agile Project Leadership" and all get on the same page about what these words mean.

Websters defines leadership as the "act or instance of leading" and leading as "guiding on a way, especially by going in advance". While one can certainly use this as a working definition, it does not seem to capture the nuance or power associated with the word "Leadership". Since this is not a particularly satisfying definition, I have included several quotes from others on what it means to be a leader:

• The servant-leader is a servant first. It begins with the natural feeling that one wants to serve. Then conscious choice brings one to aspire to lead. The best test is: do those served grow as persons; do they, while being served, become healthier, wiser, freer, more autonomous, more likely to become themselves servants - Robert K. Greenleaf
  
  
• The best executive is the one who has sense enough to pick good men to do what he wants done, and self-restraint to keep from meddling with them while they do it. - Theodore Roosevelt
  
  
• Management is doing things right; leadership is doing the right things. - Peter F. Drucker
  
  
• Leadership is the art of getting someone else to do something you want done because he wants to do it. - Dwight D. Eisenhower
  
  
• Don't tell people how to do things, tell them what to do and let them surprise you with their results. - George S. Patton
  
  
• Leadership is communicating to people their worth and potential so clearly that they come to see it in themselves - Stephen R. Covey

The key ideas embodied in these quotes are that leadership is about service, setting direction, doing the right things, empowering, and developing your people.

One would think that the definition of a Project should be a little easier to handle. Using Websters again to get us started, a project is defined as a "specific plan or design". A quick search on the web seems to hit closer to the mark. On Wikipedia for instance, a project is defined as a "one time endeavor undertaken to create a unique product or service".

Project Leadership then seems to involve being out in front, guiding the way, serving the team, doing the right things, empowering, motivating, and developing your people; all within the context of a finite, one-time endeavor undertaken to create something unique. It appears that this might be just enough of a definitition to cover both general "Project Leadership" and "Agile Project Leadership". Why bother modifying this description with the word "Agile".

Well, before we dismiss the idea, let's explore just what "Agile" means in a little more detail.

Websters has two interesting definitions for the word Agile: "Marked by ready abilility to move with quick and easy grace" and "having a quick and resourcful and adaptable character". Wikipedia is all over the place with the word "Agile" but bringing it into the software context does make things a bit more clear. Agile software development is defined as a software development framework that promotes evolutionary change throughout the entire life-cycle of the project. The key point in this definition is that Agile promotes evolutionary change through the life of the project.

It seems then that the new information about a leader imparted by the word "Agile" is that the "Agile Project Leader" also has the added ability to move quickly, be adaptable, and promote evolutionary change through the life of the project. Is it possible then to make the case that this idea of Agility is really embodied in our orginal definition of a "Project Leader"? Is it not implied by the requirement to be out in front or to do the right thing?

The problem with stopping with the textbook definition of Agile is that the word "Agile", in the context of an "Agile Software Development Project", is actually a bigger concept than we have just implied. While an Agile Project Leader would need to be able to move quickly, be adaptable, and promote evolutionary change; the Agile Software Development movement is founded on a set of very specific principles that intentionally promote a culture of adaptability and evolutionary change. Not just any principles pass the test to be considered Agile no matter how close they may meet the textbook definition fo Agility.

The founders of the Agile movement have crafted a set of beliefs intented to unify the various factions within the Agile community and define what it means to be Agile. These beliefs are embodied in a document called the Agile Manifesto and establish a value system for the Agile practitioner. Sometime after the Manifesto was created, another group of leaders created a similar set of unifying statements specifically for the Agile Leader. This belief system is called the Declaraton of Interdependence. Both are available online but are included here for easy reference.

Agile Manifesto

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
  
  That is, while there is value in the items on the right, we value the items on the left more.
  

Declaration of Interdependence

We are a community of project leaders that are highly successful at delivering results. To achieve these results:

• We increase return on investment by making continuous flow of value our focus.
  
• We deliver reliable results by engaging customers in frequent interactions and shared ownership.
  
• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
  
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
  
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
  
• We improve effectiveness and reliability through situationally specific strategies, processes and practices.

In addition to these unifying principles, the Agile community appears to be coalescing around series of best practices that in turn support the principles and desired outcomes of Agile project teams. Practices such as timeboxing, colocation, customer collaboration, test first development, and pair programming are a few examples of practices believed to deliver the desired outcomes of an Agile project.

So then... what desired outcomes are unique to an Agile Project? Aren't all projects interested in delivering on-time, on-budget, with all the scope, and with high quality? Are the desired outcomes of an Agile Project any different from the outcomes of a more traditional project? Project Managers are typically evaluated based on the delivery of the project within the agreed upon time, cost, and scope constraints agreed to at the beginning of the project. In a sense, the Agile Project shares these objectives but is not willing to deliver these outcomes at the expense of the team. The Agile Project adds to these traditional outcomes objectives around team health, sustainability of the system, indivudal empowerment, and the means for the team to set itself up to deliver the next project.

For the sake of argument, let's assume for a moment that there is such a thing as an "Agile Project Leader" and that it is materially different from a standard "Project Leader". It appears that word "Agility" is not intented to exclusively modify the characteristics of the leader, but implies that leader will employ a set tools and techniques according to a specific set of principles that will support a specific set of desired outcomes. These principles, tools and techniques, and desired outcomes are not static and are expected to evolve as the community matures in its understanding. The Agile community is too new to have a static body of knowledge and the establishment of such would seem to go against the very principles the movement was founded on. With that said, there is clearly a direction and there is clearly an accepted baseline.

So what does all this mean for the fate of our Agile Project Leader?

The logical conclusion is that an Agile Project Leader is differentiated from a Traditional Project Leader by their ability to apply specifc strategies based on the the tools, techniques, and principles associated with the Agile Software Development community and embodied in the Agile Manifesto and the Declaration of Interdependence. It seems that much past that Leadership is just Leadership.

Subscribe to Leading Agile