Scrum in Action
We are now working in a project which have taken more than 6+ months and still in progress. 159078+ lines of code, 80+ page, 120+ user controls, 100+ tables and counting. In projects with such scale, you need to manage and control your development life cycle. You want to decrease all risks and possibilities of failure. Working with Scrum methodology helps a lot in making developers time management more efficient.
I'll try to state some points which helps us during the development of the project. My recommendation points maybe a part of the scrum definition and maybe not. But sometimes practice is more trivial than science. The following are the concluded results.
Design meetings: In each project you have to design. But as a fact, the design will change. So all what you need is to put the outlines. You don't have to state all the details. Try to make the design meetings for things which is really need a heavy mind storming and architecture. This includes frameworks, libraries and infrastructures. Discussing the design of each part in the project is a time consuming and won't help you that much.
Time Estimation: When estimating the time of the tasks, it should be in the presence of your team members as it's a part of the sprint planning. The sprint planning is usually a long boring meeting. For each task, each member will make an estimate. Then the average will be the final estimate of the task. If some member give an estimation which isn't reasonable or far away of the others estimations average, you start to ask him why? He may know something in the task which is mysterious, may take more time or may need more resources. Depending on all these discussions you will get a better estimation and better time management.
Another point, if a task will take more than 2 days, you should start to think about dividing it. Most of the uncompleted and bottlenecks in the projects are the long estimated tasks. The estimation of the long tasks are usually not accurate. Even the scrum master won't be able to know your progress each day if you just telling him "I am still working on it". Try to divide your task to smaller parts so that you can give it a better estimation.
Daily meetings: The essence of the scrum is the daily scrum meetings. If you didn't do it daily you will lose process monitoring. The team activity will be degraded. You won't be able to finish the work on the estimated time. Try to keep on this 15 min. meeting every day. Try to keep these meetings physical as much as you can. I mean here to avoid instant messaging meetings or such stuff. Instant messaging meetings takes much time than the physical ones. People don't take care about the time while messaging and the scrum master won't be able to control it. Try to determine a fixed time for the meeting each day - ideally - 15-30 min. maximum - and make sure it doesn't exceed the time limit.
Code Review: Usually you will need to refactor some parts of your code with your teammates. Code Review Meeting is your way to do that. Problems exists when you try to make "code reviews" as a rule in each sprint. It doesn't work like that. From my experience don't do any code review if you don't have a predefined list of your targets and you really have a problem you want to solve. If you have nothing to review in these meetings, then it will be a hassle and it will be something other than a technical meeting! It will be time consuming and the meeting will end up with nothing. Specify the targets of the meeting before scheduling it. Team members may inform the scrum master if they think there is a part in their code should be refactored in attendance of the other team members.
Design Changes Reporting: Keep all design documents on your source control or repository folder. Make sure that any updates on the designs, flow, sequence diagrams or even requirements modifications are accessible for all the team members. Problems occurred if one of the team members changes something in the design or the flow and didn't inform the others about it. The best practice is to update your documents with any modifications and commit it in your repository. Not only that but you should inform the others about your modifications and the member you think his work will be affected with your changes.
Bug Fixing: During the sprint, testers may start to test your work of the previous ones. Bugs will be accumulated and it's not considered as a part of the sprint estimation. You have 2 choices, either allocate a member in your team to fix all these stuff or assign the bugs to their owners. The later option - if not well controlled - will contradict with the scrum rules. The developers will have an increasing bug list and will feel that they don't make any progress. The solution is to postpone any generated bugs through the sprint to the next one. Testing the work during the development is really a mess . Testers may report some bugs which are features to be implemented on the sprint. Still the bugs should be reported but not assigned to the developers during the sprint. It should be postponed. In the next sprint meeting it will be considered in the developers estimation.
Injecting Members to the Team: You have time constraints and you want your developers to take care of the new features. But in the same time, you have a list of bugs to be fixed. Don't inject external developers to fix these bugs. Especially if they don't have enough idea about the project and the requirements. You will end up with a longer bug list!
This is my review about the best practice which makes the scrum process more efficient. Still it's not that perfect on all the time. Try to modify the process to fit your needs. Although learning and reading is so important to improve your process, but still nothing better than practice.
Dzone - Vote for for this article!
Stumbleupon - Add Your Review
3
comments
Labels
Methodologies,
Opinions,
Scrum,
Tips
