In some recent blog posts I have discussed developing a process for small app development outside of the IT area as well as applying software development techniques to financial modeling. I have also covered a little about the process used, providing some additional context on the mini- assessment as well as the delivery mechanism (process authoring and management tool). Today I wanted to share some thoughts about “method content”, the actual pieces of the process that are the methodology.
Most of the focus I have working with clients over the past few years is how to adopt agile development techniques that can scale up for large organizations that still require a certain level of ceremony, documentation, and control objectives that must be complied with. The Rational Unified Process, “RUP”, has been a leading commercially available process framework for more than a decade; however, over the years there has been more and more stuff that has been added making the available content very robust. While getting a lot for the considerable money spent to buy RUP is good, the downside is that it has become increasing difficult for organizations to adopt RUP without way too much “process” coming along for the ride and spoiling the potential return on investment.
This is not necessarily RUP’s fault, if you adopt RUP with a well thought out strategy you can do it in a way that is agile and adds tremendous value to an organization, but the inevitable results far too often are too much process overhead and lack luster results in project execution. So what to do?
RUP as well as the open source version OpenUP (see www.eclipse.org/epf/generla/OpenUP.pdf) have a wealth of method content that can be used to pick and choose from to publish a process that will meet the needs of your organization and enable agile development techniques. OpenUP has far less content than RUP has, but that is not necessarily a bad place to start. Just like picking a process management tool such as RMC or the Eclipse Process Framework Composer (see www.upmentors.com/146-Using-a-Process-Management-Tool), selecting a process library to start with that is small and manageable and can be added to in the areas that will have an impact for your specific needs is actually a great place to start. If you are in a large organization, the content that is freely available in OpenUP will most likely need to be supplemented, but often not right away. Using the “Practices” that come with OpenUP (smallest pieces of a methodology that can stand on their own and still provide measureable value to a project team) can usually hit the key pain points of most organizations. From that starting point, I often add in domain/organization specific aspects that come from existing policies, procedures, and standards. After that, the additional wealth of information that is available with RUP can be used effectively.
Practices are a very powerful process adoption component; they enable project teams to adopt a part of the entire process in a more manageable way, one or more pieces at a time. They also enable selection of the pieces of the process that can immediately be put into an adoption strategy, which solves the highest ranked pain-points at a rate of organizational change that is more practical.
I will continue the discussion of practices in my next post, as they are the corner stone of the adoption strategy we most often see meaningful results with and there is quite a lot of well packaged agile techniques content that is ready and free to use.
Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.