This snapshot describes the Scrum framework and why you'd most likely choose it to deliver your tech project. There are now many development and project management approaches. For example there’s the traditional linear waterfall and a number of agile frameworks such as scrum, your choice of approach depends on your project’s specifics. While there's no inherently superior approach, most projects that deliver software-based solutions use Scrum or related agile methodologies. Here’s why;
Agile development processes such as Scrum place the developer and “customer” at the project center. These methodologies are particularly applicable in projects that that are in a rapidly changing context or address organizational innovation where solution scope can be volatile. Projects that develop novel products or processes are good examples; stakeholders have limited knowledge especially with respect to interfaces, technology and requirements. Scrum now drives most software development.
Scrum and similar approaches evolved to address the shortcoming traditional waterfall approach have in this setting.
The scrum methodology is based on specific principles that make it particularly suitable for volatile software development projects. The principles are in turn based on key Scrum values such as openness, courage, focus, trust, empowerment and honesty. The principles are;
“Empirical process control” is a phrase coined by Scrum pioneers Schwaber and Beedle. The phrase encapsulates inspection, adaptation and transparency. Based on these principles the Scrum framework is able to handle volatility. In scrum we inspect and then adapt what we are building, hence “empirical”; to do this we need “transparency”. Through transparency we are able to get early and frequent feedback. We cannot always be sure how software development projects will progress since in this field we are not building one item over and over again. The Scrum framework however equips the project team with a context to handle inevitable uncertainties in software projects.
“Iterative & incremental development”: Iterative conjures repetition. This Scrum principle acknowledges that in this day and age, a fair amount of what we’ll do will not meet the standards and will need to be repeated. Software interfaces may be uncertain, requirements volatile, the market rapidly changing and so forth. Incremental means that we’ll build the solution in smaller usable pieces.
Collaboration: The product owner, team and stakeholders need to collaborate closely in order to improve essential feedback and the benefit that feedback brings to the project. It is only with close knit collaboration that the team is able to handle the feedback and adaptation cycle.
Self-organization: The assumption here is that the modern-day tech worker is self-motivated and the team empowered. There’s therefore team buy-in and thus the incentive and desire to self-organize.
Value-based prioritization: The product owner prioritizes user stories, according to business value. The selection of stories for each sprint is based on the desire to deploy usable product subset and hence value early.
Time-boxing: Most scrum activities are carried out in a fixed, predetermined time period. Daily stand up, sprints, sprint planning, sprint review and sprint retrospect meetings. This principle recognizes that time in projects is a limited and valuable resource, its utilization should be carefully calibrated.
A significant differentiator between agile and traditional frameworks is the way you express user requirements. With the Scrum framework you’ll define user requirements and solution features that meet them with user stories.
Anywhere between ten to forty user stories are typical for a software release.
Well known author Mike Kohn describes a user story as following;
“User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a <type of user>, I want <some goal> so that <some reason>”
KOHN, MIKE, User Stories, Retrieved from
Reproduced by permission of Mountain Goat Software, Inc., Broomfield, CO.
User story examples
- As a store manager, I want an email alert whenever the stock levels of any item of inventory falls below 1-week supply so that I can initiate re-order in good time.
- As a store manager, I’d like the email alert to have a URL link that I can click to open the re-order page so that I can re-order quickly without wasting time looking for the link.
- As a librarian, I want a robo-call sent to a member as soon as any book they’ve reserved is returned to the library so that they can it pick up.
- As a librarian, I’d like the robocall to leave a voice mail if the member does not pick up the phone so that s/he can still get the message when he is next at the phone.
- As a fund raiser, I’d like a text message sent to our regular donors to their cell phones whenever there’s a humanitarian disaster so that they can donate via our charity.
The Product Owner owns the vision, defines the product and ensures that it furthers the organization’s goals. S/he aims to maximize its value to the organization. Implicit in this is a very good understanding of the organization’s mission, goals and strategic imperatives on one hand on the product place in this mix on the other. The product owner is the project’s strategic leader.
“The Product Owner is responsible for maximizing the value of the product and the work of the Development Team” - The Scrum Guide by Ken Schwaber and Jeff Sutherland.
The Scrum Master is the delivery leader and plays a role analogous with the traditional project manager. His/her focus is on team coaching and removing impediments rather than planning and control. The scrum master propagates and promotes Scrum values as the Scrum team lead. Because Scrum teams are self-managing and empowered, the traditional project management approach does not model the Scrum Master role.
“The Scrum Master is a servant-leader for the Scrum Team” - The Scrum Guide by Ken Schwaber and Jeff Sutherland.
The Scrum team consists of development professionals; developers, testers and designers.
Chickens and pigs is a term you might hear in discussions about scrum roles. The term “chickens and pigs” originate from a similarly named fable. The scenario is a chicken and pig contemplating a start up; - “The Ham-n-Eggs restaurant”. The chicken can lay eggs to contribute to the restaurant menu and continue to enjoy life but the pig has to lay down his life to contribute ham to the menu. Pig is fully committed to the project while the chicken is somewhat involved. In scrum pigs refer to the committed core project team; developers, the scrum master and the product owner. The chickens are the other interested and involved stakeholders.
Scrum artifacts and processes.
Scrum de-emphasize process and attendant artifacts. Process for process sake reduces collaboration, kills innovation and ultimately lead for fewer working products and tons of documentation. That said process is still important, too little of it will lead to chaos. Processes need documentation and generate artifacts. Scope and schedules need managing and the attendant documents irrespective of the development framework.
While acknowledging the value of process, scrum based projects focus on collaboration and are therefore documentation light. This renders many project management type documents; such as scope statements, system requirements specifications and work breakdown structures irrelevant for most part. If you can craft a comprehensive work breakdown structure that will remain largely unchanged from project start to finish then you are probably not engaged in project suitable for an agile delivery.
Several get together meetings drive the process forward, enable collaboration and flexibility.
- Daily scrum: A brief daily meeting at the start of each day during the course of a sprint
- Sprint planning meeting: A meeting before the start of the sprint in which user stories for the next sprint are selected
- Sprint review meeting: A meeting at the end of each sprint to review the created product subset for the product owner to accept
- Sprint retrospect: In this meeting the team reviews results and processes in order to discover opportunities for improvement
“The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists” - The Scrum Guide by Ken Schwaber and Jeff Sutherland.
The product backlog logically follows the product vision. It's a list of features expressed as user stories that define the solution. The product owner creates it. The project starts with an initial product backlog. The initial and subsequent product backlogs are prioritized. The product backlog is delivered in iterations known as sprints. Sprints develop a subset of the product backlog stories also known as the sprint backlog.
- The product backlog is a list of all desired user stories. The list is dynamic.
- Based on priorities, the product owner selects a few of the stories for each subsequent sprint.
- Each sprint may involve exploratory user stories whose results influence the subsequent product backlog’s stories. Product owner can and often adjusts the product backlog after each sprint
- Product backlog changes are made at the end of each sprint as the solution characteristics become clearer. The product backlog is adaptive, user stories are added and removed with each sprint. This is mechanism that enables scrum embrace volatility.
“The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality” -- The Scrum Guide by Ken Schwaber and Jeff Sutherland.
A sprint backlog is subset of the user stories planned for implementation in one sprint. A sprint is one iteration of the product backlog. The stories chosen are based on the product owner’s priority. A sprint typically lasts 2 to 5 weeks; user stories for a sprint are chosen based on this constraint as well as on priority. For example, the product owner may want to address risky requirements first and will choose stories for an early sprint accordingly. Choice of user stories for a sprint is however negotiated with the team since there may be technical dependencies. For example, if some stories must be delivered before others from a purely technical standpoint.
- The product owner selects the user stories in a sprint planning meeting held with the sprint team members at the beginning of each sprint. In a traditional process the feature implementation sequence for the entire project is set in advance.
- A sprint review meeting is held at the end of each sprint for review purposes, the sprint deliverables can therefore be accepted and any shortcoming noted and addressed in subsequent sprints.
The daily scrum is a brief meeting that starts each sprint day. A sprint typically takes between 15 and 30 days and has a similar number of daily scrums. The daily scrum is central to scrum delivery. It is one mechanism that ensures daily contact between the team members and with the scrum master. The meeting leaves the scrum master with a to-do list in the form of barriers to be removed for team members. The scrum master’s role is more to serve the team members by solving problems.
- Code is produced and tested in daily batches; about 15 to 30 batches in each sprint.
- Only team members can actively participate in the daily scrum
- The meeting is short; each member answers 3 questions
- What did you do yesterday?
- What got into your way?
- What will you do today?
One of the scrum master’s roles is to remove the obstacles identified in the “What got into your way?” question.
The Scrum framework is ideal for software projects and innovation
Requirements elicitation and selection for development in a scrum sprints is done after the product owner has visualized and experienced a subset of product features from previous sprints in action. Requirement elicitation is well informed, realistic and more in tune with real need.
Visualizing a small part of a working application can be an inspirational prompt to the product owner’s [or customers’] innovative instinct. The best innovations come from customers or people close to them. They know the customers and their needs well and intimately. They have the motivation to do almost anything to meet these needs better and more cost effectively since that’s where their bread is buttered. By seeing a piece of technology in action, a product owner is able to imagine new and novel ways to serve his/her customers. These new insights are in tune with real needs since the product owner is, or should be, far closer to the customer than the development team. At the same time the product owner is close to the development team. The result of all this close collaboration is significant customer focused innovation. A traditional business analyst role does not fit neatly into this set up. However business analysis skill sets especially in the areas of requirements elicitation and analysis can be invaluable to scrum masters and developers. Product owners can benefit from knowledge and skills related to enterprise architecture and analysis.
Scrum has almost infinitely more value as a methodology for innovation driven software projects than traditional methodologies. Though this fact is intuitive it may be worthwhile to illustrate with a couple of example projects outside of software development.
The eight year project to land a man on the moon had similar characteristics to a novel software project. It started with the iconic speech by President Kennedy in 1961 and culminated with the moon landing by the late Neil Armstrong and his team in 1969. Neither President Kennedy nor NASA knew much about the project’s scope at the time of the speech. He was setting a vision and initiating an equivalent of a product backlog for NASA to develop. Numerous "spikes", "bug fixes", "tasks" and including pilot and proof of "sprints" such as unmanned missions followed. These were part of what we refer to as epics in scrum project; there were many epics. Much of project work made more information available, validated technology and clarified scope; setting the stage for subsequent “sprints”. The primary aim was to reduce risk to the point where a manned mission could be realistically, safely and successfully carried out. An approach analogous with the waterfall life cycle model would have been unsuitable for the project.
Magellan’s circumnavigation of the globe.
The voyage’s historical account is fascinating. Like most software entrepreneurs he had to get some venture funding; though Portuguese, he successfully approached a skeptical Spanish king as he had little success with Portuguese funding.
He faced uncertainty when he set out from Seville, he did not have the full scope documented; a waterfall like methodology would not work. He had to make decisions as he progressed based on new information that was becoming available.
He was not however venturing into the complete unknown. Many westward voyages from Europe to the Americas and eastward ones to Asia had already been undertaken. The fact that the world is a globe, an important pre-condition for the voyage, had become widely accepted; navigation in previous voyages was based on this assumption and had validated it. He also had a proven craft, a set of navigation instruments and a methodology which had worked well in previous mission to other distant destinations; not to mention quite a bit of experience.
What he did not know is what lay westward beyond what we now know as Latin America and the nature of the passages to Asia through what we now call the Pacific Ocean. His journey from Latin America through the Pacific, Asia, Africa and back to Europe had never been done before. As he progressed he found new lands, entered oceans whose expanse he did not previously understand and faced numerous and unforeseen challenges; many turned out to be lethal to his crew. He had to modify scope and strategy frequently to overcome unexpected challenges and as new information become available. He in effect created sprint backlogs and modified his product backlog every few weeks.
His voyage had a lot in common with modern software development projects that break new ground. They are rooted in a breadth of knowledge about a specific subject matter and have many useful tools at their disposal. Both seek to expand an aspect of knowledge with in depth and fairly narrow investigation. A person building a novel software product probably knows more about the subject than nearly anyone else in the world just like Magellan knew more about the Pacific ocean than any other person at the time. Both can only use a highly iterative approach analogous with XP or Scrum. Both have the potential for almost immeasurable benefit to society.
I hope you enjoyed reading this blog. If you need help driving your technology projects forward, please contact us at your convenience.