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 program that he has benefited from for several years. 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.
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 (www.eclipse.org/epf). Published templates and guidance are freely available for download. I welcome your feedback and questions at Mark@UPMentors.com
 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 (http://www.scrum.org/faq/certification-and-assessments/why-isnt-scrumorg-offering-certifications.html) . Also see Ambler’s http://www.ambysoft.com/certification/scam.html
 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.