Agile Development Blog

This post continues on our series of questions and answers from the webinar Dave West from Forrester and I did on Scaling Agility with Lean: Proven Methods of Operational Efficiency.

At Rally, we often get questions about how Agile fits in with a variety of other practices and processes, so the below questions about Agile and CMMI, Agile and RUP, and Agile and Architecture come as no surprise. Stay tuned for the final Q&A on Agile champions.

DW – is Dave West from Forrester

RAM – is Ryan Martens from Rally

How can Agile be integrated in a CMMI certified application in regards to the tremendous amounts of required CMMI artifacts (documentation)?

DW – The flippant answer is it can’t. ☺  But actually I have seen some great systems integrators use CMMI to help check list their processes of which some of those processes are Agile.  Agile development works really well at the team level, but it needs to be surrounded with other processes. CMMI makes sure you remember those processes, some of which are inside the Agile team, others are not.  The PA’s always seem to imply lots of documentation, but they do not have.  You can keep the documentation to a minimum, but still deliver them.  Do not, however, burden the Agile team with proving their compliance – Use the checklist, build the software and get others to prove they did what they said they did.

RAM – I am not quite as negative as Dave on this topic. CMMI and Agile combine just fine. There are a number of proof points that are easily found from past Agile conferences and by searching “Agile and CMMI.”  The problem is that many folk misinterpret CMMI and are convinced that it mandates waterfall, heavy process and heavy documentation.  According to SEI, it does not.  Most teams would not adopt CMMI without a specific business need.

Can you speak about the friction point wrt to the Architecture? Does this  have to do with in-house expertise?

DW – Classical architectural techniques require everything to be understood, all requirements and constraints to be found and then go through a very complete process to define, describe and implement architecture.  There are lots of pictures, presentations and documents. Agile approaches demonstrate progress through working code.  They continually re-factor the architecture in the context of the problem needs and do not spend ages up front building out a perfect plan to execute within.

Both approaches have merit, but either to an extreme can be problematic.  So the key word is balance.  Putting in place a workable architecture that is skinny enough to allow teams to delivery quickly is key.  This ensures that you can scale development and manage change better.

RAM – Architecture needs to lead development and as projects get larger, it become more of an issue.  Dean Leffingwell and I have written on this topic on his blog. There are many approaches to balancing the needs.  Don’t let this concern stop your adoption; there are groups of 1000′s of developers doing Agile with incremental architecture approaches.

Specific question for Dave West – How similar is RUP and Agile? For a RUP expert, what does it take to migrate to Agile methodology?

DW – Ha, interesting question. When RUP was developed, Agile methods were not really defined as Agile methods.  RUP is iterative, which is a key tenet of Agile.  It also provides a great lifecycle to Agile projects.  What is missing is the team parts – How you organize work, manage its delivery, work with the business and report on progress. By adding Scrum to a RUP lifecycle you add a strong team approach to the overall lifecycle of RUP and the  good engineering practices offered by RUP.  The current methods team at Rational are doing that very thing.  Taking RUP apart and creating practices which allows for that type of approach.

RAM – Numerous Rally customers use a RUP lifecycle with Scrum project management.  In very large organizations this is a common configuration.

How do you provide some foresight information in release planning, say 6 – 9 months?  This is important to us in our product development.

DW – Release planning is crucial for any projects, Agile not withstanding.  Planning the release from the initial estimates is important, but should be done at a high level.  By focusing on a high level understanding of the release it is then possible to validate that after each iteration has executed (and actually as soon as they have planned).  This increases your fidelity concerning the quality of plan for the release.  Tools can really help here in terms of managing that feedback.

RAM – See Dave’s answer in the last Q&A blog post around the topic of the  “Cone of Uncertainty.”  Your 1, 3, 6 and 9 months answers should have ever decreasing levels of uncertainty.  At Rally, we publicly commit to our next release, internally commit to 50% of the following release and 25% of the third release.  We update this every time we release plan.

The next (and final) post from our Lean webinar Q&A will cover championing Agile development.