Why Agile needs RUP

What are Agile and RUP?
Agile is an umbrella of methodologies that promote frequent inspection and adaptation, cross-functional interactive and iterative team work, self-organization and accountability, and a set of engineering best practices that allow for rapid delivery while aligning development with evolving customer needs and company goals.

RUP (Rational Unified Process) is an waterfall software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is an adaptable process framework, intended to be tailored by the software project teams. Waterfall refers to a process that has discrete phases that are executed in sequence. RUP does explicitly support iteration, but I am getting ahead of myself…

Agile and RUP at the surface represent diametrically opposing software lifecycle philosophies. In a literal sense, the benefits of one are the weaknesses of the other.
As a waterfall methodology, RUP would offer the following advantages:

• Consistent quality
  Releases to production would be of a consistent predetermined quality
  
• Feature prioritization
  Efforts and releases focused on areas of prime business benefit
  
• Clear release scope
  Enhancements and fixes clearly defined in advance
  
• Regular and scheduled releases
  Production releases would occur on a regular basis and scheduled in advance
  
• Risk management
  Areas of risk would be identified in advance, understood, mitigated and managedProject success rates could improve
  
• Reduced costs
  Through better documentation, clearer roles, tasks and structure, it is possible to effectively utilize lower cost staff for areas within the technology organization. Additional costs are saved through reduced errors and rework.
  
• Transparency
  Visibility would be improved into the efforts, costs and resource allocation within the technology organization.

However, the waterfall/RUP methodology advantages accrue with the assumption that the selected project has the following characteristics:

• Large enough
  To benefit from the overhead of documentation/review
  
• Sufficient time
  To allow approvals and sequencing
  
• Known enough
  To be able to precisely define the end-state
  
• Open budget
  When knowing the precise cost is less important than getting the right result
  

Good examples of a fit for Waterfall/RUP would be:
- A core engine that serves many users/customers/systems
- System deliverable that must meet stringent quality/functionality requirements

In contrast, examples of good fit for Agile (and bad fit for waterfall) could be:
- Simple program maintenance
- Database tuning
- User Interface development

These are just examples. What might be a good criteria for selecting a methodology?
Agile fit:
· Low criticality
· Senior developers
· Requirements change very often
· Small number of developers
· Culture that thrives on chaos
· Adaptive Planning
· Responsive to customer guidance

Waterfall fit:
· High criticality
· Junior developers
· Requirements don't change too often
· Large number of developers
· Culture that demands order
· Predictive planning
· Focus on date/scope


Agile needs RUP
For the majority of projects, one need not select from these two polar extremes. A methodology can easily be framed to utilize the best of both worlds. In fact, RUP accommodates “iteration” explicitly. Iteration is loosely defined within RUP/UML precisely to allow adaptation. Iterations can exist in both requirements and in development. They can include gradual increase in functionality, and work within regular release cycles. One can even iterate in cycles between requirements/development. Lastly, iteration is a key tenet in reducing risk. By iterating, one has the opportunity to tackle higher-risk requirements early, learning and adapting from experience. Isn’t that the essence of Agile?

Task Types

There are several flavors of tasks, and the project manager controls the flavor. A project manager ignoring task types does so at his/her peril, as the likely result is frustration and hair-pulling at seemingly inexplicable behavior of MS-Project.

First, let’s state the underlying formula: Duration x Units = Work.

There are three task types:

• Fixed Units
• Fixed Work
• Fixed Duration

Project uses Fixed Units by default.

In general "Fixed Work" is most intuitive and usable for software development efforts.

Note there is no one right task-type, it completely depends on what's being worked on. For the relatively rare generic operational activities, I recommend use of the Fixed Duration task-type. This is for tasks such as a "management overhead task" that gets spread flatly across a plan, or if there's a fixed duration (ie. watching paint dry, or making babies (ie 9 resources do not in a month a baby make)). This is the kind of overhead apply for generic resource across a project. In other words, tasks that are not really task-oriented, are "operational" lights on. If you work more or less on this kind of task, the duration doesn't change.

Each of the task types affects scheduling when you edit one of the three elements as follows:

In conventional thinking, as resources are added to a task, the total work on the task stays the same. However, the amount of work distributed to the resources assigned to the task changes. Effort-driven scheduling only takes effect when resources are added to or removed from a task. Effort-driven calculation rules are not applied when you change work, duration, and units.
When working with effort-driven scheduling, keep the following in mind:

• The effort-driven calculations apply only after the first resources are initially assigned to the task. After the first resources are assigned, the work value doesn't change as new resources are assigned to or removed from the same task.
  
• If the assigned is Fixed Units, assigning additional resources shortens the duration of the task.
  
• If the assigned task type is Fixed Duration, assigning additional resources decreases the individual unit values for resources.
  
• If the assigned task type is Fixed Work, assigning additional resources shortens the duration of the task.
  

We now know what task-type is and how it works. Got questions? let me know, I'm here to help as always.

Welcome!

Project Management can be abstract, theoretical and cerebral. Especially if one spends too much time buried in the industry literature. Real Project Management is from the trenches; hands-on, full-contact, grappling with real-world problems. This blog tackles the tough questions raised in real-world situations, as well as tips and tricks that can bring success and (dare I say) even joy to the most battle-hardened Project Manager.

Welcome to "Project Management from the trenches", where I share tips and tricks on project management.

To get started, I’d like to share some MS-Project and MS-SharePoint related tips and tricks on an ongoing basis. I’ve started to document the detailed answers to questions that are frequently raised by associates.

In terms of my style, I like to show images so people can follow “click by click".

I'll start with topics in MS-Project, which is the tool of choice by project managers. In the hands of the uninitiated, MS-Project can be a source of endless confusion, seemingly frustrating the simplest of efforts. With understanding and insight, it can be a tool of beauty, saving endless time by handling tedious scheduling and providing analytic insights to optimize the efforts of your team.

I welcome questions that I can address. Lastly, I appreciate your time in reading this, because ultimately this blog is for you, my friends and future friends :-)

Joel