August 2005 - Posts

Victoria .NET UG VSTS Topics Anyone?
05 August 05 06:52 PM | Joel Semeniuk | 4 comment(s)

I’m going to be in beautiful Victoria (BC) to present at the .NET UG on October 4th to talk on Team System on behalf of INETA.  Of course, I could present on something pre-canned but that would be boring… If you are planning to attend, why don’t you send me your feedback on what topics you would like to discuss and we can customize the session to exactly what you would like to see.  I can drill as deep as you want to go on any topic…so go nuts.

Post back to this blog entry with ideas and suggestions – go ahead – get specific – don’t be shy… Hope to see you there!

Documentation <> Process
02 August 05 01:18 AM | Joel Semeniuk | with no comments

There have been some interesting comments about my last blog post on CMMI so I thought I would do a follow-up post to put more of my interpretation on these.

One of the biggest criticisms around CMMI is that it is considered as a heavy weight process.  Actually, it’s not really a process that you can follow like a map and isn’t comparable to something like RUP.   In fact, you can use RUP to achieve certain levels of CMMI.  You can use MSF 4.0 to achieve CMMI levels as well.  CMMI is not a process declaration – it’s more like rules that suggest what the process should address.

What I hear continually is how people think that CMMI is there to burden the developer – make their lives less enjoyable, less creative.  Actually, CMMI has more to do with the business.  In fact, almost all developers, except for the hobbyist (in all of their forms) develop software to meet some business need.  CMMI is intended to help a business be more effective through improved quality and reliability of its operations.  Um, that’s good right?  The problem is that an increasing number of businesses are not undertaking the risk of developing their own software because of the risk it poses.  Businesses like to have repeatable and predictable risks and in many cases, software development just hasn’t demonstrated itself to be safe, regardless of the methodology or amount of documentation produced.

Another criticism is that CMMI just means more documentation.  This isn’t really true either.  In many cases, all CMMI is suggesting is to track stuff.  Track it in a document?  Sure – however, I absolutely HATE document based artifacts – and think they should not be used except for high level charters and vision scopes – things that people need to sign, and even then I would prefer to generate them from a more raw data form.  I like simple lists – something easy to create and more importantly, easy to consume (Law of Consumption of Artifacts) – and I can’t see anywhere in CMMI that suggests that lists don’t accomplish the same goals.  Take for example the CMMI Engineering Requirements Development and Requirements Management Process areas…no where does it say that we have to create lengthy documents – all it says is to develop product requirements.  If you can do that with a user sitting right next to you – go to it!!  You’ll likely write some stuff down somewhere even though the user is continually involved… so, write the requirements down in some sort of list that you can use as a developer to better track what you need to get done and when you should probably do it.  Sticky notes? - that’ll work too.  Let’s think about the Project Management process areas – as most projects need some high level logistics and control.  One of the practices is to manage risk and to monitor the project against “a” plan.  Even Agile development has some level of a plan (it might not be overly specific, but it’s a plan) – and it doesn’t need to be in a thick document.  CMMI doesn’t tell you to write more documentation or to follow certain templates.  It may be thought of in that way because many CMMI practitioners have implemented CMMI improvement strategies that focus on document driven processes that help to govern and control process (“When this document is done, go to step 2”).  In fact, CMMI SCAMPI Distilled (a book I accidentally read once) suggests that as 400 document types and 1000 artifacts are required to facilitate an appraisal.  GOOD LORD – that’s a whole lot of documents.  We should not confuse the collecting and tracking of valuable information (and the information that can be further interpreted from it) with the creation of documents.  Ultimately, we need to track information – the manner in which we persist this information should best suite your organization based on how that information will be consumed – and documents rarely fit the bill.  To meet levels of CMMI a company only needs to demonstrate that goals are being met not that certain documents are being filled out.

When my teams start using lists to manage work that needs to get done, ultimately moving away from document based artifacts, we’re still achieving much higher levels of maturity according to CMMI while maintaining a fair amount of agility.  We stress working software over documentation, stress continual customer involvement, stress continual builds, focusing on high customer satisfaction, welcome changing requirements (but that doesn’t mean we don’t track the changes), stress the interaction between business and developers, keep things simple, and more importantly make sure that the team continually works together to see how they can become even more effective.  In fact, if you look at CMMI level 5 it states “Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements.”

The most important aspect of CMMI is the continual process improvement aspect of it.  It will force you to look at your processes and say “Yeah… that didn’t work, let’s try something new” instead of, like many organizations, simply keep on running off that cliff like those poor little lemmings.  If you find you are doing too much documentation and that you or your customers aren’t finding value in this – CMMI promotes you to change to help ensure the highest degree of value flowing through and out of your team.  That’s what gets my ticker going.  CMMI stresses gradual maturity – it is very difficult to simply pop into existence at a particular level and most organizations will want to gradually improve their process areas, depending on their needs, over time and in a way that conforms to the corporate culture around change.

Glen Alleman has a good insight into this.  David Anderson also has a fantastic presentation that you NEED to read from beginning to end.  Stephen Swoyer has a fantastic article on this as well.

Why I Like CMMI
01 August 05 12:52 PM | Joel Semeniuk | with no comments

I continually work with customers to help them achieve greater success with their software engineering processes.  Generally speaking, I come across a large number of fairly large and successful organizations who rely on technology for their business yet maintain an extremely low success rate with their IT projects.  What makes a project successful?  To some organizations simply finishing a project that they start is considered successful – nothing like keeping that achievement bar right up there.   In my humble opinion a project needs to be on-time, on-budget, and more importantly on-function.  If your projects are on-budget and on-time yet lack the business valued functionality that you planned on providing – are you successful?  My opinion is that you are not. 

 

There are many different types of companies and thus, many styles of software engineering.  For example, a company that develops off-the-shelf software will likely develop software differently than an insurance company wishing to implement a new claims solution across their offices with their in-house developers.  I could go on and on here as I can classify at least 4 distinctly different types of situations where software is developed, yet one thing I’ve learned over the years is that despite these differences, there is still a great deal of common problems in the way many organizations develop software, and thus, common solutions to those problems.

 

One of the first things that I do with customers is to try to get them to think outside of the day to day project mindset.  Think about software engineering as it exists across and between projects – take a holistic view of how they develop software and achieve a perspective of what truly drives them.  Very commonly I find that the processes and techniques that surround gathering, analyzing, and representing requirements to be a stumbling block.  This isn’t news to a lot of people and this recognition is a driving force behind many of the agile methodologies which put a great deal of emphasis on the continual interaction with users to ensure that the requirements are correctly communicated.  Generally speaking, I’m a big fan of agile based methodologies; however, I’m also a fan a bit of formality and ceremony.

 

What does this have to do with CMMI?  Well, I’ve been a silent fan of CMMI for a while, employing much of its patterns and guidance in my consulting practices.  Why silent?  Well, it seemed that every time I would bring up CMMI to other developers or organizations I would get bombarded with comments like “CMMI?  Bla – that’s only for extremely large organizations who want to waste their money” or “CMMI – that will bloat the software construction process and is totally against agile methodologies.”  Additionally, I typically get a great deal of negative feedback from developers because the discipline that CMMI was thought to impose would restrict the intellectual freedom of the developer (I tend to go off on tangents on this topic because discipline and freedom are not opposing forces – the greatest artists (music, art, dance, etc) the world has ever seen got that way through vigor and discipline – yet many developers seem to feel they fit outside of this paradigm). 

 

Back to CMMI – I like it because its not just best practices –they are also goals.  We have goals in everything else we do – our career, our businesses, our family – why can’t we have goals, and practices that help us achieve those goals, in the way we develop software.  Another reason I like CMMI is because it re-enforces my claim to separate your software engineering practices into perspectives – and to have one of those perspectives span all projects and deal with the ongoing process of improving all areas of your engineering practices.

 

I’ve always believed that CMMI does nothing to hinder the agile development team.  CMMI is not specific and is enhanced with good management tools (Microsoft Visual Studio Team System stands out here).  CMMI may not be for everyone, but for me it provides a “design pattern”, if you will, of process improvement that can be taken and interpreted for different organizations, depending on their specific needs.  On that note, many organizations do not require CMMI certification – that is having all of their software processes at a particular level (staged).  In fact, I’m a much bigger fan of the continual model where the needs of the project or organization (because they are distinctly different) drive the maturity needs for different areas within CMMI.

 

It’s my belief that we are going to see a revelation of sorts regarding software engineering – moving from ad hoc disconnected processes to one that is more disciplined (yet agile).  In fact, software engineering can’t even be considered an engineering practice until we see a more professional and disciplined approach to its definition and its construction and maintenance.  I can also see a split in the future between those who are the “engineers” and those who are closer to trade workers – much like most other industries (eg – Electrical Engineers and Electricians, Automotive Engineers and Mechanics, etc) – both perspectives requiring a great deal of training and education but focused in different areas.

 

Just some random thoughts early on a holiday weekend.