This year has seen the continued increase in adoption rate of agile development techniques in our industry. In my experience, teams that have used agile practices on their projects has said “they would never go back” to previous plan-driven and overly ceremonious processes. Software development has never been more interesting for those of us who enjoy the dynamic and collaborate approaches that agile advocates. When I was a developer working on waterfall projects years ago, I swore that I would never be a project manager. I had no interest in pursuing that career path, no matter how much it paid. It seemed that PMs were always miserable. Their days were spent running status meetings, hiring and firing, performance reviews, arguing with users on scope issues, writing up change requests, and updating elaborate project plans in Microsoft Project. Boring! These days, running agile iterative projects is so much more fun, and I love project management. I coach PMs to “get out from behind the desk” and work with their teams. Project Management is better termed “project leadership” as we are not directing teams and assigning team members tasks in a command and control style. Rather, we are more like a conductor of an orchestra, guiding the team as they collectively work with the goal of delivering shippable, working software at the end of each iteration.

Project Leadership on agile project is more challenging than Project Management on waterfall projects. As a PM on a waterfall project, I only have to worry about one discipline at a time. For instance, I may be in a 3 month requirements definition phase of the project. All we do every day is write requirements. Boring, but easy to manage. Then, when the requirements are signed off, we spend a few months doing analysis specifications (whatever they are), and so on. While it is easy to manage these projects, it is difficult to be actually successful. The risks related to deferring critical aspects of the project such as testing, integration and customer feedback inevitably result in grief later on.

Despite a large body of empirical evidence to suggest that large scale, plan-driven, waterfall projects do not work, many if not most organizations still fund and manage their projects in a waterfall fashion. There is still huge resistance at the management levels to abandon large scale plan-driven projects. Project Management Offices tend to treat software development projects like any other project and demand detailed plans and estimates.

Recent ideas from the agile camp such as “Lean Thinking” offer some very interesting ideas for delivering value to stakeholders much quicker and more frequently than other approaches. Years ago I wrote about breaking large projects in corporate environments into smaller projects and treating them like regular releases. See the article “Effective governance practices for Iteration Software Development” for more information on this approach. I have helped companies adopt this approach and the effects have been dramatic.

I believe that 2010 will be another year of increased adoption rates of agile practices. However, until management has the courage to apply some of these techniques on their projects, there will always be friction between management and those practitioners that understand the flawed approaches of plan-driven development and wish to adopt these wonderful agile ideas.

My satire on branded methodologies was just published in the Agile Journal.

Good fun.  

Check it out here:   Play Ball!® – The new and improved Agile software development methodology 

The whole process of assessing the current state was a very healthy activity for the organization. There were many people at both the practitioner level as well as management level that knew there was room for improvement and areas that needed immediate remediation. There were also people that initially were reluctant to believe that anything at all needed to be changed and everything was "just fine". In the final management discussions where all of the findings and supporting evidence was presented, no one could contest that changes had to be made.

The analysis and resulting recommendations were used to create a business case for change and an action plan which included creating a common process framework so that the organization would have a methodology that can support their varying development types with consistency and efficiency by leveraging common process practices and method content where possible. We will be using the Eclipse Process Framework Composer (EPF Composer) and as much OpenUP method content to supplement all of the existing policies and procedures.

What happens when the plug is pulled too soon on an initiative's budget?

Process implementation, process improvement, and process reengineering initiatives are no different than other types of project work when it comes to cutting budget. These types of initiatives typically span multiple years in larger organizations due to the sheer size of the target adoption population which can be from a thousand IT professionals to many thousands. So what happens when the budget for the initiative is reduced or cut too soon? Same as any other type of project work, the results and return on investment will come up lacking at best, will begin to steeply degrade at a medium, and at worst the organization is worse off than where the baseline starting point was, after tremendous time, effort, and money have been consumed.

The strategies we employ with our clients when adopting new and better process solutions or when we are helping to turn around an existing UP/Agile based solution adoption; we always have a vision of self sufficiency incorporated where we are training and mentoring the internal resources that will take over the roles and responsibilities that we engage in. This particular aspect sometimes gets eliminated by organizational management once initial adoption measurements show favorable results. External support can be reduced to quickly and the targeted internal resources have not gained sufficient experience in the role or training and mentor and sometimes not even in the role of a lead practitioner.

This often has significant negative ramifications to the initiative; it is amazing how progress that may have taken 12-18 months can be reduced so quickly. An analogy I like to draw is a group of people that encompasses the adoption team of external training/ mentors along with the internal mentors in training combined with all the other supporting roles plus all the project team practitioners that are valiantly trying their best to adopt this new process all pushing a heavy boulder up a hill. Just before reaching the crest where the momentum will begin to help continue rolling the boulder, some of the needed help to get it over the crest is removed.

What typically happens next is the forward progress of rolling the boulder is slowed, then comes to a brief stop, and ultimately begins to roll back towards the starting point. There are undoubtedly project practitioners along the way that gained enough experience and exposure to continue to use the new methods in their work, but as an organization, the ROI has generally peaked and begins a downward trend.
The new process begins to take on a negative connotation and the bandwidth of the remaining adoption team members is beyond an adequate level to provide minimum quality. On top of that, the fact that their level of expertise necessary for supporting the continuing project teams that are still on the adoption path is too low, and you can see where this is going, all the good work begins to unravel and finger-pointing starts to rule the day...

I am in Hyderabad, India, for the second time this year, teaching a group of very talented locals. Their task will be to teach the same content as I am re-visiting with them this week. Teach-the-teacher, I suppose.

Well, I mentioned RINO to the group today (RUP-In-Name-Only if you didn't already know) and after a bit of an explanation most of them recognised the unpleasant "beast". 

In fact, they got so interested in how RINO can be "hunted-down" that, after a 30-minute diversion from the course, I am now in-demand to repeat the "Hunting RINO to Extinction" presentation from the IBM Rational Software Conference of last week in London.

Unfortunately I will be without my presenting partner Arun "Zach" Zachariah, for this audience at Capgemini's University event,  but I am sure that the messages and the gags will still come across. ;-)

Julian

We at UPMentors are big fans of Agile.  However, unfortunately some interpretations of agile practices leave much to be desired.  While agile was never meant to be undisciplined, some practitioners have used agile as an excuse to take unauthorized and ill-advised shortcuts in process.  

Additionally, the agile movement is without a central voice and infighting amongst methodology camps is threatening to destroy the progress we have made in our industry resulting from some great ideas from the agile community.

I have written a short article to describe how the freely available agile method known as OpenUP allows you to grow your process incrementally as required via plug 'n play "Practices".

There is no perfect agile process for everyone.  However you should be able to "cherry pick" practices that make sense for your organization and project. They should be built upon a solid, full life cycle agile kernel such as Scrum.  However, we believe that a better foundation is OpenUP, which has a focus on progress through four business phase milestones, as well as  on risk reduction and architecture.  

Check out the article, or click here... 

Yet again I have found that my clients are referring to an article that I wrote with Joshua, Mark and Scott Ambler for IBM developerWorks in early 2008.

Agile RUP - Experiences from the trenches was written in response to what we saw as a "knee-jerk" reaction away from RUP toward a nirvana of Agile approaches that seemed to suggest that RUP was no longer a  suitable approach.

More recently, there has been a lot of talk about the relevance of mature software practices being used in the context of an Agile approach. See the latest writings of Ken Schwaber on his new Scrum.org site.

So perhaps our article was "on the button" over 18-months ago, and that Agile RUP was a suitable reality for many organisations. I know that my clients agree, so perhaps more people should be thinking about the value of an aligned RUP and Agile approach.

After all, and I am sure you have heard it said before, "RUP-done-right was always Agile, and that RUP-done-wrong was always wrong."

So, Scott joined me on Monday to help visit a client and to participate in my UK Rational User Group (RUG) meeting.  Both were challenges, for different reasons, but I think we got the right messages across...