I was attending SCRUM meeting with my team and normally it is followed by a 5 min TIDBIT session by anyone on a round robin basis. One of my team member raised a very good point, he was giving example of how we have successfully implemented Agile in our team. And he pointed out that we have brought in incremental changes. That means we have implemented Agile in the Agile way. We didn't rushed into things we took our time and we moved slowly bringing changes with each iteration.
Here in this article I will explain the manner in which we adopted things and it worked :). We have done in slow steps, the first one was adopting the basics. We started with :
1. SCRUM meetings: We didn't used the white board at this point, but we concentrated on sharing work details with each other (What we did in last 24 hours, What are our plans for next 24 hours, and roadblocks in case we have not achieved the promised objectives)
2. Pair Programming: We started with the practise of Pair Programming and Sharing sessions.
Once these resulted in better trust and self accountability, we moved to next step and introduce some XP practices like:
3. TDD: Test Driven Development
4. Testing Automation: We introduce tools like Watij (Web Application Testing In Java)
5. Continuous Builds: This resulted in tight integration. We used a software called CruiseControl for this purpose.
As and when we started getting results out of it, we moved one more step. Here we introduced
6. Simple Sprint & Product Backlogs: To track all the user stories we were working on.
7. TidBit sessions: 5 Minute session immediately after SCRUM to introduce team sharing.
This was enormous and by this time team has already started feeling the Agile. We took one more step:
8. Improved our Product & Sprint: Improved format to generate Velocity, Put up some Definitions of Done :0).
9. Iteration Plan Meeting: To ensure that we are carefully planning our activities.
10. Sprint Demo: Where developers used to demonstrate the work they have done during the spring in a already agreed upon method.
11. Retrospective Meeting: Meeting that starts after our Spring Demo to find out the good things we did in this Sprint and should be continued and the things that should be removed from the Sprint immediately.
That's it. We do make small changes to these process which we follow. But overall we implemented Agile in Agile manner. :)
Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts
Scrum Unplugged
What is Scrum?
A variation on Sashimi, an "all-at-once" approach to software engineering. Both Scrum and Sashimi are suited best to new product development rather than extended development. Sashimi originated with the Japanese and their experiences with the Waterfall model. They had the same problems with the Waterfall model as everybody else, so they adapted it to suit their own style. Realizing that speed and flexibility are as important as high quality and low cost they reduced the number of phases to four -- requirements, design, prototype, and acceptance -- without removing any activities, which resulted in overlap of the Waterfall phases. Then they made the four phases overlap. (Sashimi is a way of presenting sliced raw fish where each slice rests partially on the slice before it). Other companies took Sashimi one step further, reducing
the phases to one and calling it Scrum. (A scrum is a team pack in Rugby, everybody in the pack acts together with everyone else to move the ball down the field).
Applying Scrum
For each Waterfall phase there are a pool of experienced people available, form a team by selecting one person from each pool. Call a team meeting and tell them that they have been selected to do an important project. Describe the project, include how long it's estimated to take, how much it is estimated to cost, how it is expected to perform, etc. Now tell them that their job is to do it in half the time, with half the cost, twice the performance, etc. Tell them how it's done is up to them and explain that your job is to support them with resources. Now leave.
Stand by, give advice if it's requested, and wait. Don't be surprised if a team member thinks the whole thing is insane and leaves. You'll get regular reports, but mostly you'll just wait. At somewhere around the expected time, the team will produce the system with the expected performance and cost.
How does Scrum work?
The first thing that happens is the initial leader will become primarily a reporter. The leadership role will bounce around within the team based on the task at hand. Soon QA developers will be learning how requirements are done and will be actively contributing, and requirements people will be seeing things from a QA point of view. As work is done in each of the phases, all the team learns and contributes, no work is done alone, the team is behind everything. From the initial meeting, the finished product is being developed. Someone can be writing code, working on functional specifications, and designing during the same day, i.e. "all-at-once". Don't be surprised if the team cleans the slate numerous times, many new ways will be picked up and many old ways discarded. The team will become autonomous, and will tend to transcend the initial goals, striving for excellence. The people on the team will become committed to accomplish the goal and some members may experience emotional pain when the project is completed.
Why does Scrum Work?
The basic premise is that if you are committed to the team and the project, and if your boss really trusts you, then you can spend time being productive instead of justifying your work. This reduces the need for meetings, reporting and authorization. There is control, but it is subtle and mostly indirect. It is exercised by selecting the right people, creating an open work environment, encouraging feedback, establishing an evaluation and reward program based on group performance, managing the tendency to go off in different directions early on, and tolerating mistakes. Every person on the team starts with an understanding of the problem, associates it with a range of solutions experienced and studied, then using skill, intelligence, and experience, will narrow the range to one or a few options.
Keep in mind that it can be difficult to give up the control that it takes to support the Scrum methodology. The approach is risky, there is no guarantee that the team will not run up against real limits, which could kill the project. The disappointment of the failure could adversely affect the team members because of the high levels of personal commitment involved. Each person on the team is required to understand all of the problem and all of the steps in developing a system to solve it, this may limit the size of the system developed using the methodology.
Extreme Programming Core Practices
The 12 “XP Xtudes” (Xtude is XP means ‘Attitude’) of Extreme Programming (XP) grouped into four categories
1. Fine Scale feedback
XP thrives on providing feedback at smaller intervals with higher frequency. This allows controlling deviation at the right time, since in software or any othe industry for that matter, once deviation starts happening it is dificult to control at the later stages.
- Test Driven Development via Programmer Tests (Unit Tests) and Customer Tests (Acceptance Tests/Automation Tests)
- Planning Game (Definition Iteration Objectives and playfield etc)
- Whole Team (Onsite Customer + Programmer + Quality Team + Customer Team + Scrum Master + Product Owner)
- Pair Programming ( two engineers participate in one development effort at one workstation)
2. Continuous Process rather than Batch
- Continuous Integration (Integrate Continuosly and keep the check using Nightly Builds)
- Design Improvement (Refactor Mercilessly)
- Small Releases (Release Often)
4. Programmer welfare
/
Labels:
agile,
agile xp,
core practices,
Extreme Programming,
scrum,
xp,
xp xtudes
/
Comments: (0)
How to best use product backlogs
Product backlog is normally the starting point, it is where AGILE's heart lie. It is the first step in starting an AGILE based software development. It is nothing but a sorted list of requirements/feature requests/user stories or what ever term you use for high level tasks based on importance of the items in it. The best part is that the items are described in Customer's language which he understand basically the one which reflect the business benefit for him. Lets call these items user stories or backlog items.
Name – It is a short descriptive name of the story. Length should not be longer than 4-12 words. e.g. “Generate the employee attendance report”. It should be small, crisp, distinguishable and communicative so that stake holders knows what we want system to do. Stake holders include developers, testers, product owner.
Importance – It is the importance rating given by the product owner. There are many theories circulate around what should we use as the rating number. some suggest using P1 to P5, other says 1 to 10. I have read an interesting article which says we can use some large numbers like 21 or 135 etc, where higher the number more it has the importance. The motive behind this is to have unique importance number between stories. Second logic which is supporting it says that lets say you rated one story as P1 or 1 what will you do if a new story comes up between the iteration which is higher in importance that this one. Would you rate it as -1 or 0.5? Secondly with using high numbers we should leave some gap between importance numbers like story 1 may have importance rating of 10 and story 2 may have 9. This way is a new story comes up which is high in importance than story 1 but less in importance than story 2 we can accommodate it in between without using making sheet look ugly by making it as 2.5 or fractions. Nice thought :).
estimate – the first assessment of how much work is needed to complete this story. The unit of storage can be of your choice, normally we use a terminology called story points. The story points are usually corresponds roughly to “ideal man-days”.
Product backlog is normally the starting point, it is where AGILE's heart lie. It is the first step in starting an AGILE based software development. It is nothing but a sorted list of requirements/feature requests/user stories or what ever term you use for high level tasks based on importance of the items in it. The best part is that the items are described in Customer's language which he understand basically the one which reflect the business benefit for him. Lets call these items user stories or backlog items.
Fields associated with each story
SID – Story Identification Number, a unique identification may be you can use an auto-incremented number. This is to keep track of stories even if we change their name.Name – It is a short descriptive name of the story. Length should not be longer than 4-12 words. e.g. “Generate the employee attendance report”. It should be small, crisp, distinguishable and communicative so that stake holders knows what we want system to do. Stake holders include developers, testers, product owner.
Importance – It is the importance rating given by the product owner. There are many theories circulate around what should we use as the rating number. some suggest using P1 to P5, other says 1 to 10. I have read an interesting article which says we can use some large numbers like 21 or 135 etc, where higher the number more it has the importance. The motive behind this is to have unique importance number between stories. Second logic which is supporting it says that lets say you rated one story as P1 or 1 what will you do if a new story comes up between the iteration which is higher in importance that this one. Would you rate it as -1 or 0.5? Secondly with using high numbers we should leave some gap between importance numbers like story 1 may have importance rating of 10 and story 2 may have 9. This way is a new story comes up which is high in importance than story 1 but less in importance than story 2 we can accommodate it in between without using making sheet look ugly by making it as 2.5 or fractions. Nice thought :).
estimate – the first assessment of how much work is needed to complete this story. The unit of storage can be of your choice, normally we use a terminology called story points. The story points are usually corresponds roughly to “ideal man-days”.
- You can ask the team with a optimum number of people usually 2, in how many days you can finish a complete demonstrable & releasable version of this story. If the answer comes like "with 2 guys we will take approximately 3 working days" then the initial estimate is 3 X 2 = 6 story points.
- The concentration is not on getting every things absolutely right in the first place but the concentration is to check the relative estimates that means that a 4-point story takes about double the effort as compared to a 2-point story.
(Note: If you practice TDD (test case-driven development) this description can be used as pseudo-code for your acceptance test code. )
Notes – any other info, clarifications, references to other sources of info, etc. Normally very brief.
PRODUCT BACKLOG (example)
| SID | Name | Imp. | Story Points | How To Demo | Notes |
| 1001 | Allocate Employee to Project | 40 | 7 | Log In, Open Employee Detail Page, Change Employee Department from Bench to "Project X", Check the Employee Status in the Employee Detail Page | Need to create the class hierarchy |
| 1002 | Check Employee Allocation History | 25 | 3 | Log In, Go to "My Detail" page, click on Project History | Need to modify the css for this page. |
As the author of this sample excel sheet said and I agree that these are the basic 6 fields we need at the end of the day. You are free to add up whatever fields you want but a easy going product can survive in these fields. I myself is fan of using excel as Product sheet, it gives you lot more freedom and great control. You can allow product sheet to be in control of the "Product Owner" or you can feel free to share in on a machine with all team members, allowing them to add new stories as and when they arrive but always remember that only "Product Owner" has the right to set importance or write estimates.
HOW WE DO PRODUCT "BACKLOGS"
The last thing you want to do is to place the Product Sheet in the version repository, a good idea would be to rather place it on the shared drive. This way you can allow multiple people to access the same without causing locks, merge conflicts etc.
Additional story fields
Sometimes you may want to use few more additional fields in the product backlog based on your project's priorities, I will try to list few which are pretty common.
Category– It is a rough categorization of the story, for example “UI” or “performance”. This way the product owner can easily filter out all “UI” items and change their priority , etc.
Components - Best way is to realize it by “check boxes” in the Excel document, for example “client, middle ware, server”. Team / Product Owner has to identify which technical components will be required in completing this story. This will be typically useful when you have more than one Scrum teams.
Requester – Here as part of reporting, product owner may like to keep track who has requested for the feature to keep him updated on the progress.
Bug tracking ID – It will be useful to keep track of any direct relation between a story and reported bug(s). Specially if you have a separate bug tracking system, like we have Bugzilla.
How we retain the product backlog focus at a "business level "
It is worse to have a Product Owner coming from Technical Background, but in our case we couldn't help it. We didn't found anyone else suitable. The nightmares it caused initially was adding stories like this one "Add composite primary key to the crystal_soak tables”. Why does he want this? The real underlying goal was definitely something like “to disallow user from adding same soak twice for a particular crystal”. It may turn out that there was no primary key since crystal can be associated to more than one soak and thus users were sometimes by mistake associating the same soak more than once. It was something completely different. The team is normally better suited to figure out how to solve something, so the product owner should focus on business goals.
When you see technically oriented stories like this, you should ask the product owner a series of “but why” questions until we find the underlying goal. Then we rephrase the story in terms of the underlying goal (“disallow users to associate duplicate soak to same crystal”). The original technical description ends up in the note column (“Creating a composite primary key might solve this problem”).