Learn Software Development » Engineering

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Mon, 20 Dec 2010 19:08:30 +0000

I have been writing a series of posts that talk about how to improve the Velocity of a Scrum team, through getting rid of various items that can reduce the Velocity of the team, as well as steps that can improve the efficiency of the team (How to improve the Velocity of the scrum team). In this post, I talk about some of the dependencies that can cause problems in the efficiency of a team, along with examples of how the efficiency gets reduced.
We were working on a product which used some components provided by an external third party, and these were integral components. We could not avoid using these components since they provided us a functionality that was required for our product to work, and we did not have the time or the budget to produce these components ourselves (and it would not have made sense since we did not want to get into the business of assigning resources and supporting the functionality that this component provides).
However, we did know that we had a dependency and which could have some impact on our product schedules. We planned for tasks that entailed incorporating the component, dedicated the required amount of time and effort to integrate and fix any integration related bugs, and so on. Further, we had some team members who had experience in this area, and asked them to work through the required estimates for these tasks.
So, we were all set, and believed that integration this component would be a breeze. However, when we integrated this component, there seemed to be a problem. We usually would get a few bugs that were related to integration and some impact on our product, but in this case, there seemed to be a major problem. The integration resulted in a product that was far more shaky, and as a result, we had a lot more bugs suddenly found that seemed to be much more than what was normal. The tasks related to integration of the component took far more time, since there needed to be a large amount of time being spent on investigation and coordination with the vendor, and of course, the resultant bugs that were far more numerous.
It took us 2 more people dedicated to an extra week just to do another integration of the component after the bug fixes, and this had an incredible effect, since with a 6 member team, a large amount of work that was planned for that Sprint did not get completed, and this led to an unhappy Product Owner and senior management. The only solace for us was, that due to this impact, we were able to generate sufficient pressure to force the vendor to adopt a more thorough QE cycle; but for us, the amount of Story Points completed in this cycle were far less than what we had expected; this also set the ground for a far more interesting and detailed retrospective.

Problems with a Scrum process in terms of being able to solve dependencies on other teams

ashish — Fri, 02 Apr 2010 17:37:50 +0000

A scrum based method of development enumerates that a team works on features on the basis of Sprint cycles, and takes up feature definition close to the actual time period of the Sprint. What this means is that for a typical team that used to work on a Waterfall model whereby the features to be done in the entire cycle were decided in the beginning of the cycle, working on a Scrum cycle is a distinct change whereby the features that can be done by in the entire period of development cannot be defined at the start of the period. What this means is that if the team is working on a total time period of their version development (say for version 7.0) running from Jan to October 2010, and they have decided that their Sprint cycles are one month each, then in Jan 2010, it is difficult to define the total list of features in January 2010.
One practical example is when teams are dependent on each for their features. Consider the case which happened to our team, whereby we were working on a cycle that ended near November 2010. For some of our features that we were implementing starting approximately in March 2010, we needed the other team to deliver a core piece of technology just before we started the feature work (so our target was to receive the technology from the other team by end of Feb 2010); and such inter-dependencies between teams is fairly common in large software companies.
In the normal case, what would happen is that before we started our development work around December 2009, we would have contacted the other team and got a commitment from the team about their being able to provide this technology to us by end of Feb 2009. However, around sometime late last year, the team moved to using Scrum as a development methodology, and so when we went to them with the request for giving a commitment of support in December 2009, we were told that under their Scrum model, they would not be working on this feature till near the end of Jan 2010, and it is only then that they would start to get into feature definition, estimation, as well as final prioritization of the list of features. This caused a large number of problems to us since we were not able to commit to our features because of the dependency not being confirmed.
Such an approach causes problems in the case of companies where feature teams interact with each other for inter-dependencies (fairly common with different teams developing their core components which can then be used by other teams – this is an efficient system of dependencies). To solve this, teams will need to make some changes to their implementation of Scrum, whereby for teams that depend on them, they will have to do some initial level of working out their feature lists right at the beginning, and then provide the required level of commitment.

Advantages of using Scrum (contd..)

ashish — Thu, 29 Oct 2009 10:02:27 +0000

A couple of posts back, I had mentioned about some of the advantage of using Scrum as a project execution methodology, and this post is a continuation of that description.
- You get a person to play the role of one who ensures that the team is following the processes as they are supposed to be done, and this person is the ‘Scrum Master’. The Scrum Master is the one who looks at the processes being followed, and ensuring that people are following the rules of Scrum. The biggest problem with the enforcement of any development process is that people start deviating from that when they are under pressure. A Scrum Master watches over the entire process, and ensures that people are following the rules and practices.
- Since one of the expectations from a Scrum cycle is that the software should be working at the end of the cycle, there are improvements in the quality of the deliverables
- Typical feedback from teams that are implementing Scrum (after the first couple of Sprints, when the team has settled down and ironed out some of the kinks from the system) is that Scrum increases the predictability of work, reduces the times when they are working in an all-out deadline induced panic reaction
- You would be surprised as to how much a short 15-20 minute daily meeting can help in avoiding those long 1-2 hour meetings where the entire team would sit and discuss a feature threadbare, including those features which you would not end up implementing.
- A meeting with Dev and QE in the normal processes can be tense since people try to cover their own asses first; however, when you put them together in a Scrum kind of meeting on a regular basis, they can get far more involved in the feature and less about covering for themselves
- As you get more face to face communication in a short daily meeting, the formality that comes through an email response (where there may be many more people in the meeting) reduces to a large degree, and the discussion can happen onto more relevant points
- In Scrum meetings, dev and QE from other features get an idea as to what is going on in other features (use stories), and so they are able to quickly jump in if there is an emergent need
- How many times have you seen that the team is working on a feature, and they go to their manager for a decision, and that is to be expected, since in the normal development cycle, the team really does not have much empowerment. However, in a Scrum type model, the team can quickly take decisions and then inform people once this has happened
- The project manager and leads spend less time on preparing stuff such as status reports (and collecting information for a status report is an activity by itself). You can spend time in more useful areas.

As in the first part, the benefits that I can outline will spill over into a 3rd post.

Learning about scrum through a video

ashish — Tue, 27 Oct 2009 13:52:02 +0000

Scrum is a project management technique, one of the Agile development technologies. It is a fairly more recent technology, and has been increasingly adopted by more companies. There is a concept that scrum is meant for smaller teams, but it is erroneously thought that larger products cannot be built with scrum. For a scrum team, the size needs to be optimal (and I have found that 8-10 members are optimal for such teams in my experience), and so a larger product team can be broken down into smaller scrum teams. However, scrum seems so different from waterfall (even though waterfall is a development methodology) that people who are using Scrum really should have proper training. You need to learn about the different terms such as backlog, Sprint, burn-down charts, daily scrums, and learn the meaning of what a scrum master, what a Sprint team does, and how the teams integrate to form a much closer team.

SCRUM in Under 10 Minutes (HD)

System Engineering

ashish — Sun, 25 Oct 2009 05:59:49 +0000

Systems Engineering is an interdisciplinary process that ensures that the customer’s needs are satisfied throughout a system’s entire life cycle. This process is comprised of the following seven tasks.

1. State the problem. Stating the problem is the most important systems engineering task. It entails identifying customers, understanding customer needs, establishing the need for change, discovering requirements and defining system functions.
2. Investigate alternatives. Alternatives are investigated and evaluated based on performance, cost and risk.
3. Model the system. Running models clarifies requirements, reveals bottlenecks and fragmented activities, reduces cost and exposes duplication of efforts.
4. Integrate. Integration means designing interfaces and bringing system elements together so they work as a whole. This requires extensive communication and coordination.
5. Launch the system. Launching the system means running the system and producing outputs — making the system do what it was intended to do.
6. Assess performance. Performance is assessed using evaluation criteria, technical performance measures and measures — measurement is the key. If you cannot measure it, you cannot control it. If you cannot control it, you cannot improve it.
7. Re-evaluation. Re-evaluation should be a continual and iterative process with many parallel loops.

The purpose of systems engineering is to produce systems that satisfy the customers’ needs, increase the probability of system success, reduce risk and reduce total-life-cycle cost.
Systems engineering, which stands at the interface between engineering and management, is conspicuously practical and down to earth. In contrast, systems theories, which lie at the core of engineering science, are mathematical and rather abstract. This in no way implies that systems theories are impractical; they are practical in a general way. Connecting them to systems engineering is the notion of function, through which systems theories are applied to particular designs.