Learn Software Development » Engineering

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.

Construction Practice – Type of Software Egineering practice

ashish — Tue, 20 Oct 2009 19:34:42 +0000

The construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for delivery to the customer or end-user. A set of fundamental principles and concepts are applicable to coding and testing.
1. Coding principles : A number of fundamental principles that can be stated are :
- Preparation principles
* Understand the problem you are trying to solve.
* Understand the basic design principles and concepts.
* Pick an appropriate programming language.
* Select a programming environment.
* Create a set of unit tests that will be applied once the component you code is completed.
- Coding Principles
* Constrain your algorithms by following structured programming practice.
* Select data structures.
* Understand the software architecture and create interfaces.
* Keep conditional logic as simple as possible.
* Create nested loops in a way that makes them easily testable.
* Select meaningful variable names and follow other local coding standards.
* Write code that is self-documenting.
* Create a visual layout.
- Validation principles
* Conduct a code walk through when appropriate.
* Perform unit tests.
* Refactor the code.
2. Testing Principles : It is a process of executing a program with the intent of finding an error. A set of testing principles that have been adapted are :
- All tests should be traceable to customer requirements.
- Tests should be planned long before testing begins.
- The Pareto principle states that 80% of all errors uncovered during testing will likely be traceable to 20% of all program components applies to software testing.
- Testing should begin “in the small” and progress toward testing “in the large”.
- Exhaustive testing is not possible.