Monday, May 6, 2013

Sometimes, You Do Need To Break The Rules!


Well, it is all about the process, except when you need to forget about the process!


Quite the title … and an accurate description of what we all deal with on a daily basis.  There are some projects that come through the pipeline that don’t qualify for the full pomp and circumstance of the defined Software Development Lifecycle (SDLC).  Sometimes it is a low risk project, sometimes it is a project with a predefined date mandated by a client or a partner, and sometimes its just that everyone agrees what needs to be done and you just need to get it done.  Whatever the reason, we all have those projects that run through our departments with minimal oversight.


So, when this is happening to you, what is your reaction?  Many organizations just let it happen. Hey, the boss wants it, just get it done.  Right?  Nope, I’m here to argue for a process for the instances when someone says the process is getting in the way.

Ultimately, this is happening because someone in the organization feels that the formal process slows things down and that the need the team to be more nimble.  And, my response, yes.  If you make every project go through every phase and produce every artifact of your lifecycle - then it is going to slow things down.  The caveat - if you only look at it from the perspective of the first time through the cycle.  Typically, if you have a complex project and you begin skipping artifacts or lifecycle phases, you end up missing requirements, developing the wrong features, spending more time in testing or delivering a product into production with a higher level of defects.  Notice that I said, “complex project”.  The problem is that not every project that runs through your pipeline is complex.

So, what’s a team to do?  Strip down your process - identify the complexity and risk of the project at the beginning,  and make decisions on what can and cannot be left out during the various phases of the lifecycle.  Do you really need a discovery phase with it’s associated documents, or can you skip right to the requirements phase?  Do you need to create both a high level project design and a detail design, or can you skip the high level and just do the detail design?  Do you need to formally go through all of the decision gates, or can you just do the final gate prior to the project moving into the production environment?  Do you need to run in parallel, or will a regression test be good enough? Every project is different and for some projects you can simplify the process and reduce the churn and labor associated with the full SDLC.

I’m a huge proponent of creating a formalized SDLC process within an organization.  This can be waterfall, Agile, RAD or any other methodology that works for your organization.  That said, we can’t let the process get in the way of every project.  It’s not needed.  In fact, you may need to run waterfall on some of your projects and Agile on other projects.  I’m not here to tell you which process to use - just that you need a process and you need to be flexible in the implementation of that process within the organization.

I’ve had the fortune of creating the SDLC process for various organizations throughout my career. Small dedicated development shops, to larger teams spread out across multiple locations.  I’ve faced the same issues in every organization that I’ve been associated with.  At some point, someone higher up the food chain is going to make a commitment that you have to keep that will force you to break your process. Maybe that person will actually be you!  Will you just let it happen, or will you step back and optimize the SDLC for the specific request.  Once you do it, you will begin to find ways to make this happen on other projects moving thru the lifecycle.  This will show your team and management that you’re interested in making changes that improve the productivity and accelerate the development pipeline.

At one of my previous positions - I was constantly used as the example of someone who broke the rules.  Not in a bad way, but in a way that showed I was willing to change the status quo and find a different path to get things done.

What are you doing in your organization to streamline those projects that don’t need all the pomp and circumstance of your formal SDLC?

Tags: #SDLC #softwaredevelopment #lifecycle  #applicationdevelopment #programming

If you'd like more information on my background: LinkedIn Profile

No comments:

Post a Comment