Agile Development
The last years one of the new buzzwords is Agile development. It's a new formal software development methodology. Several methodologies to use Agile are:
- Scrum: Agile Project Management.
- eXtreme Programming
- Crystal
- Adaptive Software Development
- Feature Driven Development
We won't talk about agile itself, but about one of the agile methods called Scrum. But before doing this we have a little note: Agile creates a mentality shift. This will be explained when we talk about Scrum.
Why Scrum? The project that I'm doing at this moment for a customer is a pilot for Scrum within this customer. We have a good feeling with Scrum and our project is going in high-speed.
Now let's talk a bit about Scrum.
Scrum principles:
- As soon as there is a problem, identify it. This is important, because the faster a problem is identified, the easier it will be to pick up. Problems can be logged on the "Impediments" tab in the Sprint backlog (More of this later).
- Analysts know how to analyse and the developers know how to develop. So just leave them alone and let them do their work. In case you need something to ask, go to the Scrum master (see Scrum roles). Important is that the analysts also need to need to have basic to medium knowledge of programming language and the developers need to know how to analyze or read an analysis. Actually, you don't speak anymore of analysts or developers but of a team that works together.
- Make iterations that are not too short or too long. A theoretical/practical good iteration is 30 days. Keep the length for every sprint (see later for an explication) the same. The advantage is that everyone (the team and the customer) has the feeling at the end of a sprint that they end a real product.
- The team must be self-organising
- Try to work on one theme each sprint
- There must be one team room, not 4 rooms for all team members. Communication is very important
Scrum activities:
- Sprint planning: This is the first day of an iteration. It takes 4 hours maximum. The customer sits together with the team, shows the product backlog (see later for an explication) and explains it. Also he gives his priorities to the items on the product backlog. Then the team discusses everything and makes an agreement on what they will deliver within this iteration. Best is that each sprint is centered around one theme (e.g. Database Application, Financial Services,...)
- Sprint planning part 2: In the afternoon, the team sits together to discuss everything and to expand the product backlog items in smaller tasks of maximum 16 hours for each task. The manager (product owner) doesn't assign tasks to individuals, doesn't make decisions for the team.
- Sprint itself. During this period the team does the analysis, the programming, testing and documentation. At the end the team will deliver a Potentially Production Ready Product.
- Daily Scrum: This daily meeting is held in the beginning of the day. It takes only 15 minutes during which the team tells what they have done the previous day, are there problems and what are they going to do during that day. Cannot be used to solve problems. The chickens and pigs (The pigs are the team themselfs, the chickes are people who are just interested in what's going on) are invited. This will help to avoid unnecessary meetings. Only the pigs can talk. The advantage is that the team sees the whole picture every day and it creates a pressure to do what you have said you will do. It can't be replaced by emailed status reports.
- Sprint Review: This is the last day of the iteration. The preparation time needed by the team can be maximum 2 hours (the day before). In this meeting, the team will demonstrate the new functionality to the customer (and all the people who are interested). Typically it takes the form of a demo of new features or underlying architecture.
- Sprint retrospective: This meeting is held only by the team leaded by the scrum master (see later for an explication). During this meeting they will make a review of what happened during the last sprint. What was good, what could be done better,...?
- Sprint Stabilization: This is a short sprint around 2 weeks to stabilize the product and implement it in test or production.
- Sprint Refactoring: Almost the same as the Stabilization Sprint. Only that this sprint is needed to refactor the code.
Scrum practices:
- During the project identify the Impediments and remove them as soon as possible. These Impediments are written down in the sprint backlog.
- Identify the Product backlog
- Define the Sprint backlog
- Be sure that no one can disturb the team. The Scrum master must ensure this
- Product is designed, coded and tested during a sprint.
- No Changes are allowed to the product backlog during a sprint.
Scrum products:
- Product backlog: Is created by the customer (product owner). This backlog defines everything to cover his needs. Every item has a priority. This product backlog is explained on the Sprint planning meeting. The team itself can also add tasks during a sprint for the next sprints, when they have the need that this must be written down to be sure that will be done (impediments). There are two kinds of product backlogs : We can have a functional or a technical product backlog.
- Sprint backlog: the scrum master defines this after the sprint-planning meeting. It contains all the 16-hour tasks divided in sub categories. Also the hours a team member can work during this sprint is written down. Further included is also the team burn down and the individual burn down graphic is added. With burn down can be explained as a graph wich tells us how fast or how slow we go on a all our tasks. A good thing is to use a team member anonymous on which all task are defined. When a team member takes a task for him he changes the anonymous user to his name. This way you don't have to delegate the task before to the team members and everyone can decide every moment what he wants to do (Of course, at regular times the sprint backlog needs to be reviewed to ensure that all tasks are performed before the end of the sprint.). The sprintbacklog can only updated by the team.
Scrum roles:
- Scrum master: The facilitator of the project. He's one of the succes factors for the project. He must work together and support the next 2 roles. Typically this role is filled in by a Project manager or Team leader. He is also responsible for enacting Scrum values and practices. His major job is to remove the impediments.
- Product owner: he is the customer. Acts like one voice (even if it's not one voice). Typically this is a product manager, someone from marketing or similar. The major responsibility is that he knows what needs to be build and in what sequence this should be done.
- Scrum team: the team itself. Typically the size is about 5 - 10 people. Must be cross-functional and those people must work together. Members must be available full-time for each sprint. Some exceptions to this full-time availability are possible, e.g. System Admin,...). Team members can only be added or leave the team between Sprints. The team is self-organizing, so in principle no project leader (like in a standard project development) is in role, but it could (although this job can be done by the scrum master).
Burn Down:
You must be aware that the scrum team has a good burn down.
- No work:
- Work but not fast enough
- Work but too fast
What covers Scrum:
As you can see, every meeting type has it's own coverage. The only link that is missing is between the Product Level and the Development Level. But this is solved by the needs of tasks.
Conclusion:
Comparing tradition approaches versus agile we could say:
Traditional:
Traditional methodologists are a bunch of process dependent stick-in-the-muds who’d rather produce flawless documentation than a working system that meets business needs.
Agile:
Lightweight, er, “Agile” methodologists are a bunch of glorified hackers who are going to be in for a heck of a surprise when they try to scale up their “toys” into enterprise-level software.
- If you want to use agile, try to brew your own cocktail:
Inception: Develop in pairs (Analyst architect + user) and remember your backlog.
- Elaboration: Develop in pairs (analyst/architect + lead developer) and continue to make the use cases
- Construction: Multiple XP teams developing different parts of the architecture. Scrum Master for each team – with Project Manager over all and cross-team pairing for interface and infrastructure issues
- Transition: Integration of different parts of the architecture, but also pairing for fixing bugs and integration
- Start with XP: Use 1-month iterations
- Add other Scrum practices: Scrum master a protection/insulation of the team
- Add use cases from RUP: Architects pairs with marketing staff. Marketing sells use cases to the world, while architects converts those use cases to the developers.
Scrum in a few words:
- Is an agile, lightweight process
- Can manage and control software and product development
- Uses iterative, incremental practices
- Has a simple implementation
- Increases productivity
- Reduces time to benefits
- Embraces adaptive, empirical systems development
- Is not restricted to software development projects
Still remember:
- There's no ideal development process
- Always tailor your process and methodology based on following requirements:
- Scale of project (small team, > 100 developers,...)
- Type of project (real-time, medical,...)
- Experience and type of resources
- ...
Scrum and Visual Studio Team System 2005:
In Team System Microsoft has added the templates to use agile methodologies. It's Microsoft's own definition. A part of it is likely Scrum, but you have to recreate your own templates. Or you can go to http://www.conchango.com/Web/Public/Content/NewsRoom/PressReleaseDetails.aspx?PageID=270. It's still in development
My experience:
When people are leaving on holiday during a sprint, especially in the beginning or at the end, the Scrum Community gives us a good solution :
When folks can't attend sprint planning, reviews, or retrospectives, I suggest they provide proxies
that can fully represent their interests. This keeps the rhythm going and has the added benefit of
cross-training (pairing of sorts for the proxies).
We are going to try this principle during the sprint of December.
Another thing we discover is that at the end, sometimes people don't know in detail what 's done by the other team members. We have proposed a few solutions to the scrum master about this.
- We do intern sprint reviews in between (max 2).
- Every monday morning we will create the tasks for that week.
A scrum team is minimum 5 people and maximum 9 people. Our experience is that 7 team members is the maximum in one team. If you have more than 7 people, you must divide them in more teams. For each team there will be a kind of Scrum master who discusses the overall picture with the other team scrum masters and the scrum master.
The anonymous teammember only is not good enough. It could happens that some important tasks are not picked up by someone. So we decide that the main blocks are not assigned to the user anonymous, but to a teammember. This doesn't mean that he has to do this task, but he has to follow up that the tasks defined in this main block are getting done at the end of the sprint.
And last but not least (at this moment). Several team members still think that the sprint backlog is a kind of time registration tool. This is not the case. Every morning you have to fill in the Sprint backlog with the time still needed for the tasks you picked up. This means that when for a task of 20 hours you have worked 8 hours, you still can fill in 16 hours to go.
Links :
http://www.controlchaos.com
http://www.scrumalliance.org
Scum user stories : http://www.mountaingoatsoftware.com
Scrum Community : http://groups.yahoo.com/group/scrumdevelopment/
Short description by William Wake : http://xp123.com/xplor/xp0507/Scrum-dev.pdf
Howard van Rooijen : http://blogs.conchango.com/howardvanrooijen/archive/category/32.aspx
Conventional Software Testing on a Scrum Team : http://osnews.com/comment.php?news_id=12067
Scrum in Project 2003 : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_pj2003_ta/html/OfficePJScrumToolSolStarter.asp
Scrum Solution Starter : http://www.microsoft.com/downloads/details.aspx?FamilyId=81DAAB54-6701-4FBC-B3D0-7F261383F371&displaylang=en
Thanks to Diederik Krols, My Scrum master at this moment for extra information.
Update :
Danube Technologies has an automation tool for Scrum. Although still in trial period, you can already download it and use it. You just have to fill a few questions about the usage of Scrum. Click here for more info.