What methods exist for assessing an organisation’s development capability? [closed]

I have a bit of a challenge at work at the moment. Presently (and in fact, for some time now), we have been experiencing the following problems with some in-house maintained applications:

Defects (sometimes quite serious) being released into production;
The Customer (that is, the relevant business unit) perpetually changing their minds (or appearing to do so) about what issue to work on next;
A situation where everyone seems to be in a “fire-fighting” mode a lot of the time;
Development staff responding to operational requests from business users; (“operational” here means something that needs to be done in order to continue with business, or perhaps just to make a business user’s life a little less painful, as opposed to fixing a bug in the application, or enhancing the application);

Now I’m sure this doesn’t sound particularly new or surprising to most of the participants on this Q&A site and no prizes for identifying the “usual suspects” when it comes to root causes. My challenge is that I have to persuade the higher-ups to do uncomfortable things in order to address all of this.

The folk I need to persuade come from a mixture of the following two cultures:

Accounting;
IT Infrastructure.

I have therefore opted for a strategy that draws from things with-which folk from such a culture would be most comfortable (at least, in my estimation), namely: numbers and tangibles. Of course modern development practitioners know all too well that this sort of thing isn’t easily solved using an analytical mindset (some would argue that that mindset is, in fact, entirely inappropriate). Never-the-less, this is the dichotomy with-which I am faced, so that’s the stake that I’ve put in the ground.

I would like to be able to do research and use the outputs to present findings in the form of metrics and measures. I am finding it quite difficult, though, to find an agreed-upon methodology and set of templates for assessing an organisations development capability–the only thing that seems applicable is the Software Engineering Institute’s Capability Maturity Model. The latter, however, seems dated and even then rather vague.

So, the question is: How do I go about assessing our organisation’s software engineering capability such that I can present the findings in a way that is concrete and references a generally accepted industry standard?

UPDATE:

Doing a little more research, I came across this little oasis – a CMMI FAQ worded in laymans terms–just the sort of useful resource that one needs in this area … and free.

Like my answer, most things are vague on the subject. No one can determine for you that 10 bugs are worse than 1.

Not sure about any particular methodology, but you should start with your client first whether they are external or internal. What are the problems they see with the system. Sorry, but this post sounds a little too much on how to make the developer’s life better. There needs to be some conversations that lead to a better understanding by both parties.

To show you what I mean, I’m going to play Devil’s Advocate and take the perspective of your client and show you why these are not problems to them.

•Defects (sometimes quite serious) being released into production;

You “said” it would be ready in 2-weeks so that’s what we planned for. If you needed more time, why didn’t you say so? Don’t you have tests?

•The Customer (that is, the relevant business unit) perpetually
changing their minds (or appearing to do so) about what issue to work
on next;

That’s just the way business is. We can’t predict these things. Some of the requests come from external agencies (government tax law), vendors, clients or upper-management, so there is nothing we can do about it. The earth isn’t going to stop spinning just because we’re not ready for quarter end. Aren’t you guys agile?

•A situation where everyone seems to be in a “fire-fighting” mode a
lot of the time;

We’re the same way; nothing you can do about it. Things are out of our control just like the previous problem.

•Development staff responding to operational requests from business
users; (“operational” here means something that needs to be done in
order to continue with business, or perhaps just to make a business
user’s life a little less painful, as opposed to fixing a bug in the
application, or enhancing the application);

We would love to be able to do these things on our own because development takes too much time and complains about EVERY SINGLE REQUEST we make. Build something that gives us this capability, but you don’t trust us to do it. You can’t take control, but also not want to do it. Can’t have it both ways.

Strive for Balance. It’s difficult to weigh the risks and severity with bugs to taking some chances to get things released. The business groups may prefer you to take longer. When they ask how long, don’t assume it means the absolute minimal amount of time possible.

Document the process and get their feedback on priority. You want 10 things done and we only have enough people to do 5, which 5 do you want? Most people just want to be kept in the loop. Making them continually ask and providing no feedback makes the time seem longer. This is why phone systems try to tell you how long you’ll have to hold to manage your expectations. Making changes is no different. Let them know the change will affect delivery. Then they can decide if it is important enough.

As far as presenting this to management, make sure you know both sides of the story so you can present problems that everyone agrees need to be fixed. Hopefully, you’ll have some agreed upon solutions. One communication problem I always see is someone from higher-up asks “Hey, can you see if we can add one more column to this report?” and by the time it gets to the developer the message is, “Mr. Big wants a new column in the report ASAP or all of our first-borns are toast!” Management is in a quandary about your complaints about your situation.

Six Sigma Methodology has a number of tools that can be used to assess your processes and determine costs and losses to the business.

Just realize that the task you are taking on is potentially huge. I was on a team where one of our major projects was to do just this for a major manufacturers development and testing unit. We identified over 500 major processes, most of which were undocumented at the time of the assessment. The assessment process took 2 years, and then another year to come up with a 10 year plan to document and improve these processes to the point where the it would reach that control level. This was at a company that was already ISO 9001 certified. I suspect it would be a bigger effort at a company that was not used to the processes that are required to provide the metrics you are requesting.

One of the major problems with something like this is that many developers are creative types and that mindset often does not handle being forced to conform to processes well. Chances are if you have a Cowboy Coder culture now it is going to be a challenge to channel those developers into the type of structured environment that can produce repeatable and predictable success.

Another major problem is that despite having a huge potential ROI, development is often done on a tight budget with unrealistic deadlines. Imagine if I came to you and told you I wanted you to design and build me a Rolls Royce quality car, but I am only willing to give you a budget of $20kUS and you only have 2 months to get it done… that sort of thing happens far too often in software development. To be repeatable you have to be realistic.

May I recommend the Joel Test: 12 Steps to Better Code. Quoting from the blog post:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

These questions were written by Joel Spolsky in 2000, but still have not lost their relevancy to this day (2014). However, I would add a few additions to some of the questions:

1. Specifically, do you use a source-control system with built-in code 
   review capability? (e.g. something like git's pull-requests)
2. Do you have a continuous build system in place that 
   kicks in automatically on every commit?
3. Do you have a continuous delivery system in place that (at least)
   installs every build automatically in a test environment?
...
6. Do you actually work by Scrum or Kanban?
7. Do you write and estimate user stories on a regular basis?
...
11. Do you find useful tasks for coding that relate to what the 
    job is actually about? (as opposed to asking for the 1e6th 
    incarnation of the Fibonacci algorithm, or to solve the TSP
    when the job is about writing your next JavaScript UI)
12. Do you use A/B testing to determine what people actually prefer?
    (as opposed to their stated opinion)

Filed under: softwareengineering - @ 03:03

Thẻ: development-process

Thiết kế website giá rẻ

Danh mục

What methods exist for assessing an organisation’s development capability? [closed]