Learn Software Development » Development

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.

Some advantages of using Scrum ..

ashish — Mon, 26 Oct 2009 19:35:41 +0000

For people working on software projects, or on software products, Scrum is a relatively new development methodology that comes with a lot of hype, and with many converts. Even in my company, where we practice different development methodologies such as Waterfall, Agile, Scrum, Iterative, etc (depending on the need), there is a push towards evaluating Scrum and using it. What are some of the advantages of using scrum ?
- Scrum works on the basis that the teams involved in scrum are self-organizing and self-managing. The team is the core component of a scrum development methodology, and the team as a whole is dependent on driving the features and being responsible for the success. The team as such are supposed to merge their differences in terms of being individual QE, Dev, etc.
- Developers commit to develop only features that can be developed within the current iteration or Sprint
- Very distinct from waterfall, in the sense that you deliver feature by feature, instead of working on all features to achieve the Alpha / Beta. This allows you to have the flexibility of incorporating new features when required.
- So, you do not know the feature details for work supposed to happen in the next 2 months, that is fine, since you will have this time in between to get more detail about the needed features rather than design on features where the definition is not clear
- By ensuring that at the end of every iteration or Sprint, you have a deliverable feature and a good level of product, you can show good progress to your customers or stakeholders; customers are easily able to view the progress and demo of features after every iteration
- This shorter development cycle ensures that you have a much closer level of communication with the customer and can incorporate feedback quickly and effectively
- Scrum methodology ensures that any problems are quickly highlighted and not hidden under the carpet till much later
- When scrums are well designed and features properly allocated, then the more important features are included in the earlier Sprints, this ensures that those features are selected and implemented that are more important. Features that are low in importance are not taken up till much later.
- Daily (short) meetings during the Scrum process ensure that any blockages or impediments are quickly detected and handled, giving a higher rate of success for the project
- The team feels much more involved in the planning process, and giving them this feeling ensures that they have a greater stake in the success of the project
- Are able to better measure productivity using burndown charts, velocity, etc

Product Development – Getting requirements and prioritization – Part 2

ashish — Sun, 07 Jun 2009 12:13:56 +0000

The previous post talked about how the Product Management team generated requirements for the new version of the product. When this happens, the next most important task is to get an idea about how much effort getting all these requirements into the product will take. This is easier said than done. Doing effort estimation when the requirement is a stated 2 line statement can be really difficult, and requires some amount of refinement.
What would next happen in most cycles that I have seen is that the requirements are next discussed between the Product Management team and the engineering team (typically senior engineers along with the engineering manager); this process also envisages that the requirements are discussed to some extent in terms of what the workflow would be (keep in mind that this is not the right time of the cycle to start designing screens or dialogs or detailing the workflow other than a top level attempt – doing such an effort for most requirements would take too long and is difficult to attempt).
What really helps for this effort is to use some sort of documentation (I know people who use Word or use an internal Twiki implementation, or some other tool to capture such requirements in a medium level of detail (this is somewhat tricky, you need to have enough detail that you can take a rough guess at the effort estimate), and where you can break down the top level requirements into one step lower of requirements (example, if you need to add a new editing capability to a tool, the intermediate level requirements could be about having different file formats supported, or about different levels of editing such as having 3 quick buttons, or a slider to allow the user to have more control)).
Another element of this cycle is to press for prioritizing the requirements. It is incredibly important to make sure that prioritization is done, and there is a possibility that the product management team may have some hesitation in terms of doing the prioritization of these requirements. However, given my earlier statement about resourcing not being infinite for the product development cycle, setting a priority means that the team can focus on those requirements that are most critical, and then on the ones that are deemed less critical. The other advantage of forcing the priority is that this process forces the product management team to take a deep look at the features (including sub-features) in terms of whether this is something that will really benefit the product. This also ensures that resources are spent wisely.

Product Development – Getting requirements and prioritization – Part 1

ashish — Sun, 07 Jun 2009 11:36:38 +0000

I have in mind a series of posts that explains how the product development process works inside one of the teams for a product development company (based on previous experiences). However, this story has been interrupted in the past, and I believe I last posted on this topic many months back. I will try to be more regular on this topic in the future. Previous topics that I had written about were pre-release planning and metrics.
This topic will be about the meat of actually starting work on new feature development; the need is to actually define what the team needs to deliver in this new cycle. At this stage in the cycle, the only known facts are:
- It is decided that a new version will be required
- Dates are typically known for the release. Dates can be decided based on having to schedule for a certain condition of the market (in the US, to meet the enhanced marked season starting from Black Friday to Christmas, product development needs to conclude by a certain time so that the product can make its way through the retail chain and into the hands of retailers, large and small); dates can also be scheduled to meet projected customer needs (so if a software / hardware producer faces rivalry from Apple, it used to be that they would schedule release near MacWorld to prevent Apple from running away with the market)
- The number of resources are typically known. For most product development situations (unless there is the need to scale up to meet a competitor), the resources are not changed based on the number of features available. What would happen is that the features that can be implemented are decided based on the number of resources available.

So what happens next ? Well, what needs to happen next is that the product management team needs to decide on the features that are sought to be included in this release. If the product is something large such as the next version of Visual Studio C#, then the product management team would normally comprise of multiple product managers, each of whom would be tasked with a different area of the product. It is part of the responsibility of the product management team to decide on the features that are part of the consideration set for the release (and sources for new features include competitor analysis, user requests through forums, changes suggested through usability studies and through group sessions; there are also features that may correspond to changes in the market but not suggested by users – as an example, consider the case when a new technology related to online technologies hits the market and the product needs to have features to integrate with these new technologies or features – as an example, with the emergence of social networks such as Twitter, Facebook, MySpace, it may be needed for products to see how they would integrate with those).
So ends Part 1 of this post, I will carry it ahead with the next post.

DFD: data flow diagram

ashish — Wed, 08 Apr 2009 07:27:55 +0000

Not everybody who has worked in the software development cycle has heard of what a Data Flow Diagram is, or what it does. So, for example, somebody who makes applications such as Windows or Office or PhotoShop may not need to know what a DFD is. However, for a team that is designing an application for a bank or for a shopping application that involves a lot of data, it is essential to map the data flow. Hence, a Data Flow Diagram (DFD) is an essential component for the design of a large number of software applications, and if you don’t do the DFD well, then the system may not end up having been designed well, and may end up being less efficient than it was supposed to be.
So, what is a DFD ? A brief definition and description:
DFDs were first used in the software engineering field as a notation for studying systems design issues. A data-flow diagram (DFD) is a graphical representation of the “flow” of data through an information system. DFDs show the flow of data from external entities into the system, showed how the data moved from one process to another, as well as its logical storage. A data-flow diagram can also be used for the visualization of data processing (structured design).
Data flow diagrams can be used to provide a clear representation of any business function. The technique starts with an overall picture of the business and continues by analyzing each of the functional areas of interest. This analysis can be carried out to precisely the level of detail required, leading to a data flow diagram that is strong in illustrating the relationship of processes, data stores and external entities in business information system.
Complicated information systems have lots of data flows which can be presented in a form of a data flow diagram. Without such data flow diagram you just can’t visualize all data flows and won’t be able to analyze and improve the whole system. Data flow diagrams represent data flows in a clear visual way as arrows between blocks which represent parts and processes of the system. Identifying the existing business processes, using a technique like data flow diagrams, is an essential precursor to business process re-engineering, migration to new technology, or refinement of an existing business process.
Sounds complicated, so the next few posts will detail the steps to making a data flow diagram, what are the benefits for this diagram, and some tools that will help in generating a data flow diagram.