Agile can be daunting at first–it’s a completely different way of working, there are a lot of meetings, roles, and a set of principles to follow, so where should a team start first?
We’ll get to that, but first, a quick explanation: You may hear Agile or Scrum. Scrum is a framework within Agile. The idea of Scrum development was based on the article “New New Product Development Game” written by Takeuchi and Nonaka, something Jeff Sutherland and Ken Schwaber went on to use in the 90s independently and then together when they developed Scrum into the framework as we recognize it today. Later, in 2001, a lot of software developers who were operating under different frameworks (Extreme Programming, Scrum, Crystal, and others) got together and developed the Agile Manifesto: a shared set of common guidelines and principles in each of their unique frameworks. We work mostly in Scrum–it’s one of the more popular Agile frameworks, and has a lot of information available to anyone wanting to put it into practice on their own teams. We may mention other frameworks from time to time in our blog, however.
One of the best ways to begin to understand how Scrum works is by doing. Seems scary, right? There’s no better way than to immerse yourself in the process and what it means. I’m not encouraging starting a Sprint without having the fundamentals because having a good working foundation is important, but what I am advocating is if you’re new to this, get the whole team involved and learn how the process works together!
Here’s a quick way to get started:
You need three roles in Scrum:
- Product Owner
The ScrumMaster is responsible for the Scrum process and coaching others through it. They ensure all Scrum Events (essentially meetings) happen, they work with the Product Owner on prioritizing the work, and they help remove impediments for the team. A good ScrumMaster is key to the team. This isn’t someone who is a manager or supervisor–this should be someone on the team who is a peer and who could naturally be seen as a coach for the team. If a Supervisor or Manager is in this role, it becomes difficult for the Developers to speak up in the process. It can be done, but we’d recommend against it.
The Product Owner is in charge of working with the customer to determine priorities for work and setting the priorities. The Product Owner works with the customer to determine what work needs to be done (and in what order). While customers are often external, they can also be internal to your own company, and might be the users of your product–whatever it is you’re producing. Ideally, this role is filled by someone who can make decisions about priorities, has enough time to devote to the role (Managers and Supervisors are often not good fits for this, either because of their other time commitments), and who has (or can develop) a good relationship with customers. The Product Owner will also collaborate with the ScrumMaster to prioritize the work.
The Developers are the team members in charge of doing the work, but most importantly, they decide how the work will get done. The whole idea of Scrum is it’s based on self-organizing teams, and the people who best know how to do the work are the people who are doing the work.
Begin to immerse yourself in information about the process and it’s best if you can begin to understand Scrum as a team and what it means for the work you do together. The team can start by reading books and watching videos (Lynda.com has some great resources), and while we could just give you all of the fundamentals here, so much has already been written that is more in-depth than we’d be able to cover. The problem with most Scrum materials is they’re software-development heavy, so anytime you come across the word “software” or “code” think about what “product” you and your team deliver: you can personalize this and think in your context while you’re reading these materials.
Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland (a great primer to Scrum and meant for the general public).
Scrum: A Breathtakingly Brief and Agile Introduction by Chris Sims and Hillary Louise Johnson (the Kindle version is only .99 cents and helps to explain the Scrum Roles, Scrum Events, and Scrum Artifacts).
Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth Rubin (the bible of Scrum–very technical, but as long as you read it for your own context, it’s useful).
With the team, discuss how these principles and values apply to you as a team. Try to rewrite the values for your contexts and for your own types of work: don’t change the values, but adapt the language for your product. Remember–it’s okay to replace “software” with “product” when learning this process: Scrum can be applied to any context but so little has been written about non-software uses of Scrum that it might feel daunting, so don’t be afraid to experiment for your own uses.
In a later blog, we’ll share how we adapted the Manifesto and Principles for our own non-software work.
Once you’ve learned about the process and begin to understand how the principles and values apply to you and your own work, that’s when you can start planning your own Scrum events, which we’ll discuss in a future blog.
In our next blog, you’ll learn about the business value of Scrum and Agile.