Learn Software Development » Review http://learnsoftwareprocesses.com All about the processes involved in software development Tue, 07 Feb 2012 19:53:10 +0000 en hourly 1 Make sure that you plan some of the logistics around your Scrum implementation – else you can get tripped up http://learnsoftwareprocesses.com/2011/06/09/make-sure-that-you-plan-some-of-the-logistics-around-your-scrum-implementation-else-you-can-get-tripped-up/ http://learnsoftwareprocesses.com/2011/06/09/make-sure-that-you-plan-some-of-the-logistics-around-your-scrum-implementation-else-you-can-get-tripped-up/#comments Thu, 09 Jun 2011 17:22:46 +0000 ashish http://learnsoftwareprocesses.com/?p=822 People worry a lot about their Scrum implementation, in terms of ensuring that their people have got the required training, that some of the obvious pain points have been resolved, and in some cases, that a Scrum coach has been put in place. Over a period of time, getting hold of some of the issues [...]]]> People worry a lot about their Scrum implementation, in terms of ensuring that their people have got the required training, that some of the obvious pain points have been resolved, and in some cases, that a Scrum coach has been put in place. Over a period of time, getting hold of some of the issues related to the logistics of the Daily Scrum meeting, the rules for these meetings, and so on need to be set. These cause some of the biggest pain points related to the Scrum implementation, and some of the biggest issues for the team. However, there are some of the smaller issues that need to be resolved and set in place, and which ensure that the various meetings happen as desired. Some of these issues are:
Durations of meeting: Durations of the Daily Scrum is typically set for around 15 minutes, but there are a number of other meetings that are needed as a part of Scrum. Some of these meetings are the Sprint Planning, the Sprint Retrospective, the Sprint Review. Typically all these meetings are set for the Sprint end and Sprint beginning, but it is required to set the days on which these meetings need to happen; whether they need to be set for 1 day or stretch over 2 days, as well as the number of hours in which these meetings happen. Many people prefer to set exact timelines such as the Sprint Review happening for 2 hours, the Sprint Planning being broken down into 2 parts (User Story explanation, and Task estimation) together for 8 hours.
Setting the time that everybody can meet: When the teams have people from different geographic locations, setting meeting times and deciding who all needs to attend which meeting can be a logistical issue that requires effort to resolve. In some cases, people are pushed to re-schedule some of their meetings to alternate times, and it would be a mistake to diminish the importance of this logistical issue.
Defining your Sprint length: This means specifying the exact start and end dates for the Sprint, something that most people take for granted. When you set a specified Sprint length (something that is needed to happen at the start of the Sprints), it helps in getting a defined interval for the calculation of capacity, velocity. Typically when a team tries to calculate a Sprint length, the team can have their own opinions, and these can be 2 weeks, 3 weeks, 4 weeks, or more. Sometimes, there can be no way to get everybody to agree to the Sprint length, and in such cases, it is just easier to get everybody to vote and agree on the Sprint length which most people have voted on. Keep in mind that if you set a Sprint interval that is too short, then you will have the Sprint Planning, Retrospective, and Demo happening that often, which is something that people may not have thought about.
Decide penalties if people cannot attend: It is easy for people to use excuses for not attending the meetings, but it is very easy for such non-attendance to become a precedent, and more and more people use reasons for not attending rather than trying to re-shuffle their schedule in order to be able to attend the meeting. Set penalties and implement them (get the team to propose the penalties).

]]> http://learnsoftwareprocesses.com/2011/06/09/make-sure-that-you-plan-some-of-the-logistics-around-your-scrum-implementation-else-you-can-get-tripped-up/feed/ 0 The Product Owner as the liasion between the Product Management and the Engineering team http://learnsoftwareprocesses.com/2011/03/26/the-product-owner-as-the-liasion-between-the-product-management-and-the-engineering-team/ http://learnsoftwareprocesses.com/2011/03/26/the-product-owner-as-the-liasion-between-the-product-management-and-the-engineering-team/#comments Sat, 26 Mar 2011 20:14:17 +0000 ashish http://learnsoftwareprocesses.com/?p=779 The role of the Product Owner is one of the most complex roles in the concept of Scrum. As opposed to the earlier role of the Product Management in a waterfall (or non-Scrum and non-Agile) who would deliver the requirements and provide inputs to the team once in a while, the amount of interfacing with [...]]]> The role of the Product Owner is one of the most complex roles in the concept of Scrum. As opposed to the earlier role of the Product Management in a waterfall (or non-Scrum and non-Agile) who would deliver the requirements and provide inputs to the team once in a while, the amount of interfacing with the Product Team is much greater in the case of a Scrum model. The Product Owner should be able to provide inputs as and when the Scrum team wants, and given that the team works on a Sprint by Sprint set of features, getting inputs as and when the team requires it is important, else delay happens, which directly impacts the amount of work output in the given Sprint. As a result, most Scrum teams have a need to ensure that the Product Owner is available to them on a regular basis, or put another way, the Product Owner should not be away for long periods of time.
At the same time, there is a lot of expectation that the Product Owner (as a part of Product Management) is the person with regard to customer interaction, taking part in industry and trade shows, and working out all the usability testing and so on. This part of the job can be really tough as well, since it takes a lot of time to make all this happen; the problem that occurs is that we are trying to combine both of these roles into one person, and something has got to give. If the Product Owner is able to get a good customer perspective, then it can be a good chance that the team is not able to get the required time with the Product Owner.
So, a number of organizations realize that it may make sense to split these 2 roles for better efficiency and productivity (although there is a cost factor, since there is going to be an increase in the amount of personnel in the role of Product Manager / Product Owner – the benefits of going the Scrum way should be able to overcome the additional cost; and the problems if we don’t go down this route can be more costly). There are some huge benefits of going in for such an approach:
1. The team is able to get the required amount of time with the Product Owner; this increases the efficiency of the Scrum team
2. The Product Owner can be in the same location as the Scrum team while the Product Manager who works with the customer is located in the actual country where customers are located (in cases where the Scrum team is located in a low cost country)
3. The Product Managers are able to spend the necessary research and working with customers, thus ensuring that the team gets all the required info at the right time.

This article will be contd in the next post ..

]]> http://learnsoftwareprocesses.com/2011/03/26/the-product-owner-as-the-liasion-between-the-product-management-and-the-engineering-team/feed/ 0 Scrum: Product Owner needs to ensure that the Sprint end delivery is what he is looking for http://learnsoftwareprocesses.com/2011/03/14/scrum-product-owner-needs-to-ensure-that-the-sprint-end-delivery-is-what-he-is-looking-for/ http://learnsoftwareprocesses.com/2011/03/14/scrum-product-owner-needs-to-ensure-that-the-sprint-end-delivery-is-what-he-is-looking-for/#comments Mon, 14 Mar 2011 17:42:43 +0000 ashish http://learnsoftwareprocesses.com/?p=767 The process of starting to use Scrum as the software development methodology involves change for everybody. The various people involved in the process of software development would find that the work they do, the responsibility that comes onto them is different. The team will find that they have far more responsibility (in a positive sense), [...]]]> The process of starting to use Scrum as the software development methodology involves change for everybody. The various people involved in the process of software development would find that the work they do, the responsibility that comes onto them is different. The team will find that they have far more responsibility (in a positive sense), and are empowered to have a much greater role in terms of task estimation, and tracking. The managers of the team will find that there role is no longer that of commanding, but instead becoming a coach who advises their team members and enhances their skill sets. One of the biggest change in roles is that of the Product Owner, who has to adjust to a role where there is a much deeper integration with the team, in terms of explaining the features, being available to answer queries, being there when the team is doing its task estimation, and so on.
One of the biggest responsibilities that remains (but in a different form) is the role of being the customer representative for the team, being able to decide whether the team is being on the right direction as they are building the software product. One major difference that the Product Owner has to adjust to is in terms of periodically validate that the product that the team is building is the correct one. In one case, this turned out to be a problem. The Product Owner was a fairly senior Product Manager, and it was difficult to get him to transition to the role that was expected of him. The Product Owner would spend the time in explaining the requirements, and during the Sprint Planning meetings, would answer all the queries; this mapped very well to the process being followed earlier. However, somehow, he was not able to accept the concept of validating the product that was built by the end of the Sprint cycle. So, when the demo was done at the end of every Sprint, he would look at what was built, and shake his head if something was not done properly, or otherwise stay silent. This was somehow not conveying the correct impression to the team, who were taught that the Product Owner would provide some detailed feedback about the product, what was right and what needed feedback.
For quite a few Sprints, this feedback was not being provided. We were in fact literally goading the Product Owner to provide feedback, including even rejecting the work done in the Sprint if this was not meeting the expectations. It took some time for us to make the Product Owner understand that the Sprint End demo and validation of the Product progress was an excellent opportunity to make sure that everything was fine, and if not, then convey this to the team clearly and in such a way that the message got across. Once this was clear and we started seeing this in action, the Product Owner started seeing that the product was getting developed as per his expectation.

]]> http://learnsoftwareprocesses.com/2011/03/14/scrum-product-owner-needs-to-ensure-that-the-sprint-end-delivery-is-what-he-is-looking-for/feed/ 0 XPlanner – A tool for Scrum – Some reviews http://learnsoftwareprocesses.com/2011/01/31/xplanner-a-tool-for-scrum-some-reviews/ http://learnsoftwareprocesses.com/2011/01/31/xplanner-a-tool-for-scrum-some-reviews/#comments Mon, 31 Jan 2011 19:04:48 +0000 ashish http://learnsoftwareprocesses.com/?p=742 Xplanner is a tool used for Scrum purposes, and is being used by a number of teams all over the world. From the project site (link)

XPlanner is a project planning and tracking tool for eXtreme Programming (XP) teams. If you are not familiar with XP software development practices, the links page contains pointers [...]]]> Xplanner is a tool used for Scrum purposes, and is being used by a number of teams all over the world. From the project site (link)

XPlanner is a project planning and tracking tool for eXtreme Programming (XP) teams. If you are not familiar with XP software development practices, the links page contains pointers to relevant resources. To summarize the XP planning process, the customers pick the features to be added (user stories) to each development iteration (typically, one to three weeks in duration). The developers estimate the effort to complete the stories either at the story level or by decomposing the story into tasks and estimating those. Information about team development velocity from the previous iteration is used to estimate if the team can complete the stories proposed by the customer. If the team appears to be overcommitted, the set of stories are renegotiated with the customer. The XPlanner tool was created to support this process and address issues experienced in a long-term real-life XP project.

Here are some reviews and comments about this tool from different locations, and should help you make a decision when you are evaluating tools to use:
Xplanner.org (link)
Scribd.com (link)
ohloh.net (link)
agile-tools.net (link)
Thinking in Extremes with Xplanner (link)
javaworld.com (link)
http://borisgloger.com (link)
issart.com (link)
vietnamesetestingboard.org (link)
Journey in Software (link)
XPlanner installation FAQ (link)

]]> http://learnsoftwareprocesses.com/2011/01/31/xplanner-a-tool-for-scrum-some-reviews/feed/ 0 Learn about Scrum – Why does Scrum fail – The sponsors worried about the lack of a schedule of features in the overall project, this worry extending to the end of the project: Part 1 http://learnsoftwareprocesses.com/2010/07/04/learn-about-scrum-%e2%80%93-why-does-scrum-fail-%e2%80%93-the-sponsors-worried-about-the-lack-of-a-schedule-of-features-in-the-overall-project-this-worry-extending-to-the-end-of-the-project-part-1-1/ http://learnsoftwareprocesses.com/2010/07/04/learn-about-scrum-%e2%80%93-why-does-scrum-fail-%e2%80%93-the-sponsors-worried-about-the-lack-of-a-schedule-of-features-in-the-overall-project-this-worry-extending-to-the-end-of-the-project-part-1-1/#comments Sun, 04 Jul 2010 09:26:00 +0000 ashish http://learnsoftwareprocesses.com/?p=635 In the previous post (Problems in letting the team be self-empowered), I talked about how it was difficult for managers to transition to a role more akin to a coach rather than being the traditional decision-making, hard task driving individual who is responsible for driving their teams. In a number of cases, the managers are [...]]]> In the previous post (Problems in letting the team be self-empowered), I talked about how it was difficult for managers to transition to a role more akin to a coach rather than being the traditional decision-making, hard task driving individual who is responsible for driving their teams. In a number of cases, the managers are not easily able to switch over, and it is hard for them accept that the teams are responsible for a number of technical and even process related decisions in the Scrum process.
In this post, I talk about another case which causes problems during Scrum implementation, and can actually derail the progress of a Scrum project. This is the case where the executives have just paid lip-service to the cause of Scrum, but do not understand the changes that are needed for a Scrum project, and then find themselves uncomfortable during the course of implementation of the project. Let me narrate the example, and then we can learn how to try to overcome some of the problems that we see during the Scrum implementation.
During the course of a project, we have multiple reviews by a team of Senior Managers, who are ultimately responsible for the overall project (in terms of ownership of the overall business unit), and as a result, they need to ensure that the project team is handling the project in a satisfactory manner. For this purpose, during the start of the project, and during the course of the project, there are several review sessions where the team managers present progress to the managers. One of the most important reviews is at the start of the project where the team presents their readiness to start the project, as well as the list of features that will be implemented during the course of the scrum project.
And this is where the key problems started. If we went by the traditional waterfall project, we would have projected a list of features that we were sure would be done during the course of the project, since we would have spent the first few weeks before the meeting planning and estimating for the features. Based on this analysis, we would be able to have a clearly defined list of features, and use these for the review meeting. With Scrum however, following a strict implementation, we would only have a prioritized backlog of features, and during the course of each Sprint meeting, we were able to define a list of features that would be done in this Sprint. In this manner, however, we were not able to generate an initial list of features that we could project with confidence.
So, when we had the first discussion, we had explained the whole concept of Scrum to the executives, taken them through case studies, and also how Scrum would help in doing a project with a higher chance of success. However, when we did the discussion, it was clear that the executives were not confident without a tangible list of features that they could refer to, especially since this was a $250 million product, and competitor analysis was a key part of this review (the market was very competitive, and getting features in the project was key for good reviews and higher customer uptake).

Contd .. in part 2 of this post ..

]]> http://learnsoftwareprocesses.com/2010/07/04/learn-about-scrum-%e2%80%93-why-does-scrum-fail-%e2%80%93-the-sponsors-worried-about-the-lack-of-a-schedule-of-features-in-the-overall-project-this-worry-extending-to-the-end-of-the-project-part-1-1/feed/ 0