In traditional waterfall software development, the delivering team takes a deliberately linear approach of defining the problem, developing requirements, design, development, test, and finally deployment. Each phase in the process is intended to be complete before the next phase kicks off. Stakeholders have a clear image of how the end product will look, as well as continual insight into the project budget and timeline.
However, this process often breaks down, exceeds budget, and misses schedule. This is due to discoveries made in the later stages that feedback to preceding stages. For example, the development team has completed the development phase and begins testing. During testing, the team uncovers unplanned functional and performance concerns that force the team to return to the design and development phases. Another common cause for rework throughout the process is waterfall does not account for the changing needs of the stakeholders.
In an ideal world, it’s fantastic to have a beginning-to-end mapped plan. But for software development, it has become clear that this process is not very effective in delivering on-time product within the planned budget.
As the landscape around software development began to expand in the 1990s the trend towards structured agile development increased. Agile focuses on delivering a continuous stream of working software (“increment”) in shorter delivery cycles. One common way to think of agile development is it delivers a tiny section of the entire waterfall process in each cycle.
Agile even has its own manifesto that prioritizes:
- Individuals and Interactions over Process and Tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
Here at Corios we concentrate on two similar agile methodologies, Scrum and Kanban, in delivering value to our clients. In both methods “user stories” are entered into a common backlog. Items can be added to the backlog as stakeholders/clients or members of the sprint team add to the requirements. A story can also be removed from the backlog if it is no longer relevant or important to the project. The backlog is “groomed” at a regular frequency to stack rank all user stories and ensure the highest priority user stories land at the top of the backlog.
In Scrum, development is time-boxed at a pre-determined interval called a “sprint”. In most cases, the sprint is 2-4 weeks. To start each sprint the team “plans” which user stories it will try to complete over the course of the time-box. For each story the team identifies the tasks and dependencies required to complete the task. The team also determines the success criteria for each story by defining a definition of “Done” and sizes (“story points”) each user story added to the sprint based on difficulty. The team tries to size the collective sprint activities based on the amount of work that can actually be accomplished during the sprint. At the conclusion of the sprint the team “reviews” its accomplishments by demonstrating and grading the sprint deliverables with stakeholder involvement and closes out the sprint. Before starting the next sprint, the team takes part in a “retrospective” to review the scrum process and identify areas that can be improved in subsequent sprints. Scrum works best with a small, multi-functional group of participants who are dedicated to the project. Each team member plays a specific role. Over the course of multiple sprints the self-learning sprint team identifies its velocity by determining the average number of story points the team is able to complete over the course of the sprint.
Kanban works a lot like scrum but without the scrum ceremonies including the time-box. In Kanban, the team continuously builds a “To Do” list based on priorities. Kanban strives to keep the amount of “Work in Process” at a lean level to ensure the team or individuals are focused on the right priorities while not overburdened. Prioritization of the backlog helps ensure the most important items are picked up as other items complete.
At Corios, we tailor our agile methodologies around the client needs. We face a couple challenges working with client teams. The first challenge is most of our clients aren’t able to provide resources that are dedicated to the project and the second challenge is many of our partnering organizations have processes in place that aren’t conducive to continual delivery, evolving requirements, and adaptability. At the same time, as a boutique consulting firm with a diverse, expanding client base, we are internally challenged with strictly adhering to an agile methodology as we balance priorities with continuous delivery across our client portfolio.
In line with the agile principles, the Corios agile development is a self-learning, constantly evolving work in progress. The pace and comfort level of the client dictates the customized approach we take with each engagement.
For more about how agile develop is used at Corios, please send questions to Jason Doerflein