In todays post, I want to focus on the methodology of the SDLC by paying particular attention to the consistency of the SDLC which involves asking the following questions:
What specific values does following the same process add to the end product? Is the software better? Is the team more productive? Is it easier to attract and retain good employees? Is your company more competitive because everyone does everything the same way? Do concepts move to products more quickly? Does your stock price go up?
Most of the time, consistency in SDLCs has very little to do with these very important questions. some reasons why all of which ….are not nearly as important as the questions already listed:
Projects are easier to audit
You can use a lot of templates for deliverables
Status reports all look the same
Everyone knows how to log defects, requirements, etc, no matter what project they are assigned to
Managers tend feel more comfortable when they don’t have to rely on employees making the right decisions about how to proceed
…these benefits are not particularly substantial, especially when you consider some of the potential drawbacks of “consistency”:
Using the same hammer for every job results in frustrating inefficiencies for developers who “know there is a better way”
Employees can stop developing their ability to make good judgment calls
Your organization can develop an “it doesn’t matter if the project fails as long as we follow the process” mentality
Talented people will not stand for it — they will ignore inefficient process requirements or leave (or both)
If you…believe that consistency will have substantial benefits, that it will make your projects more successful and help your company compete more effectively, then…[the following might illustrate how benefical it might be]
1)Don’t rely on documentation to enforce the process…[as] Documents don’t make anything happen. People do. When someone asks you about the SDLC, don’t point them to a document. Walk them through it patiently and without condescension. Don’t make it “bad” to not understand — this will alienate you from the development teams and make them less receptive to your coaching.
2)Focus on the end game
Don’t try to sell consistency for its own sake. Instead, talk about the value consistency provides. If you have come to the conclusion that consistency provides value in the ways I described in my first set of questions, then you should already have answers for this. Talk about how it makes you more competitive, how it helps you deliver projects faster or with fewer defects. If you can’t explain this, then you should reconsider whether consistency is, in fact, desirable
3)Be an asset
One of the best ways to drive adoption of a process is coaching others in the use of it. Get involved with projects and find ways to add value. When they ask for help, give them more than they asked for. Try to think of ways to help them see you as an asset to them, someone that helps their projects be more successful. You don’t want them to see you as a project policeman (or policewoman) whose sole concern is whether they have created every required deliverable and doesn’t care about the project’s outcome. This will set you back millennia.
4)Keep it simple
Make your process easy to follow by reducing ceremony (e.g. required “meetings” where approval is granted, like a squire being knighted) and formality (standardized documents requiring signatures). Ceremony and formality should ONLY be used when they are actually needed — like when obtaining funding to create a new product, or acceptance of a fixed bid deliverable. Don’t create non-value adding ceremonies and formalities around interim deliverables like requirements documents, designs, code, etc. without EXTREMELY good reasons, such as avoiding accidentally killing people if the software fails. If your software’s failures don’t kill people or destabilize economies, you probably don’t need to get written signatures on every piece of paper your project generates.