Agile development is a popular and modern development method, arising in reaction to many defects of the previous reigning favorite, the waterfall model.
The waterfall model of development methodology has existed for several decades, originating in hardware manufacturing. It follows a sequential cycle of planning, designing, developing, testing, deploying and maintenance. Its strength, upfront planning, is also its weakness, inflexibility. Any change to the plan significantly increases time and cost projections. It is not ideally suited to software development.
Besides being slow or resistant to changes, the waterfall method doesn’t allow for customer feedback until nearly the end of the process. Therefore customer feedback has little room to impact the final product. In the practical sense, once a detailed plan is agreed upon, that’s what you will get. Any changes need to be addressed in the detailed plans for a future version.
Many companies today focus on rolling out changes to their user’s requests rapidly, and this old waterfall model, is slow and can’t handle the responsiveness these companies need from their development team.
Agile is more iterative than sequential, releasing early and often, and accommodates a more collaborative approach with customer design and feedback driving development.
Agile is ideally suited to a project that begins without a clearly defined set of requirements. Agile will not begin with a long period of research, planning and document preparation. For some people, this lack of a requirements document is unthinkable, and the waterfall model is likely a better approach for them.
Agile development began with the publication of “The Agile Manifesto”, in 2001. The Agile values as stated by the 17 developers who created the manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
The agile teams I’ve been on in the past three years have been fairly similar, with these concepts in common.
Sprints are one iteration of development cycle, like a project milestone, but instead of being tied to a set of project features, it is based on time. One week or two week sprints. A sprint focuses on delivering as many useful features as possible and release a version at the end which demonstrates progress.
Development tasks are defined within “user stories”, which describe a specific user request. For example, an action to be performed and a result to be expected.
“I will enter a word in the search box and press submit and a list of people matching that word are displayed.”
The process of creating, reviewing, assigning and monitoring progress on a user story is called story boarding, or task boarding. This is often done with software. Rally Story Board is a product I am familiar with. In Rally, after the creation of a user story, it appears in a column of tasks that are available to developers needing a new task. When a developer selects a task he marks it “In Progress”, reviews the user story details for the task, and updates notes for this task recording progress. If the developer encounters an obstacle the task is marked as “Blocked”. Once the task is completed it is marked “Complete”. The story board makes it easy to see the current status of each task, which tasks are in progress, which are blocked and which have been completed.
Daily Scrum Meeting
With the help of a product lead, or scrum master, the development team meets briefly each day to discuss progress. Specifically,
- What have you done since the previous meeting?
- What are you doing now?
- What obstacles are you facing in your current task?
Yeww as an agile project
This yeww project will be managed as an agile project, more specifically as an example of extreme programming and pair programming. This final aspect will be a hybrid version performed solo.
In that I am the customer and the developer, review and collaboration will be successful. As the only developer, code review is de-emphasized, although my readers may serve as an unexpected source of reviewers.
The individual lessons in this lesson series represent the content of my daily scrum meetings with myself, along with a little supporting information, like today’s lesson, to put the rest of the content into context.