Learn Software Development » Change

Learn about Scrum – Why does Scrum fail – Dealing with a team that was hesitant, and it worked only after people actually were changed

ashish — Thu, 15 Jul 2010 18:51:14 +0000

If you look at the title of this post, it does not mean that we convinced the people to change; it actually meant that in some cases, people were encouraged to leave for a different group, or when they decided to leave the company, they were not stopped. This seems rather drastic, but it turned out to be the right thing to do. This was another example (from thankfully not my present organization, but from a previous organization) of how Scrum gets labelled a failure in some cases even though there are other reasons for the problems.
Consider the case of a group with a number of senior and experienced people. They are used to their own way of doing things, going off to work for complicated items, being social only when they want to be, but otherwise pretty skilled people. You would not want to lose such people. At the same time, it is also true that sometimes people can be very skilled, but can lead to making or breaking of teams, and you need to get rid of people who can spread problems in the entire team. So, you had a team with many of such people, and things were working fine. However, overall, there was a realization by management and by leaders of the group that productivity was not what it should be, and predictability was something that was a problem. It seemed that even with such skilled people in the team, one would never be clear about what the current status of deliverables is, and whether the project was on the right track was difficult to measure. Replacing the project manager did not help in any way, and the introduction of new ideas did not seem to help.
So, with all the word of Scrum in the air all around us, it seemed that this was the way to go. However, we did not just jump into Scrum; the management of the team went in for training and for intensive Q & A, and worked out the changes, what are the advantages, and what would it do to the normal way of life. And it seemed like some sessions with the team, followed by Scrum training and some simulation exercises should get the team on the right path.
Initially it all seemed to be going fine, with everybody seeming to appreciate the providing of more information and access to the Product Manager, but just when it seemed to be settling in fine, the basic inertia of many members of the group seemed to have overcome whatever advantages. Cribs about the Daily Scrum meetings, jokes about daily reciting of past / present / future (the 3 basic concepts of the Daily Scrum meeting) and so on started causing problems in the team. It was fairly easy to identify the people who were starting to come unstuck, and some counselling seemed to work, but only for some time. It got fairly problematic that the regular activities of the Scrum team starting getting vitiated. Radical solutions were prescribed, and this meant the introduction of more Scrum oriented senior members from other teams, giving the message to many of the difficult folks from the existing team that they really should start working as committed team players, or they would need to start looking out. This radical therapy worked wonders, but is not really practical in many situations (you cannot easily bring in new experienced members so easily).

Learn about Scrum – Why does Scrum fail – There is the reluctance to allow the team to be self-empowered and modify some processes for their betterment

ashish — Fri, 02 Jul 2010 12:26:16 +0000

In the previous post (Team not being ready), I talked about how in some cases, the team has not been properly positioned into Scrum, and as a result, have not understood the benefits; and in some cases, they are introduced to an implementation of Scrum without the required training or at a time of stress, and cannot adequately benefit from Scrum (in fact, at such times, it is very much possible that what they are experiencing is not Scrum per se, but a process whereby the strains have caused people to modify the process into something that apparently gives them more control).
In this post, I will talk about an important part of what makes Scrum successful, the ability to give the Scrum team more power and more empowerment, and the effect that this has on the regular managers in the team. This was struck during a conversation between 2 managers who are part of the organizational structure in a team that is implementing Scrum, one of whom is also the ScrumMaster, and the other who is the manager of all the development people in the Scrum team. The net problem was what one of the managers told me: “I believe my responsibility is to be more of a coach rather than the conventional manager role that we see in software development processes”. I totally agreed with what the person told me, and the problem was not in this statement; it was that this manager believed that the other managers in the team had not got this, and it was difficult for them to give the kind of independence that the team desired.
One key effect was seen whenever there was something like an introspection, or a retrospective, whereby team members would suggest some modifications in the process, or in the technologies or designs used, and this would conflict with the views of the senior team members of the managers. Any of these more senior people would use slightly more forceful language or a sharp response (inspite of earlier discussions that they needed to let the team take more authority, and act in the nature of a coach, so that if some view was not practical or workable, the discussion would make that fact come out); using such a tone would effectively shut down the person who would be making that comment, but when later questioned, the person would admit that such an exchange of opinion seemed to be different from the practices of Scrum that was taught to them during the training, and it was difficult for them to reconcile such differences. Many of them understood that the managers did not easily want to give away authority, and this was fairly consistent feedback.
To correct this, we are now doing more training sessions for the managers to get them more accustomed to their roles as a coach who needs to get the team more empowered and ensure that the team feel comfortable in getting more improvements into the process.

Burn Down chart and a change in scope that impacts the burn down chart

ashish — Thu, 11 Mar 2010 17:41:19 +0000

In the previous post (Burn Down Chart), we talked about what a Burn Down Chart is, and how you can use it to get the current status of the project, while not using it as a way of judging the performance of the team. This is because there are many variable that can impact the team, with one of them being changes in scope of the features that are included in the current Sprint cycle.
Typically, if you find that while viewing the burn-down chart that the amount of time available is not enough to do the required number of features / tasks pending, then there are multiple reasons that could cause this. One of the primary reasons is the changes in scope of features in the current Sprint. At the start of the Sprint cycle, when the Sprint Planning was happening, the team would have made estimates based on the user stories (and broken down tasks) defined at that time. Over the duration of the Sprint, there could be inaccuracies in estimates, but as you get a more experienced team, they get better at planning and estimating, and thus the amount of inaccuracies get reduced.
The other primary reason is changes in scope, but how do you show those on a burn-down chart, since the burn-down chart is one of the most used and primary means to determine status in Scrum. One way is to recalculate the chart based on the revised feature scope (although this would mean that the number of features you can do will reduce to account for this increase in scope). Keep an earlier version of the Burn Down chart handy since this helps in forming a sort of baseline.
Another way is to use the Burn Up Chart (refer this location) by Alistair Cockburn; where you can see progress and earned value. The burn-up project shows another line that depicts the total workload for the project, and this can be modified to show changes in scope. If there is no change in scope, then the line remains flat, but if there is an increase in scope, then it is pretty clear that there is an increase in scope, and hence, anybody viewing the graph can quickly make out the difference that the changes in scope have made to the entire project; consequently, the impact on the effort of the team and the amount of work that can be done in the remaining time.
Another thing that the ScrumMaster can do is to take a note of the changes in scope for the tasks as these changes become clear; Scrum is geared towards being as Agile as possible, but in the retrospective, it is always good to review these changes in scope to see which ones are coming because of changing requirements, and which ones are coming because of items that could have been clear earlier in the cycle (these need to be improved upon).

Overview of Change Management – Software configuration management

ashish — Fri, 18 Sep 2009 17:57:21 +0000

Software configuration management is an umbrella activity that is applied throughout the software process. SCM identifies, controls, audits, and reports modifications that invariably occur while software is being developed and after it has been released to a customer. All information produced as part of software engineering becomes part of a software configuration. The configuration is organized in a manner that enables orderly management of change.

The software configuration is composed of a set of interrelated objects, also called software configuration items, that are produced as a result of some software engineering activity. In addition to documents, programs, and data, the development environment that is used to create software can also be placed under configuration control. All SCIs are stored within a repository that implements mechanisms and data structures to ensure data integrity, provides integration support for other software tools, supports information sharing among all members of the software team, and implements functions in support of version and change control.

Once a configuration object has been developed and reviewed, it becomes a baseline. Changes to a baselined object result in the creation of a new version of that object. The evolution of a program can be tracked by examining the revision history of all configuration objects. Basic and composite objects form an object pool from which versions are created. Version control is the set of procedures and tools for managing the use of these objects.

Change control is a procedural activity that ensures quality and consistency as changes are made to a configuration object. The change control process begins with a change request, leads to a decision to make or reject the request for change, and culminates with a controlled update of the SCI that is to be changed.

The configuration audit is a SQA activity that helps to ensure that quality is maintained as changes are made. Status reporting provides information about each change to those with a need to know. Configuration management for Web engineering is similar in most respects to SCM for conventional software. However, each of the core SCM tasks should be streamlined to make it as lean as possible, and special provisions for content management must be implemented.

Changing requirements and implications on testing

ashish — Wed, 04 Feb 2009 17:58:12 +0000

An ideal software development cycle involves a process whereby the requirements are frozen pretty early and the entire cycle happens with those frozen requirements. And if requirements do need to change, then a major impact analysis needs to happen, and the change is thoroughly studied before any change is taken. However, in the real world (and something that is increasingly acknowledged by incremental and Agile software methodologies), requirements can and do change and it is better for the software industry if there is a lot more effort put in to figure out how to incorporate the world of changing requirements. One of the folks impacted by changing requirements are the testing team, and once should evaluate how they can respond to such changing requirements. Let us start off by calling it a common problem and a major headache, and then work out what we can do. Here are some steps:
• Work with the project’s stakeholders early on to understand how requirements might change (stakeholders have a much better idea on whether the requirements are fully known and stable) so that alternate test plans and strategies can be worked out in advance, if possible.
• It’s helpful if the application is initially designed in a manner that allows for adaptability so that later changes do not require redoing the application from scratch, or at least minimise the amount of effort required for change.
• Coding practices of commenting and documenting, if followed religiously, makes handling changes easier for the developers.
• Another way to minimise the need for changing requirements is to present a prototype to the stakeholders and end users early enough in the cycle. This helps customers feel sure of their requirements and minimize changes.
• The project’s initial schedule should allow for some extra time commensurate with the possibility of changes. Better to build such a time in the schedule.
• If possible, and if there is some amount of flexibility in negotiating relations with the client, try to move new requirements to a ‘Phase 2′ version of an application, while using the original requirements for the ‘Phase 1′ version. This however does not work if the changes affect the workflows directly.
• Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application. This should be possible if there is a good change control process in the project.
• Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. This is typically done by delineating a proper change control process and explaining this to the stakeholders along with examples if necessary. Only after this, let management or the customers decide if the changes are warranted.
• Changes have a major effect on test automation systems, especially if there is a change in the UI of the application. Hence, you need to be sure that the effort put into setting up automated testing is commensurate with the expected effort required if there is change which causes re-doing of the test effort.
• Try to design some flexibility into automated test scripts. Not easy, but if you have initial ideas of change this should be possible.
• Focus initial automated testing on application aspects that are most likely to remain unchanged. This ensures that later test automation effort is done when there is some stability in the requirements.
• Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
• The last plan may seem very strange to a test manager. Focus less on detailed test plans and test cases and more on ad hoc testing; keep in mind however that this entails a certain risk.
Overall, when requirements are changing, teams also need to be more flexible to respond to such changes.