Why agile?
What characterizes agile software development? (Sander)
At this point in time there a quite a few agile methodologies, that all first appeared around the last years of the previous century. Think of Scrum, currently the most popular process, but also of extreme programming, DSDM, Smart, Feature Driver Development, MSF Agile or Lean Development. Although these methodologies differ in implementation detail, they all adhere to a set of key principles, which are eloquently define in the Agile Manifesto. But even in implementation details, there are a fair amount of characteristics these processes share, such as:
- Close collaboration. All agile projects are delivered in a close collaboration with the customer, and with the different roles in the project team present at the same time, including developers and testers.
- Small unit of work. Agile methodologies all apply a small and equally granular unit of work. Both extreme programming (XP) and Scrum apply stories, feature driven development uses features and in Smart projects, the more structured smart use cases are used.
- Apply short iterations. Projects are run in 2 (or 4) week iterations. Some methodologies only have one type of iteration, such as extreme programming and Scrum. Other define different types of iterations, including DSDM, Feature Driven Development and Smart.
- Test driven. Agile projects test as early as possible. Testing includes both functional testing, for instance based on smart use cases, and unit testing to define and run code tests.
- Delivery driven. Agile projects deliver working software to the customer, as soon as possible and as frequent as possible. Software can be delivered daily, at iteration end, or in releases (most often in 3 month releases).
- Pragmatic tooling. Most agile methodologies apply all kinds of additional tools and techniques, but always in a pragmatic nature. Think of continuous integration, unit testing, stand up meetings, retrospectives, agile dashboards, or burn downs charts.
Scrum in a nutshell (Bart)
Scrum is an agile method for software development that was first implemented by
Jeff Sutherland. The first step in the Scrum process is a vision. The vision describes in a clear and concise way the goal of the project. Establishing a vision is a responsibility of the product owner.
To accomplish the vision a product backlog needs to be created. The product backlog is a
prioritized list of what needs to be done to achieve the vision. It includes functional and non functional requirements. The product owner is responsible for the product backlog but anyone can contribute.
The product backlog is divided into several releases. This, however, is only a starting point and is subject to change. A release normally consists of several sprints. This is where the work is done. Each sprint starts with a sprint planning meeting in which the product owner and the team decide together what will be done in the next sprint. The result of every sprint should be a potentially deployable increment. The team itself is responsible for
managing the sprint. The tasks that are needed to successfully finish the sprint are placed in a sprint backlog. Every day the team comes together for a daily meeting (Daily Scrum) and at the end of the sprint a sprint review meeting is held. In this meeting the team presents the completed work to the product owner. After that the next sprint can take off.
Smart in a nutshell (Sander)
Smart is an agile software development methodology that was developed by Sander Hoogendoorn and his team over the past ten years. Smart originated as an implementation for doing RAD and DSDM projects in 1999, but over the years grew out to be a fully agile project life cycle, and matches or blends in quite well with other agile methodologies, such as Scrum and extreme programming. Smart is used by a growing number of organizations, and is also used in projects that are run using the accelerators of the Accelerated Delivery Platform (ADP) at Capgemini.
As with other agile methodologies and processes, projects that are run using Smart are split up into short iterations. However, unlike other agile processes, Smart defines a number of different types of iterations. In consecutive order these are called
Propose,
Scope,
Realize,
Finalize and
Manage, guiding a project from the very first proposal until application management.
Smart iteration types and iteration cycle
Each of the iterations in Smart follows a straightforward iteration cycle: plan the activities (Plan), perform the activities (Build), and evaluate on the activities (Evaluate). Although the iteration types all confirm to this cycle, the emphasis is different in each type. Each of these types proposes different activities to the list of activities to execute (comparable with the product back log in Scrum), depending on its particular emphasis.
User stories and smart use cases
- What is a user story? (Bart)
- What are smart use cases
Using back logs and work items
- Splitting back log items into work items
Smart use cases and work items
- Applying the smart use case life cycle
- How to split up smart use cases in work items
Estimating and planning
- Smart estimation
- Smart use case points
- Estimation poker
When are we done?
- Defining criteria for smart use cases
- Defining done in Scrum (Bart)
Different roles in Smart and Scrum
- More roles in Smart
- In larger projects we have analysts and testers!
- Scrum roles (Bart)
- Product Owner: the product owner is the voice of the customer. He or she defines the features for the product and prioritizes them according to their market value. It is also the product owner that rejects or accepts the work of the team.
- Scrum master: the scrum master has an enabling role. It is not a directive project manager. His role is to allow the team to do its job and to ensure that the process is followed: invites to daily scrum, sprint review and planning meetings
- Team: a SCRUM team should be self organizing. This means that every member of the team is responsible for managing the team and the team is responsible for getting it done. By doing so the team is highly involved in the project and thus more committed.
Round up
- Scrum fine process - but really lightweight.
- In a lot of projects a bit more ceremony is welcome.
- Mixing Smart en Scrum works well.
- Hints and tips