Software Process Improvement Stuff

Software Project Success Factors

2011-03-22T08:58:00.000-04:00

Below are criteria that Capers Jones collected from interviews with internal and external clients:

1. High schedule accuracy
2. High cost accuracy
3. Low defect potentials (< 3 per function point)
4. High defect removal efficiency (> 95%)
5. High levels of operational reliability
6. High transaction volumes and good operational performance
7. High levels of security and immunity from hacking
8. High levels of customer satisfaction based on surveys
9. Ease of learning application
10. Ease of use and intuitive human interfaces
11. Ease of initial installation
12. Eases of installing updates
13. Ease of removal
14. East of access to customer support
15. Rapid response to reported defects

Traditional Development, you say?

2010-06-10T11:43:00.004-04:00

Traditional development. I hear that often. I'm never too sure what people mean when they use these words.

I believe that defining traditional development is personal. In my opinion, traditional development is what most organizations use. For me, it is a continuously changing method that constantly adopts new and (hopefully) proven to-be-effective-in-your-specific-type-of-environment practices (discovered by collaborating with various information sources).

No choices have to be made for adopting radical changes. In contrast with the fights that we often hear about Kanban vs Scrum, or Waterfall vs Agile, etc. Of course, these are public battles which should logically have been internal discussions, since every organization has a different context. And every organization is at a different level of maturity.

An interesting definition of Maturity : (Wikipedia)

...a technology that has been in use for long enough that most of its initial faults and inherent problems have been removed or reduced...

So I think that all methods of software development are good but none will ever be perfect. But then again, judging that one is better than the other is, well, immature.

I was never much of a sports fan and rooting for only one team is not inherent to my nature.

Happy developing!

Happy New Year!!

2010-01-05T16:51:00.000-05:00

I wish everyone a happy and prosperous 2010 !

Let's make this an 'improved' year over 2009.

Yeah!

Developer Segregation

2009-04-13T16:15:00.001-04:00

A natural phenomena that has been occurring for ages among humans is segregation. Why do people still tend to cut themselves off from their own kind is beyond me. As a process improvement specialist, I put all my energy in getting people to work together towards the best interests of the organization. I also enjoy sharing what works and what doesn’t work with my fellow developers from outside of the organization.

An odd behaviour coming from the developers’ world is the need to belong to a gang. Some even call it being part of a community. Similar to a sect, I guess, since in one case there are a bunch of commandments or something. You sorta get this feeling: If you can’t follow these guys, hit the road!

Now, imagine if I created a baseball league in which our guiding philosophy (this term is often used to represent a collection of valued ideas) stated that using a leather glove was valued more than using a synthetic glove. This being stated in a policy, you don’t belong to my community (The Leather folks) unless you value the leather glove more. Even though you might play better in the rain with the synthetic glove.

When Fagan worked on the peer review process, he never mentioned that if you valued these inspections, you are now doing Peer development and therefore belong to the Peer community!

My organization uses many valuable practices including short iterations, working software increments, always validating with customers, effective requirements change management, complete project plans, documented processes, formal inspections, etc.

As you see, this collection of practices doesn’t make us belong to any specific group. Although, we have a project success rate of 100% based on near-perfect customer satisfaction and 100% initial schedule expectations.

The point I’m trying to get at is this: can’t we all be in this together and improve our world without separating us into groups? Just because one of us has a great idea, why do folks have to create a club that states that this idea is their motto? Why not share best practices without assigning them to a single group?

I hope my message is not misunderstood, and that one day software developers can have a manifesto that belongs to everyone…

Oh, stop it! Agile is only a word…

2009-03-04T13:05:00.004-05:00

I am going to write this post while ignoring the possibility that the ‘Agile’ word is only used to sell something.

I often see articles on how to implement CMMI in Agile environments but I still can’t understand why these authors limit their subject matter to so-called ‘Agile’ development. Is it because they don’t know any other development environment? Are these people just beginners that have little experience in a variety of development settings?

Since this fad started, I have become increasingly weary of any business that touts their services as being geared towards ‘Agile’. In an attempt to understand what ‘Agile’ means, I once initiated a discussion in a popular Internet forum on what makes a software development method ‘Agile’. For some reason, I wasn’t surprised that most ‘experts’ in the matter couldn’t describe anything specific. For example, there was mention of short iterations, fast scope changes, etc. To me, these were obvious ‘best practices’ in ANY environment.

And speaking of best practices, not one example of an alternative CMMI practice was ever brought forward to show that ‘Agile’ development was anything other than ‘Regular’ development. Yet so many folks seem to believe that whenever they aren’t capable of exercising a model (CMMI) practice, they should still deserve to be recognized as having fulfilled the maturity level requirements.

So in the end, ‘Agile’ means absolutely nothing and less. Go figure.

This article represents my experience perfectly: Agile-CMMI Wars - We need to talk

GTD - A personal perspective

2009-01-08T14:38:00.005-05:00

I was walking by the desk of a developer in a software development shop last month and saw a poster with a mean looking face and the following text beneath it : The Process is Watching You!

My first thought was: Hum, I think he’s missing the point... But then I came to the conclusion that some people think that there are two ways that organizations get things done:

1. Do it THIS way or else!
and
2. Do it any way you want. Just get it done!

Perceptions have a knack of twisting reality into mush.

Now here is an idea : The process is your friend. YOU own it just as much as the next guy. If it isn't just right, improve it. It is the best tool to ensure that the job gets done in a way that maintains the execution of specific activities and therefore a certain level of quality.

A well-maintained, constantly improved process keeps everyone moving steadily and happily.

Now it’s up to YOU!

Fixed Finish Date Equals Failure ? ... NOT!

2008-12-11T09:53:00.000-05:00

I sometimes read articles that make me wonder what the authors are trying to convey.

This following article is one of those : http://blogs.oreilly.com/missingmanuals/blog/2008/02/lets_make_a_deal.html .

I attempted to respond with a personal opinion and was blocked by a registration process that I could not get to. So here is MY comment on the article:

Dear Bonnie,

I believe that you left out an important piece of information when you state that : 'But an arranged marriage with a finish date is doomed to failure.'

I work for an organization that is in the software development business. We develop tax software. End date dependant projects. If we miss our end date, we close shop. Period.

I believe that managing a project successfully with a fixed finish date is very easy IF you have an efficient requirements management process. Your missing piece of information. Negotiating a requirements management process with a customer is much more rewarding than refusing to work on a project with a fixed end date. This type of project is more common than some think...

I am more than willing to share our process with any interesting parties.

My two cents. Again...

New paper on Agile and CMMI

2008-11-13T09:29:00.000-05:00

Here is a new paper on using the CMMI model within an Agile environment: http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html

It was written with the collaboration of consultants specializing in Agile and some SEI folks.

Back from summer...

2008-08-21T14:33:00.002-04:00

Right. Summer isn't over yet... Of course, I never saw it anyway. Rain, rain, rain...

I'm going to be posting some texts on the upcoming process improvement activities that keep feeding me my learning material. After over 5 years of Level 2 (and bits of level 3) maturity level process improvement work, I am dipping my toes into quantitative management stuff. Not sure where I'm going or how useful this will be, but I'm sure I'll have fun trying to get things together.

My organization has a pretty good metrics collection and lots of data from well structured XML forms on our SharePoint repository, so I have lot's of potentially useful data building to do.

I'll keep posting on that and other subject matter that comes up.

Thanks for listening.

Shopping for a requirements management tool

2008-04-23T12:47:00.001-04:00

Shopping for a requirements management tool is a strange adventure to say the least. The suppliers hold off publicizing their functionalities so that their 'edge' is maintained and trial packages are almost inexistent! .

There are two ways to evaluate the purchase of such a product:

Try to find a tool that fits your existing process, or
Try to find a tool that will help you build your process.

I hate to say it but #2 seems to be the most common approach based on how the vendors present their goods. It is rare that a vendor's practiced approach will include an analysis of what is happening with requirements now to then follow-up with a personalized demo based on the actual environment. Through all of the demonstrations received, this was the case.

Then we decided that in our best interest, we would train the trainers. So once again, I contacted the vendors and described our actual process which happens to be pretty mature, albeit not perfect, which is why we are looking for a tool in the first place. Then I had them prepare a demo using our terminology and acronyms using our requirements process activities.

Bingo! This one hit home. Our team of evaluators (we had a representative from each requirements management activity) felt right at home and were capable of feeling where the advantages of using a tool could be effective.

A strange thought comes to mind when you notice how the less effort spent trying to know your customer usually involves the more expensive products. Ex.: my car dealer spent more time prodding my use of a car before presenting his models.

Conclusion:
When shopping around, be prepared with a scenario to be used for the demos. Keep it identical for all vendors to allow for a qualified evaluation based on the same process steps. Also make sure that you have the list of criteria that are important to the organization and set a value to each item. And let the results guide you in your selection...

What's With Configuration Management?

2008-02-06T19:48:00.001-05:00

CM is a software development subject that people would rather not talk about because they don't seem to understand it sufficiently. I definitely know where they are coming from! It took me ages to stop thinking that CM was all about repositories.

One way that helped me understand it better was to think of it as taking a 'snapshot' of the status of all work products (this includes code) from a project at a specific time. The status is in fact the version of each work product. This is where people (mistakenly) think that CM is only about the tools...

What counts in CM is not ONLY the versioning of a specific work product, but was it an APPROVED version of the work product that was part of the 'snapshot'.

Having said this, the use of a CM tool (TFS, Kovair, MKS, Doors, SourceSafe, Jama, etc...) is important in allowing the management of the different versions of the work products. These tools incorporate features that assist in the change request processes to allow the necessary tracking.

We then send a report (Compile Notes) accompanying each software build, created automatically by the CM tool, that specifies all changes integrated since the last software build. This report lists all bugs, change requests and new requirements (by their unique number assigned by the CM tool) that have been 'approved' for integration.

The control is executed by doing audits on these Compile Notes and comparing their content with an automatically extracted list of the comments included with all items as they are checked-in to the repository. The 'Gatekeeper' (or CM auditor) lifts an immediate flag if a 'stealth' sneaks through, or, if an approved item is missing from the build.

Hopefully, this short text will help some gain some insight on configuration management activities!

Requirements Management

2008-01-22T10:43:00.000-05:00

I have often read that no or little requirements' management is probably the cause for most project failures in software development.

From my point of view, I can say that I have seen requirements management save projects from schedule overruns and keeping project managers away from getting new ulcers... Also, having a controlled change management procedure is at the very heart of it.

In my organization, we have a high level request list which contains all new requests (wishes, change requests to existing requirements and any changes to satisfy environments and technology constraints). These requests may come from internal clients (staff, whether executive or development) or external clients (those who buy our products).

This 'master' list is managed by the CCB (change control board) which includes product management, marketing and development representatives. The requests are evaluated and 'tagged' with a level of priority and criteria for its selected status (why is it rejected or approved).

Once approved, the request is added to the project's requirement document to be elaborated by the business analyst through customer elicitation and validation sessions. In parallel with the analyst's work, the UI Designer gets a prototype approved by the same stakeholders. Then begins the requirements development activities.

Any changes to these work products (use cases, test cases, UI artifacts, etc) are managed by the change request process. Once a change request is recorded, it gets approved based on specific criteria including the impact analysis results.

Every work product gets peer reviewed (inspection) before it gets implemented or used by another process.

The benefits that we have tracked since applying this process include :

Controllable scope (can't call it creep...)
Improved impact analysis due to structured traceability
Lower stress levels from everyone
Much less rework
Etc...

Doing PPQA

2007-12-05T07:20:00.000-05:00

Here is a great intro post from Tom Cagley.

Doing PPQA is the exercise of executing quality assurance activities. Many process improvement methods are very efficient in 'improving the process' but most methods do not include ongoing QA practices. This is sometimes called 'controlling' the process.

PPQA is the 'guarantee' that a process is being followed as documented. It serves the purpose of ensuring process execution consistency by objectively auditing processes and work products. Then, by requesting an 'improvement plan' to the project leader, an action plan is set up to avoid a recurring non-compliance.

Due to the objectivity required to fulfill this task, the QA team should be hierarchally equal to the audited project teams. In other words, the PPQA auditor should not share the same functional manager as the audited project leader.

In my world, the PPQA auditor performs many functions:

He audits the processes and their work products.
He approves the effectiveness of the action plan that should thwart a non-compliance.
He collects any improvement opportunities while auditing.
He coaches developers on new or changed process activities or work products.
He trains staff on processes.
He is a CMMI reference that watches out for the model's compliance requirements.

PPQA audits should be structured for the particular environment that the organization works in. It is important to design the audits to be resource friendly but not sacrificing efficiency.

The first audits that I designed were based on the practices of each implemented CMMI process area. This served two purposes: to maintain process compliance and to assess CMMI compliance. The audit checklists were soon felt as an overwhelming task. Complete, but too effort intensive. These are now used for our yearly SCAMPI-C assessment.

Following our yearly external process assessment, our friendly expert consultant recommended a leaner method. Tom was right. Again. So I began designing an audit procedure that adopted a project risk evaluation in which projects with recent non-compliances received deeper coverage within an audit. As opposed to projects without recent non-compliances to which I applied a very light audit model. There are a few extra attributes used to assess the project risk, but you get the idea...

And last but not least, let's not leave out the essential 'escalation plan' that helps deter delinquency. Every delay causes the issue (the lack of or incomplete improvement plan) to be sent up one level at a time until it gets all the way up to the project sponsor.

This is my fifth year as a PPQA auditor. It is the only role in the whole organization that sees what is going on EVERYWHERE. And I work for the sponsor to ensure (or assure) that the processes continue to be followed as defined in our policies.

In the end, this is all to keep the quality of our processes and work products at their expected levels, so that the sponsor can go about his work knowing that he has eyes out in the field looking out for his interests.

Peer Reviews

2007-10-23T06:08:00.000-04:00

Formal peer reviews (or inspections) can take many shapes and sizes but one of the benefits that cannot be ignored is: major cost savings! Ironically, this is probably the most costly process to implement. Certain types of peer reviews may require a lot of effort to plan, execute and track activities, however, other types may have very little overhead.

Implementing peer reviews on our requirement work products have reduced our rework on designing and coding by 80%. And these numbers don't even include the testing that we don't have to repeat. Since specifications are verified before coding, we now have insight on the causes of the rework and are able to reduce the effort that the reviews require. In the end we get high quality work products.

One must also keep in mind that 'peer' means what works for you in your environment. In some formal peer reviews, the peers include one stakeholder from each impacted development group. For example, for a use case peer review there will be the use case author, a business analyst, a UI designer and a tester (author of the related test case). Each will review based on their interests and the impacts on their work products.

What other types of peer reviews are there, you might ask? As many as there are development teams, I would answer. These must be practiced and shaped to your environment to be effective. At first, buy-in may be very difficult since it 'seems' to add an extra workload on staff. Of course, this is an illusion because so much development rework is avoided in the later lifecycle phases.

In conclusion, the cost savings, the high quality work products and the close collaboration that develops are reasons why development staff become highly attached to peer reviews. In the end, it helps make everyone more comfortable with their individual tasks.

I can't imagine a development team that can't benefit from such an exercise.

Happy reviewing!

The Quality Culture

2007-10-05T15:41:00.000-04:00

A key goal in implementing a process improvement program is seeding an environment geared toward improving their process activities. This is a big step in getting the big OPF PA and all GP 3.2's rolling.

To do this successfully, there are 2 key factors to have on hand: a functional process improvement change request tracking tool and the resources to support ongoing change requests in processes and work products.

When at the beginning of this exercise (and the implementation of a SPI program), PPQA audits are usually the source of the early flows of change requests. Once these have been promptly managed and applied, developers will see the benefits of making change requests and will usually jump right in. This is the result of acting quickly on the change requests to show the developers that the organization is interested in helping them work more efficiently.

We're in year 2 of using our process change request process and with 150 developers, we've received over 300 change requests since being successfully evaluated at CMMI ML2.

I read that to be a healthy quality environment.

Process Focus (OPF)

2007-09-13T06:01:00.000-04:00

Focusing on process improvement is a lot about change requests on existing process activities and work products once processes have been established. The more change requests that we (SEPG) receive, the better we feel the health of our 'quality' culture is.

As this process's champion, the method I established to manage change requests is strikingly similar to the DMAIC method adopted by SixSigma. I designed, with much help from my technically inclined co-worker, an InfoPath form (we call this SPI specification work product a PID for Process Improvement Document) that is used to plan and track the development of our process and work product improvements. Of course, each change request is approved by firstly ensuring that it falls under one of the business objectives' categories. These objectives are clearly defined in the SPI project plan.

The following phases are incorporated into the steps to fulfill each approved process improvement change request:

Define
Our process improvement change request list (we call it our MRL for Master Request List) is where we define the improvements and their potential benefits.

Measure
In the PID, we note the original performance score (this can be based on many elements). We will note the 'new' measure once the pilot is underway.

Analyze
The analysis is performed to decide which solutions are a good fit.

Improve
The change is applied to the process and work product and a pilot is run to get our new performance measure.

Control
Once the change has been piloted and approved by the stakeholders assigned in the Define' phase, training is offered and the change is incorporated into the PAL and into the process area's PPQA audit checklist.

Within this environment, what colour belt do I have?

Supplier Agreement Management

2007-09-12T09:49:00.000-04:00

This process area seems to bring about many questions. Is it applicable? How useful is it if I don't have any control on suppliers? Etc, etc...

I'm writing this text to point out a very common situation that isn't that obvious but may make or break the success of a project. Or of the organization depending on maintaining control over the availability of its source code.

The CMMI-DEV model clearly lists the following goal: Satisfy Supplier Agreements.

The description of the goal's first practice is : Perform activities with the supplier as specified in the supplier agreement.

Here is an excerpt from the GNU Public License which often accompanies components distributed on the web. (http://www.gnu.org/licenses/gpl.html)

You must make sure that they, too, receive or can get the source code.

So imagine a commercial software development organization incorporating a component that contains this license (let's call this the supplier's agreement, 'cause that's what it is).

For this reason (and many others), applying SAM activities such as reviewing and approving components' licenses are extremely critical in software development organizations. Let's not underestimate the importance of this PA.

Does Agile have a downside?

2007-09-10T09:26:00.000-04:00

Everyone wonders what software development method works best in our own environment. You never know for sure unless you try, I like to think. Here is the first article I've read stating the negative side to Agile methods. Personally, I like (and believe in) several aspects of Agile methods such as stand-up meetings, short iterations and the list goes on. I would have different opinions for extreme programming, though, unless the organization is very, very small.

Here's the link : Agile Methods and Other Fairy Tales

Enjoy... Or not.

QA vs QC

2007-09-05T14:34:00.000-04:00

I have a software development pet peeve. I have been involved in Quality Control activities since 1994. I have been involved in Quality Assurance activities since 2003. Why do people still use the acronym QA to represent QC???. It seems clear to me that QA is NOT testing! Why do highly respected people in the software development industry still use QA in their documentation and presentations? This habit has a tendency to confuse people...

Quality Assurance = Activity to prevent defects in processes or work products.
Quality Control = Verification activity on a product to ensure compliance to the requirements.

Clich here for a similiar article.

Back to PPQA

2007-09-04T06:05:00.000-04:00

Quality Assurance audits are back on track. With our goal of ML3, the process improvement project is also in the mire. This will be an action-packed year. The key is to keep the audits effective but not too time-consuming. There is one PPQA auditor and he is not full-time... This will be a challenge.

Error in SharePoint

2007-08-29T15:52:00.000-04:00

I just got this error message in SharePoint (WSS 2.0) : !-- #RENDER FAILED --. I searched the WHOLE Internet without finding a solution. I will now use this blog to share solutions found that involve SharePoint, MS Project Pro and Server and various other common applications that I use.

For this error I had to open the affected library in IE (7 was my version). I then inserted this command in the address bar:

javascript:MSOTlPn_ShowToolPane('2');

I removed the problem web part (click the X in the top right corner) and re-inserted the original from the list of folders and lists.

And Bingo! No more problem.

Waiting for updated project plans

2007-08-27T14:33:00.000-04:00

Following a small structure change, our project (4) plans are going through the review and approval steps. Once this is complete, PPQA will be back on track with the planning and development process audits. Certain PPQA audit procedures will be re-aligned to reflect the new reality. In a few days, all will be back to normal.

Re-doing PPQA schedules

2007-08-24T07:05:00.000-04:00

New structure changes are making me go over the PPQA schedules to re-assign some project tasks to the new development group. Some project tasks (process activities) are changing hands. This will cause a delay in my PPQA audits... and cause change requests in existing processes and work products. This is just another part of the job I love. I expect project plans to be updated by the end of next week...

PPQA audits have begun

2007-08-22T09:08:00.000-04:00

All my PPQA schedules have been created and peer reviewed. I will begin audits today. My schedule is packed wall to wall. My MS Project Web Access view is nicely structured so that I take the first task and work my way down. No scrolling to find the next task to be started. I had to use predecessors and priorities on recurring tasks within the schedule to accomplish an organized task list but it works very nicely. I level 6 schedules (all use the same shared resources) which have both recurring and regular work tasks which are effort driven. The recurring tasks use the fixed end dates of the development project schedules to align audits within the project time frame. To the starting gate!

PPQA Planning

2007-08-17T06:50:00.000-04:00

Just back from vacation and many project plans are in. Now it's time to schedule their PPQA activities. I create one MS Project schedule (I dislike to use the word plan for a project schedule. It just confuses everything) per project plan. I have 6 to build to start the season. About 200 to 300 tasks each, they are fun to make. Next week, I start QA audits on all of them and try to fit in some change requests, too.