Learn Software Development » Scrum http://learnsoftwareprocesses.com All about the processes involved in software development Sun, 20 May 2012 19:17:40 +0000 en hourly 1 New implementation of Scrum in an organization – some points http://learnsoftwareprocesses.com/2012/03/13/new-implementation-of-scrum-in-an-organization-some-points/ http://learnsoftwareprocesses.com/2012/03/13/new-implementation-of-scrum-in-an-organization-some-points/#comments Tue, 13 Mar 2012 16:29:12 +0000 ashish http://learnsoftwareprocesses.com/?p=1019 No doubt, Scrum is the simplest and effective methodology to implement; however it needs some careful attempts in terms of implementation, in order to make it work efficiently for your organization. The main objective to bring Scrum into the system is to achieve maximum business advantage. There are a few things that should be considered [...]]]> No doubt, Scrum is the simplest and effective methodology to implement; however it needs some careful attempts in terms of implementation, in order to make it work efficiently for your organization. The main objective to bring Scrum into the system is to achieve maximum business advantage. There are a few things that should be considered while implementing Scrum in any organization.
To start with, understand the organizational needs of using Scrum. No matter, how big or small is the organization, they have their specific needs. Scrum is applied to deliver better output in a well organized way and with the least possible time. It is aimed at accomplishing the project goals in lesser time and with smaller costs. The implementation of Scrum and the project ought to benefit from each other. While deciding the project, there are certain concerns that should be taken in account such as having a single and dedicated product owner and a trained mentor. A Scrum team should ideally be small in size, with about 5 to 10 cross-functional people.
It is also important to figure out whether the team will be working from one location or multiple locations. Although it is not mandatory to have the entire team at single location, however, it simplifies the tasks to a great extend. Organizations also need to make sure that the team has adequate technical resources for successful accomplishment of the Scrum based project.
Once the project and its structure are designed, you need to bring a product owner, Scrum Master and a team into the picture. Since Scrum is not very rigid, simply reading about it and attending class room training will not be able to let it execute effectively. You need to have the right kind of people on board, who have thorough knowledge and hands on experience on Scrum and understanding of the project. You may also consider engaging a qualified Scrum trainer for support in training.
Sprint Planning is another important phase of Scrum Implementation in the organizations. It involves two steps, which are Sprint Planning for requirements and Sprint Planning for tasks. These steps require detailed information about the organizational goals and objective of Scrum Implementation. One must make sure that the requirements are clearly defined and understood because once the sprint is started no changes are permitted; which means that any amendments made to the requirements are bound to come through a fresh set of requirements in the backlog, which in turn leads to an increase in costs of the project.
The shift from long-established techniques of working to Scrum approach is comparatively easy. But as a matter of fact, neither Scrum nor any other Agile methodology, are the easiest shots to play, and taking on any of them would involve some severe and considerable obligations from the organization to make it work for them. These methodologies work very well in their own right and at the same time, Scrum is also an exceptional first step if you want to bring in Agile concepts in your organization as it is uncomplicated and is focused on increasing the efficiency of project management.

Agile Project Management with Scrum Agile Testing: A Practical Guide for Testers and Agile Teams Agile and Iterative Development
]]> http://learnsoftwareprocesses.com/2012/03/13/new-implementation-of-scrum-in-an-organization-some-points/feed/ 0 Testing practices in Scrum methodology http://learnsoftwareprocesses.com/2012/03/07/testing-practices-in-scrum-methodology/ http://learnsoftwareprocesses.com/2012/03/07/testing-practices-in-scrum-methodology/#comments Wed, 07 Mar 2012 18:16:43 +0000 ashish http://learnsoftwareprocesses.com/?p=1016 Introduced by Hirotaka Takeuchi and Ikujiro Nonaka in 1986, Scrum is one amongst the most popular software development process methodology used for product as well as application development. It belongs to the family of agile software development methodologies, which has got many advantages over traditional methodologies. Scrum methodology not only offers flexibility and ease in [...]]]> Introduced by Hirotaka Takeuchi and Ikujiro Nonaka in 1986, Scrum is one amongst the most popular software development process methodology used for product as well as application development. It belongs to the family of agile software development methodologies, which has got many advantages over traditional methodologies.
Scrum methodology not only offers flexibility and ease in development but it has also changed the way testing is performed during the entire process. It allows the testing team and the developers to collaborate and communicate in a better way. In the traditional methodology, testing is done after the development part is over, which is a lengthy and time consuming process. However, in case of Scrum development and testing goes hand in hand. Both the tasks can be performed and synchronized at same point of time. The entire Scrum team (quality testers, software developers and product owner) can have access to the same information about the project requisites and client needs at the same time. This involvement of both the teams from the beginning gives transparency of activities performed by each other, leading to the overall success of the Scrum sprint in a shorter duration.
With the simultaneous inputs of software developer, quality testers and projects managers, it becomes easy and fast to discover and rectify the defects and remove the bugs. Incorporating Scrum testing methods allows the team to clearly focus on delivering the maximum business value in the least possible time. One can easily, swiftly and constantly keep a close eye on real working software on regular intervals (fortnightly or even once in a month).
It also gives the quality testers, an opportunity to bring forth alternative situations and come up with helpful inputs on designing and development resolutions at different stages of the projects right from the beginning. Their contributions can transform into more value and admiration from their corresponding development personnel.
A real Scrum project is more likely to be very development focused, at the same time as paying attention on testing new features. The chief aspect of the Scrum process is the incessant collection and planning of the regression testing. Most of times, it is seen that these projects tend to overlook regression testing, which may land up in an extremely treacherous situation. So it is better to re-execute all the scrum sprints before the final delivery. Although application of Scrum persuades collocation, however, at times, it may not be possible, particularly in the cases where the teams are scattered in various geographic locations. Ideally, Scrum should have a small team of 5-7 people comprises of Product Owner, the Scrum Master, software developer and the tester.
On the whole, Scrum is an exceptionally good methodology for software development as well as testing, due to its simple, straight forward approach and its ability to have control over each situation, which the software developer may come across at some stage in the entire development process. It is a fair idea to integrate Scrum throughout the total iteration phase.

Agile Project Management with Scrum Agile Testing: A Practical Guide for Testers and Agile Teams Agile and Iterative Development
]]> http://learnsoftwareprocesses.com/2012/03/07/testing-practices-in-scrum-methodology/feed/ 0 Do Scrum of Scrums meetings add value to the project – Part 2 http://learnsoftwareprocesses.com/2012/02/13/do-scrum-of-scrums-meetings-add-value-to-the-project-part-2/ http://learnsoftwareprocesses.com/2012/02/13/do-scrum-of-scrums-meetings-add-value-to-the-project-part-2/#comments Mon, 13 Feb 2012 20:00:19 +0000 ashish http://learnsoftwareprocesses.com/?p=977 In the previous post (Scrum of Scrums), we started discussing about what the Scrum of Scrums meeting is all about. In today’s post, we shall discuss more about the Scrum of Scrums meeting. This is a meeting that is typically not meant to be a kind of mega-status meeting, being meant to be a technical [...]]]> In the previous post (Scrum of Scrums), we started discussing about what the Scrum of Scrums meeting is all about. In today’s post, we shall discuss more about the Scrum of Scrums meeting. This is a meeting that is typically not meant to be a kind of mega-status meeting, being meant to be a technical coordination type of meeting where representatives from the different Scrum teams come to discuss technical and coordination issues. Who actually attends from each team is left open, and there is no necessity that a Scrum Master or Product Owner from each team should be attending; in fact, a number of people to whom I have spoken also talk about one of the senior technical folks from each team attending this meeting rather than any manager kind of person attending.
But since this is a meeting requiring a fairly detailed level of coordination between different teams (some of the issues related to inter-team technical coordination can be fairly complex, requiring changes in the Product Backlog of individual teams and follow up), so you need a Scrum Master or a Project Manager to manage this meeting, coordinate the various actions; in some cases, have discussions with the Product Management organization for resolving conflicting priority of items and seeing through the various changes that would be required over a period of time.
Further, there is no time slot for the Scrum of Scrums, it does not require the same kind of time boxing as the Daily Scrum meeting which has some strict criteria on what can be discussed, the amount of time that such a discussion can happen, and so on. This follows from the fact that the Scrum of Scrums is not meant to be an update meeting, but a meeting between the various Scrum teams so that they can resolve their issues and do a much better level of coordination.

Succeeding with Agile: Software Development Using Scrum Agile Estimating and Planning Agile Testing: A Practical Guide for Testers and Agile Teams
]]> http://learnsoftwareprocesses.com/2012/02/13/do-scrum-of-scrums-meetings-add-value-to-the-project-part-2/feed/ 0 Do Scrum of Scrums meetings add value to the project – Part 1 http://learnsoftwareprocesses.com/2012/02/07/do-scrum-of-scrums-meetings-add-value-to-the-project-part-1/ http://learnsoftwareprocesses.com/2012/02/07/do-scrum-of-scrums-meetings-add-value-to-the-project-part-1/#comments Tue, 07 Feb 2012 19:53:10 +0000 ashish http://learnsoftwareprocesses.com/?p=975 One of the most confusing meetings for new entrants to Scrum is the Scrum of Scrums meeting. For a lot of people, there is no clear understanding about why this meeting is held, who are the participants, frequency, agenda, etc. I have been through a couple of trainings and those did not really cover the [...]]]> One of the most confusing meetings for new entrants to Scrum is the Scrum of Scrums meeting. For a lot of people, there is no clear understanding about why this meeting is held, who are the participants, frequency, agenda, etc. I have been through a couple of trainings and those did not really cover the Scrum of Scrums. In the past, we have had some team members of complex Scrum teams (where the project was split into several Scrum teams for convenience) coming to us (a group of experienced Scrum Masters), asking for more experience in what this meeting was about. Some of them were researching about what to do when they had large teams working together, and needed some guidance in this regard. This post (and many others) are more in terms of explaining what the Scrum of Scrums is, and how it can be optimized.
So what is the Scrum of Scrums ? Well, as in many of such terms and processes, you will find some amount of variety in the answers you get, but there is consensus about the fact that it is a process geared towards ensuring that multiple scrum teams interact with each other. Consider a big project with many features; these are broken down into multiple Scrum teams. However, it is required that these teams interact with each other, since it would be pretty accurate to expect that features could interact with each other. For example, a login module would not work until another team has made the connectivity with the Database work, and yet another team has made the security protocols for the login process.
Because of all these interactions and dependencies, the teams need to interact to resolve and coordinate the integration of these dependencies. In our experience, we have had the Scrum Master and Product Owner from the Scrum teams attend the Scrum of Scrums (the frequency of this meeting in turn needs to be defined by the members of this meeting; we have had cases where the number of dependencies meant that teams meet for this meeting every day, in another case where the User Stories were fairly independent, and the Scrum of Scrums would be setup for once a week and would finish quickly); we haven’t had something like a Scrum Master concept for the Scrum of Scrums meeting. But, we did ask for a person from the Product Management organization with enough authority to act as a Product Owner for this Scrum of Scrums; one of the primary roles of this PO was to reconcile different priorities among the various Scrum teams to ensure that feature dependency schedules were properly synchronized, even if that meant that some individual Product Backlogs had to be redone to incorporate changes in priority (in one significant case, one Scrum team ended up with a task on the next Sprint that was at a very low priority because other teams depended on that task for a lot of architecture support).

More on the Scrum of Scrums in the next post (link) ..

Succeeding with Agile: Software Development Using Scrum Agile Estimating and Planning Agile Testing: A Practical Guide for Testers and Agile Teams
]]> http://learnsoftwareprocesses.com/2012/02/07/do-scrum-of-scrums-meetings-add-value-to-the-project-part-1/feed/ 0 Expanding the Scrum process to a larger team, some problems .. http://learnsoftwareprocesses.com/2011/12/13/expanding-the-scrum-process-to-a-larger-team-some-problems/ http://learnsoftwareprocesses.com/2011/12/13/expanding-the-scrum-process-to-a-larger-team-some-problems/#comments Tue, 13 Dec 2011 18:54:49 +0000 ashish http://learnsoftwareprocesses.com/?p=936 We were successfully running Scrum on a team that was just at the appropriate size, with around 8 people in the team, all well trained in Scrum and believing in the way forward being Scrum. They understood how to use Scrum, and had developed a nice understanding with the managers of the team to ensure [...]]]> We were successfully running Scrum on a team that was just at the appropriate size, with around 8 people in the team, all well trained in Scrum and believing in the way forward being Scrum. They understood how to use Scrum, and had developed a nice understanding with the managers of the team to ensure that they got the desired independence to estimate tasks and track the progress of the tasks. As a result, they were the team that everyone pointed to when there was a need to point out success stories and were also called to present to other teams that were planning on using Scrum.
Soon, there was a plan to take another team through the Scrum process, and with team members from the first team providing training and support, the plan was started. The idea was to get the division of the team done properly (since this was a 20+ member team), along with separation of the features into some significant areas such that multiple teams could handle each tasks separately, set Product Owners for these tasks. The thought was that this would be a smooth experience.
Well, it was not. Soon, within a couple of Sprints, the Product Owners started complaining that many integrated features were just not making it as the original plan, and the product was falling apart whenever integration was supposed to be happening. Soon, there was an emergency session on to figure out what was going wrong, since individual Scrum teams were working fine. After some analysis, the following were found to be some of the main problems:
- Coordination between the multiple Scrum teams was just not happening to the desired level. There were informal contacts between the team members, and the Product Owners met up on a regular basis, but the deep technical discussions that should have been happening were not present; this was primarily because the teams were too focused on their own specific work (and this was enhanced by the emotional attachment they had developed due to the process of estimation and assignment, as well as because of the Daily Scrum meeting).
- The teams were no longer thinking of the big project. Originally, you had the managers who would always have a conception of the big picture in terms of the integrated product, but after passing on a fair amount of the operational authority to the team members, the picturisation of the big picture when doing the regular daily work was getting lost. The only alternative that seemed to occur to the managers was to get more involved, but they also did not want to seem to interfere with the work being done by the team.
- Daily meetings. With the big teams being split into smaller teams, the management was getting very heavily stretched just in terms of the amount of meetings, and if they did not attend the meetings, the managers were not sure of being aware of status of what is happening in the project, and hence had to stretch to know more. This in turn prevented the managers from spending the desired amount of time that they would normally spend on other items such as optimizations, improvements, and looking at the big picture.

Succeeding with Agile: Software Development Using Scrum The Elements of Scrum
 A Practical Guide to Distributed Scrum
]]> http://learnsoftwareprocesses.com/2011/12/13/expanding-the-scrum-process-to-a-larger-team-some-problems/feed/ 0