Dedicated team for previous version releases

For software products that have had multiple releases over the years, there is a ticklish question about the resources that need to be dedicated for previous released product versions. This is even more critical for software products that have wide usage such as Microsoft Office, Photoshop, and Acrobat. Organizations have stated policies about providing support for previous versions, but there is a cost associated with doing the same. You need to have people who can do defect resolution and testing, you need people who can do all the entire build infrastructure including releasing the software fix. This can add upto a pretty packet in terms of resources, and this can be painful especially when there are time periods when there are no major fixes that are due.
Deployment in these previous support teams can also lead to tricky morale issues, given that people assigned to these teams would feel that they are put onto a team that is less important than those who are part of the team working on the current features. To avoid such morale issues, team can rotate people across these teams, but that comes with its own problems about people not being able to develop the expertise, something that comes only after gaining experience on the team.
A problem with not having these previous support teams - for some organizations and products, such an option is not possible; a full fledged support team is required. Consider somebody using a previous version of MS Office or Adobe Acrobat, and suddenly, there is news from a computer security researcher about a critical zero day or similar intensity defect in the product which could allow a hacker to get into the hole. These events can be a public relations disaster - such blowback cannot be countered just by Public Relations, but there is a need to have a team that can work on a full scale quick research and fix, such that the organization develops a reputation for responding quickly. And it's just not a fix in a previous version, but the same problem may be there in the ongoing version that is being developed and the team needs to get the research done by the previous version team and incorporate the fix in the version under development.
A lot of teams I know slightly under-budget a team for working on previous version defects, and if the problem requires a slightly enhanced amount of effort, then additional people are deployed for working on the defect fix, and are only there on a temporary basis (even though it might have some amount of impact for the current cycle, but there is no real solution for the same). People assigned to such teams are typically team members who are not very high in ambition, and are not necessarily the high rated people in the team. Further, the Product Management teams need to be involved in both sides, since many of the feedback in terms of defects or suggestions are actually coming from customers or end users and there is a possibility that some of them may have value for the next version to be released.   

Trying to get non-responsive members of the team be more schedule sensitive

We know this problem, it happens all the time. You have different members of the team, some more disciplined and some less disciplined. Actually discipline is the wrong word. When you have creative members of the team, or team members who are attached to multiple projects, then there can be problems with respect to scheduling of their deliverables. In the case of team members such as User Interface Designers or Visual Experts, or Visual Designers, they typically do not move to the same beat as that of the rest of the project teams, such as Engineers or Testing Engineers.
This can be problematic for the rest of the team, since schedules are interlinked to each other. For example, the User Interface Designer would prepare design specifications that are used by the team members to discuss and finalize the feature workflow and the technical architecture. These are then developed and passed onto the testing team which does the testing and then releases the feature. However, if the initial design does not come in time, then the rest of the schedule will get impacted.
One of the problems that I have experienced with User Designers or similar creative people is that they do not work in pieces; they would like to look at the overall workflow for the product and then release a completed design. But the team does not work like this, it would like workflow designs feature by feature, so that the work can be done feature by feature (and it makes logical sense).
Another option that could have been postulated is that the Workflow Designer could have a period of 2-3 months before the start of the cycle, so that the Designer gets enough time to make the design. This seems logical, but there are problems in this. The Workflow Designer does not work entirely on his / her own, but needs to work with the Product Manager and the team members (the team members  are involved so that the team could figure out the technical cost of doing the Workflow designs; some of these workflows may take more time and effort than other workflows and the contribution of the technical team in figuring out these is critical. This process can be iterative).
So how do you work out trying to get such more creative members as part of the process?
- First and foremost, it is necessary to ensure that you do not make the assumption that these resources understand the critical nature of meeting their schedule deliveries. It would be needed to spend much more time with these people and form a detailed plan for deliveries, doing this discussion multiple times till an understanding has been formed.
- In my experience, it was also necessary to have 2 dates in the schedule with a few dates gap between the 2 dates. It was necessary to push the delivery to happen for the first date, but there was also the understanding that the delivery happening on the 2nd date would also work fine without threatening the schedule.
- It was also realized that there was the need for a regular reminder along with checking about state of progress and updating the rest of the team on such progress. So, the Project Manager had setup a weekly meeting with the workflow designer to discuss the state of progress and the deliverable, and figure out alternatives if there was a delay.

Lining up the support structure at the start of a cycle with firm commitments ..

During the course of a software project, you need the support of a number of people. For those who are not so well versed with the various challenges involved in project management, handling the support and resources from outside the core team are one of the biggest challenges during the early stages of the project, during the middle of the project, and during the later stages of the project; which only means that handling the various supporting teams is one of the biggest tasks during a project cycle.
So consider the starting time of a project. The features that are required for the project to succeed have been generated (including the trade off about the ones that are critical for the project vs. the ones that can be cut when there are schedule risks), and there is a need to ensure that there is a formal kick-off for the project. What do you do in a formal kick-off ? Well, one of the key items is to ensure that the team knows what the project is about, what are the key features that will be there in the project, and other such details. Typically the product manager will give a presentation to the team about the aim of the product, the market, the revenue earned by previous versions of the product and the target for the current version, and a high level description of the features that are sought to be included in the project. For many of these features, the further detail that the product manager can give is about how these features were derives, whether these be from competitor analysis or specific requests by customers, or generated based on ideas by the team.
However, as part of the initial kick-off, there are many other discussions that need to take place. For making the software development project successful, there is a lot of support that is needed from other teams. There are teams that prepare the build and the installer, there are teams that work on the documentation and help files, there are teams that deliver components that are required for specific functionality in the product, there are teams that work to translate the product in other languages. Most modern organizations have these kind of dependencies; it is no longer possible to have a situation where a single team does everything that is required for the team (for example, if you have a product that uses video formats, you would rather be using a common component that uses different video codecs to work with these formats rather than write code for working directly with these video formats (it may not even be possible to write code for all these video formats due to technical and commercial limitations)).
It is easier to ensure that you have the support of your core team and more difficult to ensure that all these supporting teams are providing the required support. For this purpose, before the kick-off, you would need to work with all these teams, providing them details about your requirements and the schedule in order to get a commitment from them (in some cases, where there is a clash due to priorities for support, you may need to escalate before you can get the desired commitment). In all cases, unless you can get the required level of support from these teams in terms of commitment, your project is already at a certain amount of risk that you will need to manage in one way or the other.

Open up the feature planning and tracking to the team for improvements ..

In the previous post on this topic (Risk planning by looking at confidence level of estimates), I talked about the difficulties posed due to discrepancies between the original estimates done at the time of planning, vs. the actual efforts spent on the work when the features are in development. Tracking these discrepancies and working out some kind of logic about these discrepancies is very important for the project manager. Typically, the estimation is done by the senior folks on the team while the person who works on a specific feature can be anyone on the team (if the work is specialized, then it would be allocated to somebody who has more experience in that area, but that person could still be different from the person who did the actual estimation).
So what do you do ? Well, you would typically track the estimation against the effort, and try to figure out whether there is some kind of logic. Sometimes, there is a possibility of generating some logic to figure this out. We had a case whereby the person who preparing the estimates had a person situation during the time that he was working on the estimations which was very distracting (but not enough that the Project Manager could figure out that here was a problem). So, soon after the actual work started, some data analysis about the discrepancies resulted in figuring out that the actual effort was about 25% more than the estimates where this particular person was involved, and this helped us in re-estimating the remaining features and also making a decision that a particular feature needed to be stripped down, the scope of the feature reduced for getting everything in the time frame.
However, what was interesting was that this logic was actually seen by a member of the team who pointed this out, and though it seemed a bit strange at first, more analysis helped. Some speaking to the people who had already worked on the features that this person estimated tended to confirm that they believed that the features were under-estimated. What this incident showed was that this provided us (the leads and the project manager) that we should get the team more involved with the risk planning and analysis that we do, such that sometimes it would be possible for them to identify a pattern that we might miss. There were other smaller cases that we could see.
One problem that was told to us before we started was that it was supposed that this would distract the team members from their regular work, and, many of them might not be interested in being involved in such kind of analysis. We did find people who were not interested, but we did start out with the entire team, making them involved with the process we did for identification of risk factors, gathering the data and then doing the analysis. About the time it took to do this, we figured that overall this would take an hour per week, but getting team members involved with stuff such as this would help give them a better perspective on some important processes that team leaders go through and when they could see the problem, they had a closer perspective on some of these risks and could figure out solutions for a percentage of these cases faster than we could. This helped save time overall, and after a couple of rounds, the people who elected to remain involved were appreciative of the learning they got from such exercises.

Developing a list of features for current and future versions of the product - Part 11

This is a series of posts that talk about the features that make up an application, and more importantly, the series of steps through which the list of features for the application are collected. There are a number of sources from which these list of sources are collected (in fact, it is important not to miss as many possible feasible sources as required). Once the list is collected, they need to be added to any sort of tool where the list can be consolidated, details added where required, and then the Product Manager can start ordering the list of features based on some specific criteria. In the last post (Developing a list of features for current and future versions of the product - Part 10), I talked about one way in which the features can be selected for the next version of the product, based on the product going in for a specific area of focus. So, there was a product that had social networking as the theme for the next version of the product, and as a result, those features were ordered higher in the list that had social networking as the theme.
This post will cover more such basis on which features can be prioritized and ordered for the next and future versions of the application. Another way in which features are ordered is by trying to group them into major and minor features. Typically, one of the major necessities of new feature development is to decide on a set of features that look cool, specifically those that look good at reviews. Now, these can be features that add on a major new set of functionality, or do something that can excite users. For example, if you have an application that provides remote control capability on a tablet, a cool new use could be to also to act as a controller for game devices such as the PS3 or the Xbox (now, this is just an example).
In the whole list of features that are available in the database, there will be many such features that are worthy of review and can excite user attention. A wise product manager would not like to add too many features in one go, but add a couple of such features for the next release, then save some for the next version, and so on. Adding too many in one release diminishes the focus on each of them, and also sets expectations for future releases that may be difficult to fulfill. Another important part of such a planning is about the resources for each such feature, and combined, the total resources required for developing and testing such features. Unless the resourcing for the application changes significantly from release to release, the amount of resources available per release will be around the same, and this also limits the amount of work that can be done for each release. In our experience, we always had time only for some new features, and some smaller features / modifications.
Doing some smaller features is important, since many of these are actually refinements of existing features and allows you to pass the message to your customers that existing features are also tweaked based on their inputs (and in fact, in many cases, you should be able to trace a direct path between customer feedback and the changes made in those features based on these feedback). Prioritizing some of these modifications should be done based on the critical nature of the feedback and the urgency of them. In many cases, these modifications are important for customer workflows, and this helps the Product Manager in doing the required prioritization.

Read more about how to do this prioritization in the next post (Developing a list of features for current and future versions of the product - Part 12 - TBD).

Developing a list of features for current and future versions of the product - Part 10

This is a series of posts on how to define a list of features that will be used for current and future versions of an application. If an application needs to be successful, it is important that the application have a great list of features that attracts reviews as well as users. For this purpose, it is important to draw upon a significant list of people and users who can generate a list of features based on their usage of the product, and then it is upto the team, primarily the product manager, to organize these features into a list that will be defined by the priority of the features and the way that these features are managed in terms of which feature will make it into the current version of the product, and which feature will be added to future versions of the product. In the previous post (Developing a list of features for current and future versions of the product - Part 9) I talked about how a tool was used to capture these features, and how the Product Manager would be able to use the tool to review the features and decide the level of detail that is required for each of these features.
In this post, I will talk about how the Product Manager will try and group these features together into a logical set based on the overall feature set planned for the product. This is much easier to do when it is decided to have the next version of the application feature a specific area. So, let us consider the case of a software that generates greeting cards, after giving the user a chance to upload specific image clips, or use stock photography that is made available by the application, allows the user to add details in terms of messaging as well as using pre-determined messages and various other features. The software would let users do all this and then enter email id and name of the person to whom they would send out the email to. Now, the makers of the software felt that their competitors as well as the market were getting focused on using social networking for sending these cards as well. So, once the user has made a card, it was not required to send the card only in a 1:1 situation (which is what email would typically do), but the software would allow the user to post the card on the Facebook profile of the person to whom the card was intended for more people to see; similarly, the card could be posted on Pinterest, or sent via Twitter, and so on. All of these are new age social networking features that were missing in the application.
So, now the overall thrust area of the release was there (there would always be some minor areas that were also present, but these were the broad areas that the product would focus on). For this purpose, the Product Manager would review all the features in the tool that are focused on social networking, get an initial list, and then do a quick prioritization of the features that seem the most important. This would be an initial prioritization, and in most cases, this initial list would be presented to senior management of the team for a review as well, and changes made if required after discussion. Thus, the final selected features from the list would be taken up, with a mix of major and minor features being there in the list (with the ones that are not selected having a note added about why these features were not selected, and some of them might get the tag about being rejected as well). Once this final selected list is available, the team can then use this list for further detailing.

Developing a list of features for current and future versions of the product - Part 9

This is a series of posts that detail the need for a product team to generate a list of features that can then be applied to the current and to the future versions of the product. Having a list of features that is comprehensive as possible is necessary to ensure that the product has the best chance to success. An important part of such an effort is to ensure that all possible sources of information regarding possible features that can make it into the product are obtained, for prioritization. This has been the focus of previous posts such as the last one (Developing a list of features for current and future versions of the product - Part 8). Since we had listed down a number of possible sources for features, we should start now trying to figure out some of the ways that this list of features can be prioritized for the current and future versions of the product.
So, how do we decide on how these features can be prioritized ? Well, the most important step is to decide on the kind of process used for documenting these features. Based on several teams and tools that I have been involved with, one of the most important conclusions that we came up with was to use the default tool that is used for feature collection to collect features for future versions, or to get it tweaked if the feature tool is not able to support features that will not be implemented in future versions. So, if you are using Scrum based development, ensure that the tool you are using for scrum is capturing all the features, and then you can start doing prioritizing and ordering of such features. Other teams have been comfortable using even a simple tool such as Microsoft Excel to capture the list of features and then additional columns to capture order, timeline and other such information needed for feature ordering.
Another important part of the overall process was about deciding the level of control over the tool and the process used for the same, which would also include the level of information required. In the process we had implemented, the Product Owner has overall authority and responsibility for the ordered feature list. As a part of that, there was a process (widely publicized to the team and to other stakeholders) where a new feature could be added to the overall list. At this time, it was also mentioned about the categories of information and the level of detail that was asked for, with some of this information being mandatory, and other information being on a good to have basis.
Once the information was added to this database, the process was that such information would be added to a new status called review. It was important to realize that unless any feature was approved by the Product Manager, the feature would not move into the prioritized list (although there was a weekly reminder to the Product Manager about ensuring that pending items were reviewed by the Product Owner). The Product Owner had the power to add additional people who were allowed to review the list along with the Product Owner (this was very useful when the list of such features was large, which was typically the case when the product was moving into a final stage of the schedule, or also when the Product Owner had sent out a request email asking people to enter details into the feature database).

This is turning out to be long, so will add more in the next post (Developing a list of features for current and future versions of the product - Part 10).

Developing a list of features for current and future versions of the product - Part 8

This is a series of posts that detail the need for a product team to generate a list of features that can then be applied to the current and to the future versions of the product. It can be said in a majority of cases that a weak feature set leads to the failure of a product; as a result, it is required that the feature team and product management spend as much time as possible to ensure that all possible sources of feature requests have been looked at to determine a possible list of features for the product (for current and future versions of the product). In the previous post (Developing a list of current and future versions of the product - Part 7), I went into details of how to generate a reward based method of getting feature requests from customers and others. I will add more details of more sources for getting features and adding these to the overall feature list for prioritization and development.
We have already looked at many sources for the product. Some of those sources are people who are pretty familiar with the product and hence may have already run out of ideas (these are typically people such as the product managers, the team and a number of traditional customers). What is required is the provisioning of fresh people to look at the product and generate ideas for features based on somebody looks at things fresh. Well, where do you get such fresh people from ?
Every release there are new customers who are introduced to the product, and some of them will be of the form that they will have an opinion. You need to mine such people for getting information on where they feel some features of the product need improvement, where their work flows are not being met, and equally importantly, which are the features that would be great in the product, and are not present (these may or may not be present in the feature set that competitors have).
There are many ways to get information from customers, and we have talked about some of those ways in previous posts. Another way is to set out a survey which attempts to reach out to new customers, and asks them about which features they need help on, and other questions that will help in generating data related to which features need improvements, and which are the new features that need to be present in the product.
Another set of sources is in terms of vendors. In today's model of software development, there are many teams that will be using external vendors (in addition to the core development and testing teams) for a variety of needs; some companies have totally hived off their testing processes to external vendors, other use them for converting the software to different languages, and preparing help / documentation about the product. A number of these will be people at the vendor's end who have not worked with the product before, and they can provide some fresh ideas about what worked with them, and what did not work. Doing this on a regular basis, when they are getting some training on the product, and also when they are involved with actual work is important. The problem is, if the development team is working with these vendors, they tend to dismiss feature ideas or workflow queries from these vendors, instead of evaluating them to see whether these queries could actually work out to be feature improvements or new features.

In the next series of posts, I will talk about how to organize these features, and put them in a form that they are useful (Developing a list of features for current and future versions of the product - Part 9 - TBD)

Developing a list of features for current and future versions of the product - Part 7

This is a series of posts on how to resource a collection of features for the current and future versions of the product, develop these features, and then prioritize these features such that a list of such features can be laid before the team. Once a list of features has been generated, reviewed, necessary details added and dependencies evaluated, they form the basis for the future development of the product. However, it is critical to ensure that the feature list is formed after an extensive evaluation of all possible sources. This series of posts has been concentrating on how to obtain features from different sources, with the previous post (Developing a list of features for current and future versions - Part 6) focusing on getting a list of features and feature modifications / additions from the team members. Team members are very close to the product and can provide a lot of incremental improvements, and with their study of competitors, can also suggest features that it would be useful for the product to add. This post will look at another source from which features can be suggested (and keep in mind that even though some of them may sound odd, generating even a couple of features based on a new source can be very useful).
In a previous post, I had suggested using surveys and also collecting information based on customers usage of various features in the software. This post takes a more specific instrument to collect features; basically a contest that asks customers and others to suggest the most useful features that a product can have. This is a new avenue that has shot into higher profile in the past couple of years, and I have seen it adding a few more features to the existing list of features for a product, overcoming the skeptical nature of the team and the product manager. It is a bit hard to ensure that the team management and the product manager are exploring new avenues for generating a list of features; normally they would already have a list of features from previous such exercises, and after looking at some competitors, they would feel that they already have a good list of features and don't really see the need for looking at fresh sources of generating features (which would help in refreshing and re-prioritizing the existing list that they already have).
In the recent past, I have seen some organizations and products trying to use crowd-sourcing (god, I hate using buzz-words) as a way to generate a list of features for the product; and when you add a prize at the end, it can turn out well. So, the simple way to go about this would be:
1. Prepare a timeline for how long do you want this exercise to continue, when would start informing people and when you would end the process of collecting the list of features
2. Define whether there are any selected categories in which you want features (this can be helpful when there are certain areas of the product that you feel that you are weak in)
3. Define the level to which you want people to prepare the features that they are submitting - something like a top level definition, or a more detailed description in which they define the entry points into the feature, the processing in the feature, and the exit points from the feature
4. Define the prizes that top contributors will get, and also define whether you need to get more information from these contributors during the time period that the feature development work is happening; also define more aspects about whether there is the need to have agreements such as a Non Disclosure Agreement in the same time period.
There will be many more details during the planning of such an exercise, but these are the top level details that you should be looking at while starting an exercise to obtain features from people.
Once you get such a program running, there is a good chance that you get atleast a couple of features concepts that have not been thought through from other sources and which can be useful for your product. And in the end, if you have decided that you will take one or more such features in your product, be sure to advertise the feature and also get the contributor (if he or she has been happy with the interaction with your team) to be part of your coming out exercise of the product.

Read more about generating a list of features in the next post (Developing a list of features for current and future versions - Part 8)

Developing a list of features for current and future versions of the product - Part 6

This is a series of posts that talk about developing a list of features for the software product. One of the major factors that determine whether a product is successful is having the right set of features, and getting the right set of features is not an easy task. It takes a lot of effort for ensuring that you have the right set of features, and the team and product manager should ensure that they do their best effort for preparing the list of features, and then prioritize them according to the features that should be incorporated in the current version, and those that should be kept for the next versions of the product. Once you have a list of features, you can spend time on prioritizing it for the current and future versions of the product. In the previous post (Developing a list of features for the product - part 5), I talked about how to get feature ideas from the reviewers of the product, from their experience of seeing multiple products trying to attract the same set of customers. This post will continue in the same and talk about more areas where feature requests can be generated, and added to the overall list.
One of the biggest sources of information about features (and yet one that should be considered with a lot of thought) is the development team. Day in and day out, the team is working on the product and they get a very detailed idea of what the product is like, what are some of the shortcomings of the product, and what are some of the features that are built solidly. In our teams, it invariably turned out that atleast 15% of the features that were done in a release were built based on the feedback from the team, collected from them at regular intervals of time. Doing so also increases the morale of the team, ensures that they are fully committed to the feature set of the product and to the features (the managers of the team may feel that it is not necessary to do so, since the team would anyhow be committed to the product, but you would be surprised at how such steps increases the level of involvement of the team in the future of the product).
How do you collect these features from the team ? On a regular basis, the product manager of the product should do brain-storming sessions with the team, and should also have a repository where the team members can add features, add more details to these features and even build upon these by adding use cases and examples. Such avenues can lead to some incredible feature ideas, that the product manager would not even have thought about; even though many of them would be like feature improvements rather than new features (but as we have discussed before, feature improvements, if they are big enough changes, can be almost like new features). The team, while working on the product, would have noticed many areas where the workflow could be improved; competitor analysis shows them where a feature could be modified to seem like a feature that the competitor has; their interactions with customers would show them where there can be improvements to the features and what the paint points are.
At the same time, the product manager should ensure that these feature requests from the team are seen as requests from somebody who is very deeply involved with the product (a lot of people would argue that the team is too involved and too biased in certain ways), and hence there needs to be a lot of filtering and some amount of modifications before those features can be added to the feature list. This is something that the product manager should ensure that the team has understood.

Read more about processes of collecting feature requests in the next post (Developing a list of features for current and future versions of the product - Part 7).

What are Software Process Improvement resources?

A supportive and effective infrastructure is required for facilitating the coordination of various activities that place during the course of the whole program. In addition to these qualities the infrastructure should be quite flexible so as to be able to support the changing demands of the software process improvement with time. 

Resources for this program include:

1. Infrastructure and building support
2. Sponsorship
3. Commitment
4. Baseline activities
5. Technologies
6. Coordinate training resources
7. Planning expertise
8. Baseline action plan and so on.

- When this program is initiated, a primitive infrastructure is put in to place for the management of the activities that would be carried out by the organization under SPI. 

- The resources mentioned above are also the initial accomplishments that tell how well the infrastructure has been performing. 

- It is the purpose of the infrastructure to establish a link between the program’s vision and mission, to monitor it and guide it and obtaining resources and allocating them.

- Once the SPI program, a number of improvement activities will be taking place across the different units of the organization. 

- These improvement activities cannot be performed serially rather they take place in parallel. 

- The configuration management, project planning, requirements management and reviews etc. are addressed by the TWGs (technical working groups). 

- But all these activities are tracked by the infrastructure.

- Support for the following issues must be provided by the infrastructure:

1. For a technology that is to be introduced.
2. Providing sponsorship
3. Assessment of the organization impact

- As the program progresses, the functions to be performed by the infrastructure increase. 

- There are 3 major components of the SPI program:

1. SEPG or software engineering process group
2. MSG or management steering group
3. TWG or technical work group

- It is third component from which most of the resources are obtained including:

1. Human resources
2. Finance
3. Manufacturing
4. Development

- However, the most important is the first one and is often called the process group. 

- It provides sustaining support for the SPI and reinforcing the sponsorship. 

- The second component i.e., the MSG charters the SEPG.

- This is actually a contract between the SEPG and the management of the organization. 

- Its purpose is to outline the roles and the responsibilities and not to forget the authority of the SEPG. 

- The third component is also known as the process improvement team or process action team. 

- Different work groups created focus on different issues of the SPI program. 

- A software engineering domain is addressed by the technical work group. 

- It is not necessary for the TWGs to address the technical domains; they can address issues such as software standardization, purchasing, travel reimbursement and so on. 

- The team usually consists of the people who have both knowledge and experiencing regarding the area under improvement. 

- The life of TWGs is however finite and is defined in the charter. 

- Once they complete their duties, they return back to their normal work. 

- In the early stages of SPI program, the TWGs might tend to underestimate the time that would be required for the completion of the objectives assigned to them. 

- So the TWGs have to request to the MSG for allotting them more time. 

- Another important component could be the SPIAC or software process improvement advisory committee. 

- This is created in organizations where there are multiple functioning SEPGs. 

What are Six Best Practices in Rational Unified Process?

The IBM Rational Unified Process is a means of commercial deployment of the approaches and practices which have been proven for the development of the software systems and applications. It is based up on the following six best practices:

1. Iterative development of the software systems and applications
2. Management of the requirements
3. Use of architecture based up on the components.
4. Visual modeling of the software system
5. Verification of the software system.
6. Controlling the changes to the software system or application.

The above mentioned practices are called the best practices not because their value can be precisely quantified but because they are quite common in the software industry by most of the organizations which are successful and reputable.

In the rational unified process each and every member of the team gets templates, guidelines as well as the tools which are found necessary for the whole of the team in order to reap the full advantage.

Basic Practices In Rational Unified Process in Detail

Iterative development of the software systems or applications:  

- Software systems and applications are quite sophisticated and therefore they make it impossible to define the problem first in sequence.

- By sequence we mean, first defining the whole problem, designing a solution of the problem, building the software system or application and then finally testing the software system. 

- In order to deal with such software systems and applications there is a requirement of an iterative approach so that an increase in the understanding of the problem can be made in a series of successive refinements. 

- This also helps in developing an effective solution in increments done over multiple iterations.

Management of the Requirements: 

The rational unified process gives a description:

- On how the elicitation, organization and documentation of the constraints as well as the functionality is to be done, 

- how the trade-offs and decisions have to be tracked and documented and 

- how the business requirements are to be captured and communicated.

Use of architecture based up on the components: 

- The focus of the development process is on the base-lining and early development of an architecture that is robust and executable as well. 

- It gives a description of how a resilient architecture can be built with more flexibility that can accommodate the changes easily, can be easily understood and effectively promotes the reuse of the existing software artifacts. 

- The rational unified process provides a great support to the component based development. 

- By components we mean, the sub systems and non – trivial elements for a clear function.

Visual modeling of the software system: 

- The rational unified shows you exactly how a software system or application can be visually modeled and can be used for capturing the behavior and structure of its architectural components. 

- This further enables you to hide the details and develop the code with the help of the graphical building blocks. 

- With such visual abstractions, communication can be established between the different aspects of the software system or application.

Verification of the software system: 

- Poor reliability dramatically cuts down the chances of a software system or application from being accepted.

- Therefore it is important to review the quality concerning the factors namely functionality, reliability, system performance and application performance etc.

Controlling the changes to the software system or application: 

- The management and ability to track the changes are critical to the success of any software system or application. 

- However, the rational unified process helps you to cope with these issues also.

What is website usability testing?

Since the past few years the growth and usage of the web sites which are both free and paid had risen rapidly. In other words, we can say that the usability of the web sites has witnessed a massive growth. With the rise of usage of web sites and web applications, it is obvious that the demand for the web site usability testing also increases! 

Now you must be wondering what actually is web site usability testing? In the earlier times, it took expensive recruitment labs and a large amount of time and deployment to carry out the web site usability testing. Since the advent of the web site usability testing tools, the whole process of testing seems to be so smooth and so under control. 

In this article we have discussed about web site usability testing. You might be thinking that why it is necessary to carry out web site usability and what good it does to the web sites and web applications. 

- The web site usability testing contributes as an essential element of the quality assurance of the web site or web application under the testing. 

- Web site usability testing can be considered to be an exact, actual and true test of how a web site or web application is actually being used by the end users.

- Web site usability testing  becomes quite easy when you know how to do it and also quite cheap when you are going to carry it out yourself. 

- Web site usability testing involves checking the following aspect of the web sites and web applications:

1. It checks if the web site or the web application is being used by a series of individuals under some guidance from a facilitator.
2. It checks whether or not the web site or the web application can be successfully used by the outsiders.
3. It checks if the web site or the web application is focusing only on a particular group.

There are some common terms associated with the web site usability testing that we are going to discuss now:

1. Observer: An observer is the person in charge of the observation of the of the test that is in progress and he/ she often sits in another room.
2. Facilitator: He/ she is the person in charge of the guidance of the user while the usability test is under progress and takes relevant notes.
3. Owner: Owns the web site or the web application.
4. Web site development team: This team constitutes of all the people who are involved with the development and maintenance of the web site or the web application. It includes the following:

a)    Strategy group

b)    Programmers

c)    Designers

d)    Stake holders and so on.

5. User: The person who uses the web application or web testing during the usability testing.
6. Usability: It can be thought of as a measure up to which the intended user achieve his/ her goals using the web site or web application that is under test.

Testers usually take a whole one whopping big usability test which makes the whole testing process quite clumsy rather than breaking down the testing process in to little parts and then executing them. 

There are 5 appropriate timings for carrying out the web site and application testing as mentioned below:

1. At the time of the conception of the web site you can start by testing a printed mock up of the home page of the site.
2. Before a re development plan is created.
3. Repeatedly during development.
4. Whenever an anomaly shows up in a traffic analysis.
5. When the owner of the web site calls for some info regarding his web site or web application. 

What is a scrum process and how does it work?

To implement the scrum development process, it is important to know how it actually works. Most of the errors in the development occur because of the lack of knowledge about the working process of the scrum. 

Scrum works on the principle of iterative and incremental development and it operates with the help of two types of roles namely:

1. Core roles:

(i)                Scrum master

(ii)              Development team

(iii)            Product owner

2. Ancillary roles:

(i)                Stake holders and

(ii)              Managers

What is a scrum process?

- The scrum process deals in terms of sprints which are usually called iterations for the other agile software development processes. 

- In a typical scrum, a sprint may have duration of a week to a month. 

- Scrum is facilitated by various meetings which have been mentioned below:

1. Daily scrum: 

This meeting is held during the sprint and is based up on the project status. Usually the core roles participate in this meeting. This meeting is time boxed to 15 minutes.

2. Story time (back log grooming): 

This process involves the estimation of the existing backlog and the acceptance criteria for the user stories is also refined. These meetings are time boxed to an hour.

3. Scrum of scrums: 

This meeting follows after daily scrum and is somewhat same.

4. Sprint planning meeting: 

This meeting is held before the beginning of every sprint and the tasks that have to be completed within that sprint are selected.

5. Sprint review meeting: 

It reviews the status of the sprint and also the tasks that could not be completed.

Principles on which working of scrum depends

The scrum follows the following three principles throughout its working:

1. Working software is more valuable then the documentation.
2. Response to the changes in requirements is more important than the plan.
3. Team collaboration is important than contract negotiation.

How does a scrum process work?

- Usually the first few weeks of the scrum are spent working out the high level requirements including business needs and system architecture. 

- After this, the team produces the product backlog and sprint backlog. 

- These two backlogs together make the scope of the software project by the end of the week. - All the team member themselves take up the responsibilities and operational activities from each other during the daily meetings. 

- At the end of some sprints, it happens that some of the tasks could not be completed as planned so they have to be included in the next sprint in addition to the other tasks. 

- One of the reasons for such situations is the “scope creep”. 

- However, this does not turns out to be a real issue especially when the team is working closely with the business owners who have good understanding of the development process going on. 

- It should be understood that the scrum is a framework rather than just being a full methodology. 

- A detail of everything that is to be done is not provided by the client since it is decided by the team itself.

- At the end of the sprints the coding, testing, integration of the features is done. 

- In the sprint review, the newly added features to the software are demonstrated to the product owner. 

Reasons why scrum works well

There are several reasons why scrum works and few of them have been mentioned below:

1. Iterative nature.
2. Re assessment of priorities between iterations.
3. The old check points are discarded when the team is doing something new.
4. Availability of the product owner.
5. The development team works on a single project at a time.
6. The team has a chance to co- locate the entire development process.

When should scrum be used and when should it be avoided?

There are conditions and situations encountered while the development of a software system is in process in which only one specific development methodology can be implemented! 

It does not mean that any software development methodology can be implemented any time and any where! This holds true for all the software development methodologies and so for scrum too! 

In the recent years of the use of the scrum development method, it has been observed that many developers and programmers have faced problems while implementing the scrum in the development process of their software product, project or application etc. The nature of the scrum development methodology should always be kept in mind while implementing it. 

What is Scrum Methodology?

- Scrum represents a light weight agile process frame work that primarily finds it use in the management of the software development process. 

- The scrum has been recognized under the category of light weight agile process frame works since it involves the use of very few elements, 3 core roles (namely the scrum master, development team, product owner) and three main artifacts (namely sprint backlog, product backlog and burn down chart). 

- With scrum, the rate of response to the ever changing needs of the customers is improved. 

- Scrum cannot be called as a mere process but a frame work since it is composed of several concepts and practices that together can be used to build several combinations of processes.  

- The iterations in a scrum process are cyclic in nature i.e. the iterations are repeated in every few weeks. 

- The requirements are supplied by the product owner as the user stories. 

When should scrum be avoided?

There are cases in which the scrum should be avoided! They have been mentioned below:

Case I: 

Implementing scrum in a problem for whose domain it is not compatible and

Case II: 

Implementing scrum in a development processes whose processes are against that of the scrum principles.

Case III: 

When the development processes of an organization works actively or passively against the principles of the scrum, then the scrum cannot be fully used here. 

Case IV: 

The scrum spirit is also threatened whenever a faux scrum is implemented by the company.

Case V:

Scrum can go wrong when the company involves too many people in the development process of so many projects! This phenomenon is called matrixing.

Case VI:

When the teams cannot commit to a fixed scope of work during a week, the scrum can not be implemented for that project since the scrum processes demand commitment. 

When should scrum be used?

There are cases in which scrum is used. 

Case I:

Scrum can be used well till the company is not bothered about the process that is being used at the team level and is not against the scrum values. 

Case II:

Also implementing scrum in a holistic way is itself an art and requires faith in scrum development process. 

Matrixing at the level of the scrum master is somewhat ok but may pose as a hindrance in the way of scrum. Matrixing is ok as far as the people involved in it have high knowledge and IQ levels. 

Usually teams like production support, network support and so on encounter this kind of problem with scrum. You should be careful while fixing the scope since if it’s too much for the team than your team can experience some serious dysfunction. In some cases if you are advocating for scrum, it may prove to be a disaster for you lest you know how to embrace it!