Managing release day

Typically in a software company there is a dedicate 'Release Manager' - a person who manages all the projects and make sure they all come together in the software and that the software gets shipped on the release day, but does the buck stop at s/he ?
I think companies should have release team where there is more than one person to manage the release cycle (now of course that depends upon how big is the release cycle and how often it is done).

Software release can be very complex, may involve many small projects, to coordinate, scope of the project can change based on available resource and customer priorities, the main role of the release team is to ensure that the software being released meets customer requirement, all small project are included, and the most important thing is to release on time with highest quality possible.

The software release team should be decided earlier on the project and each person should have a clear responsibility within the release cycle. Often QA team leader or project manager is the best person to be the team leader of software release team. Software release team leader should be expert on interdependencies and various integration issues, s/he should be very familiar with the product to be able to analyse the impact of release on each and every customer, this information is very crucial when the software has to be released with known bugs (I know no one accepts this but it has been the fact of software release)

Some of the role/things to be managed by the release team are as follows

• Who is the Build Master (ideally there should be one complete build every day)?
• Who is responsible for the installer?
• Who is responsible for releasing the software and ensuring the software is delivered to the customers?
• Who is in charge of the release/installation document?

If all (or most of the above) is planned and executed there may not be any surprises on the release dates.

Quality Of Software

Many placed I have worked in past, software quality is often talked about but in reality it is always compromised mainly for cost and time reason. The usual explanation is that since the turnaround time to fix the bugs are not that high, there is no need to spend more time on testing. Market research has shown that organization, who invests heavily in testing procedure and tools, reduces cost long term since they are not constantly going backwards and fixing things over and over again.

Even in an organization where this is a QA team, often quality starts and finishes with them, I feel quality is responsibility of the entire team, which includes management and BAs, and of course developers. Try looking at your development cost and chances are that 60% of the development resource is spent on identifying and fixing defects. By not introducing defects in the system and implementing proper tools and procedure to identify them earlier on, development cost can be reduced and eventually increases team productivity.

Quality should be enforced right from the beginning of the project (yes even in requirement gathering phase), project leader should focus more on quality rather than quick delivery.

To conclude this blog, there are various level of quality required for software, some mission critical software needs to have close to 0% defect, where as some software can handle more. Quality is an ongoing process, which should be built in to the SDLC, quality should not be looked as burden and requires commitment right from the top level management. Any testing tool can identify the defect but only the ones which falls under the testing criteria, most software are so complex (at least the ones I have worked with) that there is no way you can test the complete software, in this scenario implementing good quality business process (along with testing tool) is the way to go.

Shorter Release Cycle

Quality of software can be improved over a period of time by introducing shorter release cycle (I am experiencing it first hand at my current workplace). It is a known fact that software has defects, there could be many reason for that, bad requirement, poor coding and not enough testing, fortunately over the last decade or so people are so use to defect they have started accepting it in some form or another.

Defects which are left in the software too long becomes an undocumented feature and when it is fixed you are bound to upset some of the customers.

Introducing shorter release cycles ensure that software gets out of door more often and chances of identifying defect increased, which in turn means more (and timely) opportunity to fix them. This also means that no defect is left long enough to become a feature.

Shorter release cycle also means more excitement to the development team, users and market, it enables team to release new feature in a controlled fashion to get a feel from the market before you invest heavily in any given functionality. It also give you more opportunity to catch up with your competitors.

Releasing web based software could be much easier, fix has to be deployed only once, and is available to everyone instantaneously, but there is also a downside one defect introduced and everyone is affected immediately, frequent release can also upset web users as no one likes to put up with changes every day, but it gives you an excellent platform to change user habit slowly over a period of time.

Releasing software more often can also pose some challenges to the internal team as well as customer, since customer has to upgrade more often it also creates a sense of uncertainty (as they say 'known enemy is better than unknown friend’), but over a period of time team and customer will get use to the release cycle and will start seeing the value. The key is to release software timely without compromising innovation and stability.

On the final note regularity = reliability = happy customers.

Walkthrough Process

Performing a walkthrough process is very critical during analyzing phase, it helps the stakeholder, business user and development team to understand the proposed solution and identify any potential shortfall.

Walkthrough should not be just conducted before the beginning of development; it should be done regularly (as and when needed) during the entire lifecycle of the project.

Some benefits of structured walkthrough are as follows

• Helps stakeholder to believe and take ownership of the project.
• Business users can visualize the solution and propose any changes or highlight any potential problems.
• Reduces ambiguities and identify missing functions earlier on the project.
• Helps the team agree on objectives of the proposed solution.
• Validates the current and complete understanding of the analyst(s).

Planning and Organizing Walkthrough

Make sure that relevant people (preferably one person from each department and/or level) attend the walkthrough meetings, keep the meetings short and distribute material to every participant before they attend the meetings.

Facilitating a Walkthrough

Rules observed during any business meeting should be followed during a walkthrough meeting, such as

• Make sure you book the meeting room well in advance.
• Setup the meeting room before the meeting starts.
• Arrive on time, and most importantly finish on time.

Below are some more tips when you are facilitating walkthrough meetings

• Give every participant a fair chance and time to speak.
• Do not interrupt when someone is talking and don’t let anyone else do that.
• Use terminologies which are familiar to the group and/or organization.
• Take notes of all the proposals, questions and problems identified during the meeting.
• Try to stay away from fixing any problem and/or bugs identified during the meeting.
• Nominate yourself or someone else to resolve any conflicts arises during the meeting.

Always remember the cost of fixing and/or changing anything after the development is complete is very expensive and time consuming when compared to identifying it early on the project. Please let me know if you have any questions and/or comments.

Got a presentation to give ... read on

Anyone can create a presentation, but presenting a presentation is totally different game, I am going to talk about some of the skills you may need in presentation.

The main part of the presentation is content, if the content is right and catered for the audience, you are guaranteed a great turnout. You have to make sure that you have done enough research on the topic well in advance, you never know who is going to ask you a question and about what.

One of the thing which is very important in a presentation is to keep in charge, there will be occasion when someone will ask a question which is unrelated to the presentation or perhaps out of scope, in that situation you have to gracefully acknowledge that question and inform the person that you will address that question outside the presentation.

If you know the audience before the presentation it is a very good idea to send them the agenda of the presentation in that way you are absolutely sure you get right people and gives others a chance to gracefully opt out of the presentation.

I think visuals are great in presentation, make sure they are not very small and do not contain lots of information, it can be very distracting for the audience, you don’t want people to lose focus while you are talking.

Make sure the slides are in logical order; there is nothing worse than having to jump from one section (or slide) to another.

Font size should be appropriate, it may be useful to actually project you presentation before your meeting, sometimes text looks quite different on a computer screen then projector screen. Avoid writing text in presentation exactly what you are going to speak. I have attended some presentation where the presenter is just reading the slides; you can have bullet points to highlight items you are going to talk about in your presentation.

It may be very handy to print slides and give it to the audience, in that way they can refer to previous slides and write notes on it, also very handy for latecomers or people leaving early. One more reason is that some people take it with them and keep it for their future use (you may want to email your presentation to everyone who attended the presentation), on that note it may be good idea to mentally record names of people attending the presentation (this may not work if you have a very big audience).

Make sure you do not spend too much time (or too little time) on each slide; my guideline will be about 2 slides per minute.

The most important part of the presentation is YOU, make sure you stand straight, don’t move from one side to another, use less hand movements and the most important thing is your tone, don’t use same tone throughout the presentation (it may sound like a robot and puts people to sleep), show some emotions in your voice, if you show that you are passionate about what you are presenting your audience will feel the same. Practice some breathing techniques; a few deep breaths can reduce the tension and helps relaxing.

Below are some of the things I would discourage you from using in a presentation

• Video
• Sarcastic comments on product/people/team etc
• Animated text
• Multi color text
• Share joke (very unprofessional)
• Black (or dark) background

In the end of the presentation, you may want to open the floor for questions and answers, make sure you thank everyone attending the presentation, give your contact details and ask them to be in touch if they have any questions and/or feedbacks.

If you follow the tips mentioned above I am sure you will give a great presentation... all the best.

Critical Success Factor (CSF)

Critical Success Factor (CSF) are defined based on individual organization’s goal, objective and mission, a good CSF are the ones which can be measured, and when I mean measured I don’t mean by a score, there needs to be a baseline defined for each CSF to be measured against.

One of the CSF for a project I worked for in past was 'ease of use', immediately when I looked at the CSF I told them, that’s an interesting CSF and I posed them a question, how are you planning to measure that?, and guess what I did not get any tangible answer, the reason was that everyone agreed that we want to deliver a software which is easy to use but did not know how to measure it? that does not mean it is not a good CSF. The moral of this story is that if you cannot measure something how you will decide if it was successful or not, sometime we do not have to categorize a CSF as success or failure it could be how effective it was and that’s good enough (at least for me).

One another CSF I came across was 'increase in sales by 20%', which was later changed to 'increase sales by 20% from last year', now this can be measured, do you agree?

Identifying CSF (oops measurable CSF) at the begining of the project is very critical for project's success and for stakeholders confidence in the project.

Some of the typical CSF is as follows

• Solution will be delivered by so and so date.
• Solution needs be able to install via an installer.
• Software needs to be up and running with no (or absolute minimum) configuration.
• Sales order should be placed within X minutes.
• Quotation needs to be generated within X minutes.
• Implementing this solution needs to save X dollars in operational cost.

Sometime there could be different CSF for different team, but an experienced BA will ensure that every teams individual CSF can be used to measure organizational CSF.

It is very important to constantly keep an eye on CSF, the progress needs to be recorded correctly and more important timely, very recently I saw people in my organization using burn down graphs and backlogs, the tool was very simple to maintain and enabled the whole team to act in time and monitor progress, that’s what I like to see.

Bye for now…

'Team' the sacred word

I bet you have heard that word a million times, perhaps few times every day, we all know what team means and there is no need for me to explain that term, but sometime I still ask myself the question "What team means to me?"

So I am going to talk about what team really means (to me), for me "team is a group of likeminded people thinking, analyzing and working together for a mutual goal". Most companies (no offence) think a team is a bunch of people thrown together in a room to complete a task. Now you may argue what is the difference, the difference is more of philosophical, when a group consists of people who have different view and different goal; often it is difficult to increase the productivity and delivery of the group. Why do you think these "Team Building Programme" are getting popular, that’s because more and more companies realizing the true meaning of a team (a good team).

Following are some signs of a good team

• One team member supporting other team member (or group of member).
• Tolerant to each other’s short come, uniqueness and opinion.
• Team Leads are passionate to teach and help team members.
• Team member are open to share their expertise & insight to other team members.
• Team member often stop to see how other team members are doing.
• Team member treat each other with respect.

Remember a team is as strong as its weakest team member.
Something to think eh?