The Unified Process and Scrum

Earlier this year I did a presentation at Agile 2008 on using RUP as a scaling framework for Scrum. The talk was pretty poorly attended and clearly controversial. Earlier this morning I was up on my Slideshare account, pulled the talk up, and did a quick walk through on the presentation.

I really think the concepts here are solid and central to any serious conversation about scaling agile in the enterprise.

If you get a minute over the holidays, take a look at the presentation and give me some feedback. How could we take these foundational concepts and make them more palatable to the broader agile community?

Using RUP As A Scaling Framework For Scrum

View SlideShare presentation or Upload your own. (tags: agile rup)

Subscribe to this blog Subscribe to Leading Agile

Assumptions are Made to be Validated

"Every project is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis is a tool that explores the validity of assumptions as they apply to a project. It identifies risks to the project from inaccuracy, inconsistency, or incompleteness of assumptions." - A Guide to the Project Management Body of Knowledge, Third Edition

Making assumptions is essential in project management. Assumptions simplify our understanding of the problem domain and allow us to move forward in the face of uncertainty. Without the ability to make assumptions, our projects would become paralyzed, unable to deliver the value for which they were created.

The success of our projects is largely determined by the quality of our assumptions. Therefore, by making assumptions on our projects, we are accepting some degree of risk that our assumptions could be wrong. Anytime we assume risk, we need to understand the probability the risk will be realized and it's potential cost to our project. In other words, it is not enough to make assumptions, we need to understand the risks associated with those assumptions, and have a plan should they prove invalid.

Systematic and thorough validation of our project assumptions is the foundation of good project management.

Traditional project management (by that I mean project management as prescribed by the PMI, documented in the PMBOK, and certified through the PMP) makes one key assumption that no one seems to want to address. We routinely assume that our projects are predictable. We assume that with enough planning, with enough forethought, that we can come up with a strategy that will hold through the life of the project.

While I am certain there are some project domains where this assumption holds true, I am equally certain there are many domains where it does not. As project managers, we owe it to our stakeholders to thoroughly assess the likelihood that this assumption is valid and have a mitigation strategy in place if it is not.

If we operate in an environment where market needs change, requirements change, technologies change, and individual performance can vary exponentially; spending effort trying to create a static project plan is wishful thinking. It is just not good project management. We need a mitigation strategy, we need an alternate approach to deliver our projects in the face of overwhelming uncertainty.

Agile methods give us a way of handling projects when the assumptions about predictability just don’t hold. Agile methods give us a way of delivering the most project value, in the least amount of time, with the least investment possible. Agile methods represent a risk mitigation strategy for when our fundamental assumptions about project management no longer prove valid.

Let's apply good project management technique, validate our assumptions, and work to mitigate our risks. Don't be afraid to challenge the assumptions behind our understanding of PM best practice. The assumptions you fail to consider are the most likely to cause you problems in the end.

Click here for my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/04/assumptions-are.html

Subscribe to this blog

Subscribe to Leading Agile

Scrum Project Management as a Simple Rules Framework

"Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves" - Ken Schwaber and Mike Beedle, Agile Software Development with Scrum

The Scrum methodology is elegant in its simplicity. It teaches us that when processes are not stable, and outcomes cannot be predicted within sufficient tolerance, we cannot use planning techniques that rely on predictability. We must rely on observation. We must adjust the processes as we go and guide them to create our desired outcomes. Using this philosophy as its basis, Scrum is founded on three simple principles: make everything visible, frequently inspect outcomes, and adjust the process as necessary.

People really like simple messages and Scrum delivers in spades. Scrum is easy to communicate and the practices are rather straightforward and easy to implement. You can put a single diagram on a single page and talk someone through pretty much everything you need to know. There is power in the simplicity of the message and that has been a major factor in Scrum's rise as the de facto agile methodology in use today.

The simplicity of Scrum can be deceiving. That simple, straightforward message comes at a cost. Scrum is not all there is to software development and it's not all there is to good project management. If we are fortunate enough to have a group of really great developers, a fully engaged product owner, and a team that can operate with some degree of independence from the rest of the organization; the simple messages of Scrum are a great way to lead a project. The quality of the team allows you to get away with a barely sufficient methodology.

What about when our context is not so simple? What about when we have to develop complex systems architectures or work with a tightly coupled legacy system? What about when we have multiple teams distributed across the globe? What about when our product is an integration of several different products, each with their own product owner? What about when we have to deal with procurement or complex human resource concerns?

Scrum is silent on these issues.

Scrum abstracts these answers behind the team's ability to "devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves". While we are beginning to answer some of these questions, Scrum doesn't really give us much guidance on how to pull it all together. There is clearly more to the story than Scrum is prepared to address.

You know what though? That's okay.

It's okay because Scrum is broad enough to provide simple rules for one set of problems and a framework to handle more complex issues (and incorporate more complex strategies) as our teams need them. The simple rules of visibility, inspection, and adaptation don't break down. They have no geographic boundaries. They don't care about the size of your team or the expertise of your team members. They are about how we are going to control our projects in the face of uncertainty.

Scrum is a barely sufficient, simple rules framework for developing great products. It gives us space to apply our knowledge and skills and the freedom to adapt to our surroundings. We just need to be aware of what Scrum leaves out and be prepared to fill in the blanks. That said, I would rather be given a framework for adaptation than a heavyweight methodology. Very seldom in software is there one best way to do everything. Our processes should not assume otherwise.

 Subscribe to this blog

Subscribe to Leading Agile

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