Agile Zone is brought to you in partnership with:

Mark has been building software for over 20 years and has served in a variety of roles, such as Enterprise Architect, Director of Software Development and Partner of a large IT Services firm. He is a frequent speaker at international conferences, published author, and is a technical reviewer of book manuscripts for Pearson Education and IBM Press. Mark is also Canada's representative on IBM's worldwide Client Advisory Group for Methods. Mark teaches courses for UPMentors and IBM across North America on subjects relating to all aspects of the SDLC including Project Management, Requirements, Architecture, and Agile software development. Mark is a DZone MVB and is not an employee of DZone and has posted 4 posts at DZone. View Full User Profile

Agile development grows UP

  • submit to reddit
“The Agile community likes to think that they represent God’s answer to good software development.  NO!!  You are acting like children and making fools of us all!!” - Scott Ambler, IBM Rational Software Conference 2009

I have followed Scott for years, but I still seek opportunities to hear him speak because he always has a few new gems in his talks.  Scott is IBM’s global Practice Lead for Agile Methods, and likes to remind us that most organizations have to deal with realities that the Agile fanatics seem to trivialize or ignore completely. 


  • Many of us don’t have the benefit of co-location, where the entire team works in close proximity (ideally in the same room), with the user representative present at all times to answer questions
  • Pair programming i.e. 2 programmers sharing 1 keyboard is an expenditure most management will not endorse
  • Delivering a system without moderately detailed requirements (beyond User Stories) is not acceptable for testing, writing training materials, and production support purposes.
  • Fixing architecture as you go (i.e. refactoring) without some initial architectural design is not appropriate for large-scale enterprise systems
  • Most projects are not completely independent and cannot be built in isolation.  Dependencies and integrations with other systems are required and require some co-ordination.
  • Organizations usually have some governance practices in place (such as PMOs, ISO, CMMI) that necessitate a level of bureaucracy and documentation
  • Deploying software to users every 1 or 2 weeks is usually not practical in most organizations.  Just migrating software through development, test, system test, user acceptance, production environments is a major undertaking.  Having many projects trying to do this in parallel on a weekly basis simply isn’t feasible.   

OpenUP - A full lifecycle agile methodology 

OpenUP is the freely available open-sourced version of the IBM Rational Unified Process.  It is an agile kernel of process that includes guidance for all aspects of the software development lifecycle.  It is however, by design, a lightweight process.

What makes OpenUP (as well as other Unified Process variants such as the IBM Rational Unified Process (RUP)) different from other iterative agile methods is some common sense improvements such as:

  • Understanding that not every iteration is the same, and thus deserves specific emphasis depending on the business milestones that we are trying to achieve.  For this, the Unified Process breaks a project up into 4 distinct Phases, after which the iterations are named.  In this way, stakeholders can know how the project is progressing.  An iteration name of E2 conveys to a stakeholder that the project is in the 2nd iteration of the Elaboration phase.  This means that the team is maniacally focused on reducing risks by elaborating the requirements and architecture of the application (by building software to validate the architecture).  Other agile methodologies simply number their iterations sequentially.  Being in iteration 4 tells me nothing about the progress of the project towards completion of its initial vision.
  • Understanding that architecture is not trivial.   Software architecture encompasses key decisions about the structure of a software system.  Well designed architecture allows us to deliver our functionality against non-functional requirements such as performance and scalability.  Poor architecture, discovered late in a project is not a “refactoring” fix.  Rather, it is usually a “do-over”.  The Unified Process acknowledges that we had better test that we can meet our non-functional requirements in the early iterations of the project before we write thousands of lines of code against a flawed architecture.  Grouping our early iterations into an “Elaboration” Phase communicates to our team and stakeholders that we are focused towards this goal.
  • Most agile methodologies have poor lifecycle coverage.  For instance, Scrum contains some good guidance for Project Management, but is silent on Architecture practices.  Extreme Programming (aka XP) has some interesting ideas about coding and testing, but is weak in the area of Project Management.  Grady Booch (an IBM Fellow and thought leader on Architecture) told me that he recently received a call from Kent Beck (thought leader on XP) wishing to discuss architecture.  Grady looked like the cat that swallowed the canary.  Seems other methodologists are realizing that architecture and things like requirements are actually important!
  • The Agile community is fractured and has been subject to considerable disputes and infighting.  As I write this, it has just come to light that Ken Schwaber (the force behind Scrum) has resigned from the Scrum Alliance and has renounced the Scrum Certification[1] program that he has benefited from for several  years.[2]  As a result, the Scrum community is in considerable disarray, without its leader.  My business partner (Julian Holmes) and I have recently been doing a talk called Process Wars, where we point out that fighting over whose methodology is best is a juvenile sport.  Why throw out your process for the latest fad just because a few interesting and sexy practices (as well as terminology such as “sprint”) have emerged that are not described in your current process?  Much better to stick with your current process, and replace or inject specific   “practices” (such as test-driven development) into your current lifecycle.[3] 

Agile Needs to Grow UP!

Bickering over terminology and this idea that “mine is better than yours” is juvenile.  We should all have realized by now that process must be adaptable to the situation for an organization and project.  This means that project management is not prescriptive but rather requires thinking.  Modern Project management is better described as project “leadership”.  Effective project teams are highly motivated and collaborative.  The days of “command and control” styles of project management are long gone.  An effective project manager facilitates, enables, and gets out of the way.  They are also masters at navigating the unique culture and bureaucracy of their organization.

If you are interested in incrementally improving and evolving your software development process, and swapping new practices for old without ditching your current process, I encourage you to consider using one of the base agile processes (eg. OpenUP, Scrum, DSDM, XP) that are available from the Eclipse Process Framework (  Published templates and guidance are freely available for download.  I welcome your feedback and questions at


[1] For a parody on inventing new methodologies around sports metaphors see

[2] Many people are surprised to find out that Scrum trainers do not train from the same set of slides.  Trainers must provide their own training materials, which are not subject to reviews for consistency.  Not surprisingly, many people are questioning the credibility and value of the certification program, including Ken Schwaber himself ( .  Also see Ambler’s

[3] For those of you that ARE comfortable changing your methodology to the latest-and-greatest every few years, we consultants thank you for the opportunity to come and teach you new terminology for techniques that have essentially not changed materially in 30 years.

Published at DZone with permission of Mark Lines, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Michael Dubakov replied on Wed, 2010/02/17 - 5:03pm

Here is my reaction to this advertisement.

Petri Heiramo replied on Thu, 2010/02/18 - 4:12pm

Mark, you seem quite prejudiced about "Agile community". What you describe as "realities Agile fanatics trivialize" are misunderstandings about Agility. Michael, in his previous comment, went through many of the issues and responded to them as I would have. Agile project do take these things into account, even though they are typically viewed as "impediments" or "organizational dysfunctions". I would expect any sensible Agile project to try to work to change such dysfunctions, if possible, or to modify operations in a way that the dysfunction can be circumvented/mitigated. It is no-one's benefit to inflame such conflicts, but a constructive dialogue may change things over time.

Also, things you present as "common sense improvements" in AgileUP are common sense also in any sensible Scrum or XP project (the iteration notation probably isn't, and it does have merit as an idea for communication to management). Scrum is purposefully silent about architecture because it expects you to fill in that area based on the needs of your system or context (and whole notion of architecture is moot if you use Scrum e.g. for managing the development of a weekly magazine). You can use the ideas from AgileUP if you like, or wherever.

As to the comment regarding the current situation between Ken Schwaber and Scrum Alliance, and how "mine is better than yours" is a juvenile sport in your opinion, do you not see how you are doing it yourself? :) (and I think I'm drawn into it a bit, too)

However, I agree with your closing statements, excepting your seeming acceptance of existing organizational cultures and bureaucracy. Agile projects do need to review where they are, where they would want to go (in process sense), what kinds of obstacles there are on the way, and how they could navigate towards the desired state without sacrificing themselves in the process (i.e. use common sense over zealotry). Unfortunately, there are organizations which will inhibit and devour such initiatives, but let us hope that their numbers slowly reduce as more true awareness of Agility penetrates the business organizations.

PS. Is this an advertisement site, since this is clearly an advertisement-type of post?

Franz Allan See replied on Thu, 2010/02/18 - 8:51pm

Are you talking about Agile, or just Scrum & XP? 

Are you talking about just Scrum & XP, or just Scrum & XP in a specific context?

I would suggest you review what Agile is all about again instead of basing your claims on a subset of subsets.

This That replied on Mon, 2010/02/22 - 7:07am

This was one of the oddest advertisements I've seen yet. First lining up a pack of strawmens that mostly have to do with XP and not Agile and then introducing the sales pitch, namely RUP. That's a twist...

Since I have worked at IBM I know well that their methods have absolutely nothing to do with "lightweight"and "agile kernel".

The core features of Agile practices are:
- Automation
- Testing
- Close team interaction 

Most of the fluff in this article has to do with completely different things and the arguments are frankly not even worth discussing since they are mostly off topic.

This That replied on Mon, 2010/02/22 - 7:08am in response to: Franz Allan See

"I would suggest you review what Agile is all about again instead of basing your claims on a subset of subsets."

I second that.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.