Discovery Phase in the Software Development Life Cycle (SDLC)

Anyone who has completed a few software development projects should recognize most or all of the Design and Delivery activities listed on this software development life cycle (SDLC) slide. However, in my experience, a much smaller percentage have been involved with projects as early as the Discovery phase. In some cases, Agile projects are so anxious to get to coding that they skip this phase altogether because they want to get to the nitty gritty details as soon as possible. However, a little time spent on Discovery activities can save lots of time, and is therefore agile in my book.

I drafted a big long blog about this phase, but realized that even using the word “Phase” made it sound like some long, drawn out waterfall project, when in fact it is a quick exercise meant to narrow scope and focus the design effort. With smaller projects I’ve spent as little as a few hours on this phase. Even for larger projects I usually don’t spend more than a week or two. The main goals are simply to identify the business case (current problems, proposed solution and expected benefits/ROI), identify the high level project scope, and provide a resource and budget plan for the Design phase).

Here is a sample Design phase proposal, which I have posted in html format. If you'd like a soft copy of the actual document, send your request to aaron@agile101.com.

During the Discovery phase I conduct interviews with the sponsor and key stakeholders, including eventual system users. The Design phase proposal is the key deliverable of the Discovery phase. As you complete the tasks in this phase, keep a few things in mind:

• Identify what is in AND out of scope - It can be just as important to list what is out of scope as it is to list what is in scope. This helps clarify some big misunderstandings right out of the gate. I’ve witnessed a few projects and skipped right over the Discovery phase and found themselves moving ahead with designing and even developing features that the business may want but that the sponsors consider to be out of scope. At this high level identifying what is in and out of scope isn’t a perfect, but it can definitely save time.
• Ensure technical oversight – Often, project and account managers, or even sales and marketing people with no concept of software development, attempt to tackle the Discovery phase on their own. However you resource the Discovery phase, make sure that you have oversight from a senior technical person. They should at least review the high level scope and identify potential risk points. Since I believe pretty strongly in doing technical proof on concepts (POC) during the Design phase, they can identify which POC’s will be of value, and provide estimates for these exercises.

Spending a little time in Discovery at the outset of the project can help you focus your design efforts and get to delivering valuable, working software as soon as possible.

Agile Software Development Lifecycle (SDLC)

One of the biggest critiques of Agile software development methodologies is that the planning is almost non-existent. Indeed, there are some Agile teams that get pretty aggressive and begin developing with very little detail of the system requirements. The idea is that as they receive more information, they’ll just refactor their code as necessary. While the ability to quickly refactor is a valuable skill, this approach can be taken to an extreme. Consider construction of a building. If you decided 3 months into the project that you want blue paint instead of yellow, no big deal. Changed your mind on the shag carpet? No problemo. Decided it should be a 40 story building, not a 3 story building? Hmmm…lots of wasted time and money that could have been saved by doing a reasonable amount of planning.

No matter what project methodology you use, certain planning activities are necessary for a successful software development project. Here is a link to a slide of the Agile software development lifecycle (SDLC). It also shows the activities by phase. Over the next few months I’ll expand on each of the activities identified on this slide.

The slide identifies 4 main project phases. These are pretty standard across methodologies, although they often go by different names:

• Discovery – Identify business case and high level project scope
• Design – Define requirements and mitigate risks pre-development
• Delivery – Develop, test, and release working software
• Deployment – Deploy working software and provide support

OK, so I’ve been going on and on about how much Agile follows the same SDLC as other methodologies. While the high level activities are the same, the timing and depth of each activity can differ greatly. The main point is that Agile is iterative, i.e. you don’t complete all work in one phase and move to the next, as in Waterfall projects and many RUP projects that I have seen. Instead you complete enough planning early to mitigate overall project risks and provide adequate direction to begin the highest priority development as soon as possible. Reams of documentation can be impressive, but at the end of the day, it is the working software delivered early and often that puts the smile on your customer’s face!

The Art of Lobbying in Software Development Projects

It happens many times every day all over the world. Someone enters an important meeting and makes a proposal. First one person raises a concern, then another, then another. Much to their consternation, their proposal goes down in flames. They might ask themselves, "Why do people have to be so critical of my ideas? It didn’t even seem like some of them wanted to understand. Why can’t they just listen?"

One of the soft skills that are so valuable in business in general is building consensus, or, in other words, lobbying. So many people fail to do this, and find themselves in losing situations. Here are some more specific examples:

• A new technical team lead announces a new direction for the technical architecture strategy. This is the first anyone else has heard of it, including team members with much deeper understanding of the existing architecture.
• An external consultant running an outsourced project tells the customer’s IT department in a meeting how they are going to have to change their deployment process to support this project.
• A project manager mentions during an iteration review with the team and customers that the tech lead’s development capacity is going from 75% down to 25% to accommodate their other responsibilities.

In such situations, you may have painted yourself in a bad situation. Some people will push back on any decision, good or not, made without their involvement, especially if it impacts them. Often, people just haven’t thought through the issue like you have, and take longer than you might think to catch on. In the meantime, the critique can essentially brand the idea forever as ill-conceived. More often than not, your plan just has a few flaws that should have been addressed before it was lights – camera – action.

Yes, but isn’t it impossible to avoid dissention? And isn’t critique an important part of honing an idea? Isn’t group feedback the right way to go, anyway? Certainly group planning and brainstorming sessions are helpful, and are most effective when you don't arrive with completed proposals. However, when you enter a situation where completed and well-thought-out proposals are needed, lobbying is crucial.

So what does lobbying entail? In short, run your plan by key stakeholders prior to your meeting, discussing your proposal, how you came to your conclusions, and highlighting the expected benefits. Listening is then a very important aspect. Consider feedback, and take the time to solicit their alternative recommendations. Address concerns. Your plan will likely evolve based on these discussions, and you will find that there were rocky parts that have been smoothed, making your plan more viable. Additionally, you will be winning supporters along the way. These people who might have been critics are now likely to back you up when others raise their concerns during a meeting.

Build consensus before making any grand announcements, and you’ll find your ideas and plans much more fully-baked and more easily approved.