Archive for the ‘Development’ Category

SEPG North America 2013: Why You Want to Be There!

Thursday, August 22nd, 2013

Why Do You Want to Be There?
This year, the conference is significantly re-orienting itself towards END USERS. Previous SEPG conferences had a lot of useful information, especially for experienced change agents and consultants in the field.

This year, the focus is on up-and-coming disciplines, established success strategies, and most importantly, direct business performance benefit of using CMMI. In fact, what we’ve seen over the years is that CMMI is working extremely well with other forms of improvement as well as with existing defined service delivery and product development approaches — whether agile, lean, traditional, customer-focused, innovation-focused, or some combination.

CMMI provides a specific framework that is both a way to focus attention on specific needs while also benchmarking progress. Instead of flailing around trying to find where to put improvement energies, or waiting for a long-term traditional approach of process exploration and decomposition, CMMI takes a lot of the guesswork out by leveraging decades of experience and laying out very specific goals to seek to improve performance.

CMMI users have reported their productivity to increase magnitudes of order, costs drop in double digits, and their ability to cut through thick process jungles more quickly than being left alone to their own devices.

Yes, I’m speaking and presenting at SEPG 2013, but that’s the least relevant reason to attend. Come because you want to see what others are doing to marry CMMI with existing (or new to you) concepts; come because you want to hear from other end-users what they’re doing with CMMI to improve performance. And, most of all, come because you want to get and stay ahead of your competitors who aren’t using CMMI nearly as effectively as you will after attending.

SEPG North America: The CMMI Conference is coming soon, but there is still time to register.

This year’s conference program will include content perfect for you if you are:

  • Beginning to implement–or considering implementation of—CMMI
  • Seeking resources and best practices for integrating CMMI and Agile practices
  • Interested in taking your process improvement game up a level
  • A fan of rivers, boats, bridges or baseball !

Check out the conference agenda here: http://sepgconference.org/sepg-north-america-agenda and when you register, enter the promotional code "Entinex" to save $100 on your fee. (Or just click this link and the discount will be applied for you.)

Book before September 1st to get a discount on your hotel room, as well.

Get the details on the website (http://sepgconference.org) and email sepg@cmmiinstitute.com with any questions.

Posted in Agile, Agile+CMMI, CMM, CMMI for Services, Customer Satisfaction, Development, Discipline, Efficiency, Engineering, Goals, High Performance, Improvement, Innovation, Kanban, Maturity, Performance, SEPG, SEPG Conference, SEPG North America, Services, agile SCAMPI, lean, measurement, operations, value | Comments Off

Forget CMMI!

Tuesday, November 15th, 2011

This is probably the most important blog entry I’ve ever posted.

The video is the longest video I’ve ever posted on the blog, and for that reason, I’ll keep the text content to a minimum. 

Here’s why you should watch the video:  CMMI may be entirely wrong for you, and you may not know it!

The video explains an epically crucial reality about CMMI that many agile (and other) teams are not aware of, leading them unknowingly down a path of self-defeat and damage.  All of which could be avoided with this one super-critical piece of knowledge.

You’ll thank me later.

Backstory:

The lure of seemingly limitless opportunities can be quite strong, obviously.  And, especially in tough economic times, succumbing to that lure can cause even the best of businesses to act unwisely.  Such is the lure of CMMI ratings.

Well, anything that’s very alluring can cause unwise behavior, I suppose.  Whether it’s as apparently harmless as indulging in a luscious dessert, spending money on unnecessary luxuries, or any of equally limitless opportunities to make bad choices, doing what we want instead of doing what’s right shows up even when working with CMMI.

This blog is full of examples of such bad CMMI choices, but there’s one bad choice I haven’t mentioned much about.  That’s the choice to even try to use CMMI.

When working with a knowledgeable, concerned, trustworthy CMMI consultant, an organization should be steered away from CMMI when their circumstance doesn’t align well with model-based improvement using CMMI.  In some cases, it may be a matter of steering towards the right CMMI constellation (e.g., for Development, or, for Services).  However, just as whether or not CMMI is right for an organization ought to be discovered before too much energy is put into it, so should the decision about a particular maturity level within the constellation.

No CMMI constellation should be attempted if/when the organization doesn’t control the work that it does.  Namely, that the work it does is controlled by another organization, such as a customer.  Or, put the other way, CMMI should only be used if/when the processes used by the people doing the work are controlled by the same organization using CMMI to improve them.

At Maturity Level 2 (ML2), almost any type of work can use the practices in that level to improve its performance and to demonstrate that the practices are in place.  However, at Maturity Level 3 (ML3), you have to be doing the type of work in the particular constellation in order to be able to use the practices in it.  If you’re not doing that type of work, the practices will be irrelevant.  Attempting to use the practices when there’s no such work being done will only cause the practices to get in the way and add nothing but frustration.

In particular, if you’re not doing work that involves structured engineering analysis, CMMI for Development at ML3 will be truly unwieldy.

Adding practices for work you’re not doing is an example of the bad behavior many organization exhibit when they’re chasing a level rating rather than hot on the trail of performance improvements.  It’s these sorts of behaviors that are somehow rationalized as being beneficial when, in fact, they are unequivocally, diametrically, and everything but beneficial.  They are a colossal waste of time and money and detrimental to morale and productivity.

You really need carve out about 11 minutes to watch the video.

Posted in CMMI, CMMI for Services, Development, Engineering, Improvement, Level-Chasing, Maturity Level, Performance, ratings | Comments Off

Reintroducing "engineering" to software.

Monday, May 4th, 2009

I’ve been noticing an interesting "convergence" going on in this corner of the universe:  "engineering" is being re-introduced to the idea of software.  It’s fascinating how no sooner do I have the idea to write this blog (while entirely not connected to the Internet), then I re-connected to get an article that’s entirely speaking of the same root issue.image

Of course, I’m not saying that engineering had completely left the software universe, though, a strong argument can be made that for the last decade and then some, software has allowed engineering to escape from the premises.  In particular, architecture, analysis, systems thinking, design, hardware and other integration issues, and planned, deliberate, methodical testing have largely been allowed to merely "emerge" from the work that was completed.

Again, I’m not advocating for Big ____ Up-Front as a solution, what I’m pointing out is that many people who embrace agile methods incorporate engineering practices into how they organize and perform their work, but enough don’t that it raises issues with agile scalability.

And here’s where I *am* expecting to annoy some people…

Programming and Development are NOT the same.

Development is an engineering function.  Developers ought to be using engineering practices in what they do.  Just look at the word "development".  The connotation is that something is "grown" or "evolved".  The denotation of ‘development’ in the technical sense is that it is done deliberately, not by happenstance.

This idea is where I believe software, in general, not limited to agile practices have short-changed themselves.  Too often, activities that amount to nothing more than programming are called development when no actual engineering is happening.  In other words, programming is allowed to take place without any (or at best without enough) engineering, and therefore what’s really happening is the building of something without any/enough forethought about the thing itself that is to be built.  Instead, what happens too often is all the focus is on "staying busy" (albeit on ostensibly priority work), but what is worked on is absent sufficient technical rhyme or reason.

Is this true of all agile development?  NO.  But, it is what happens in many organizations when they don’t have sufficient technical leadership.  For what it’s worth, many development projects don’t need much engineering, and product development is sufficiently described in tasks defined by few people.  So the jump from development to programming is small and fast. 

image However, there are projects (or tasks) of sufficient technical complexity that skipping the engineering and handling such projects/tasks as programming alone is where I believe a space is created for the unfair reputation for agile and its scalability, as well as some of the anti-process bias among agile proponents.  When I read (and sometimes contribute) to agile and non-agile software groups, I’m often struck by the same thought: where’s this person coming from?  This is basic engineering!

But that’s the matter, isn’t it?  Programming isn’t development without engineering and too many programmers aren’t engineers (not should they be) but are being told to "develop" without given the time or resources or something to do the engineering.  And so what they’re really being told to do is "program", not "develop".  Someone, somewhere doesn’t see and/or understand that what many projects need are to be engineered.

I think what this points to is a persistent phenomenon plaguing software: it’s not being taken seriously as an engineering discipline.  Sometimes by leadership in organizations where software is being worked on, sometimes by programmers and sometimes by customers.  I’m sure there’s plenty of blame to spread around, and spreading the blame is both a waste of time and not the point at all.

Programming is to software as assembly is to construction.  Not image everyone swinging the hammer needs to be the civil engineer nor the architect, and not everyone with a nail gun can be the foreman (and no, I’m not likening the skill set of programmers to those of construction workers, and no, I’m not saying construction workers aren’t smart….geez).  There has to have been engineering taking place before software can be actually developed, and as evinced by the kinds of challenges I encounter regularly, enough software shops are going about their work absent acknowledgement or awareness or consideration for the engineering that has taken place or has yet to take place (or should have taken place but didn’t[!]).

Process stuff generally finds its roots in engineering.  Especially process stuff as found in CMMI for Development.  Excepting processes that are over-engineered, are themselves lacking in engineering, or are odious even alone in a room, I’m beginning to piece together that resistance to processes in general, and CMMI in particular, is actually from a lack of engineering discipline in the software practice and not from anything intrinsic to process as a topic.

It’s no wonder CMMI is so hard to use by so many, it assumes peopleimage are not only experts in process improvement, it also assumes everyone using it is an engineer.  Some people are nail-gun swingers, worried about getting enough done that day to avoid having to work on the weekend.  Meanwhile, someone else already worried about in what order to build piece the trusses together and someone before that worried about the right number of trusses and their thickness and someone before that worried about its shape.

It’s becoming fairly clear that anyone fooling themselves into believing that agile advocates not doing an architecture at all, or a design at all, or other engineering activities at all are doing themselves a disservice.  In fact, I’d go so far as to say that once an architecture has been settled upon and once a design becomes clear, that agile practices can happen more freely and effectively.  More so, I’d assert that the future of agile "scalability" depends on these.

What I and a colleague are setting out to do over the next few months is help agile scale by re-introducing engineering to software, and while we can’t fix the software universe, we hope to help agile out by giving it some engineering practices that software (as a whole) lacks — not everywhere, just in too many corners — but that we believe agile can really take and run with.

Let me know if you want to play with us.

Posted in Architecture, Design, Development, Engineering, Programming | 3 Comments »