One of my colleagues, Jim Heidema, does Agile Project Management with Scrum training for us. He recently ran a class for one of our clients. Part of the class is a simulation to build a comic book that tells the story of the Three Little Pigs. Here is one beautiful, unexpected outcome of that exercise!
Scrum is a tool for product development that uses transparency and fast feedback. The Sprint Review is an open meeting during which the Scrum Team works with all interested stakeholders to look at the results of the Sprint. This meeting is usually dominated by a demonstration of the working increment of software. The stakeholders in attendance at this meeting freely provide feedback about the product which is then used by the Product Owner to update the Product Backlog. This feedback is critical to ensure that the team is staying on-track, that it is building the most valuable possible product features, and that the stakeholders are satisfied with the results. Missing this aspect of feedback makes Scrum only modestly better than non-agile approaches to doing work and should be considered a critical problem to fix as it undermines the whole point of doing Scrum.
Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants. In Scrum, the length of the Sprint Planning Meeting is determined by the length of the Sprint. For example, a one week long Sprint has a Sprint Planning Meeting that is timeboxed to two hours. It is acceptable for the meeting to take less time, but not more. A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours. Keeping the Sprint Planning Meeting timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective planning in a very short period of time. If the meeting is not timeboxed, then typically the team will keep planning until the plan is “done” which usually substantially eats into work time.
The Sprint Planning meeting is the start of the Sprint and is the opportunity for the Scrum Team to discuss what they will build during the Sprint and how they will build it. The focus of the meeting is on choosing Product Backlog Items (the goal for the Sprint) and then breaking those Backlog Items down into a detailed list of tasks (the Sprint Backlog). In Sprint Planning, choosing who will do the work is strongly discouraged. The value of Sprint Planning comes at three levels: first, setting a concrete goal helps with team cohesion and enables high-performance teamwork, second, the planning work helps set expectations with stakeholders and develop a team’s understanding of its own capacity, and third, the time set aside for planning gives the team a chance to think systematically about how to respond to feedback from the previous Sprint.
The phrase “potentially shippable” has a very simple meaning: the features built in a Sprint and all the related activities are done to such a degree that ONLY business considerations are involved in the decision to ship or to not ship at the end of the Sprint. Every Sprint should start with the intention of getting a small set of features to this ideal state. Of course, teams make mistakes and have obstacles to doing their work to this level of doneness. The intention to make potentially shippable software is designed to help teams see and expose obstacles to actually shipping. These can be technical obstacles, dependencies, or bureaucratic obstacles. Failing to have this intention removes this beneficial pressure from the team. This lack of pressure can in turn lead to acceptance of “the way things are” and a team that never reaches a high-performance state.
Each Sprint that a Scrum Team does is an opportunity for learning through “inspect and adapt”. If there is a break or a pause between Sprints, the Scrum Team may forget what it has learned or fail to apply that learning in a timely manner in the next Sprint. Of course, many Scrum Teams end a Sprint before a weekend and start their next Sprint at the beginning of the next week. This non-working break is normal and acceptable. However, a break between Sprints during which some or all Scrum Team Members do other work is not acceptable.
The length of a Sprint determines how quickly a Scrum Team can “inspect and adapt” to changing circumstances and learning. Scrum, as a tool for product development, sets an upper limit to the duration of a Sprint. In other words, Scrum sets a minimum for the frequency of the inspect and adapt cycle. This ensures that teams using Scrum get at least a certain minimum benefit. Scrum does not set a maximum frequency (minimum Sprint length). If a team has a five-week (or longer) Sprint, the benefits from Scrum rapidly drop off. In particular, you dramatically increase risks associated with short term planning, responding to change, team development, windows of business opportunity, and error detection. Having a cycle longer than four weeks is not Scrum and a team with such a cycle length should not claim to be using Scrum.
The Sprint is the fundamental unit of work when using Scrum. Any product development effort using Scrum is, therefore, divided into Sprints. Sprints are fixed in length so that the team has a predictable amount of time available to them to do work, which in turn assists in both short and long-term planning. By making every Sprint the same length, the Scrum Team learns its own capacity for work. If the Sprint length changes, the rhythm of Scrum is broken and a team will have to re-learn its capacity which usually takes at least a few Sprints. If Sprints are rarely the same length, then the Scrum Team will struggle to do any reliable planning.
I am starting a new series of brief articles that go through the details of the Scrum process, artifacts and roles. These articles will be one or two paragraphs each and will have a razor-sharp focus on the fine structure of Scrum. I have found that many people know the broad strokes, but are often missing important details. I hope you find these articles enjoyable and informative.
Many of you have heard that Scrum does not solve problems… it just exposes them! Mike Caspar has written a great in-depth article about why Scrum exposes problems (and why this is good!) with lots of great examples. I like his concluding remark:
Scrum does not have answers for not following Scrum.
Glen Wang, a former student of mine, has written another fantastic article about Scrum called “The Retrospective: Know Yourself and Adapt to the World“.
I love Glen’s philosophical take on things! This article is strongly recommended to any ScrumMasters, Process Facilitators and Agile Coaches out there!
I just finished reading an excellent article about a UCLA prof who, for his game theory class, allowed the students to cheat
I strongly recommend reading this because this points to one of the big cultural barriers to using Agile methods effectively: we are focused on individual performance instead of the outcomes of a group (team) of people!
Coaching Agile Teams course descriptionCoaching Agile Teams is a training experience that covers both the being and the doing of agile coaching. There’s a lot to learn, experience and practice! At the end of the course, you will be capable of applying many new tools and techniques, as well as your own mindset changes, to coach agile teams to high performance. As practical as it is provocative, the Coaching Agile Teams course challenges agile coaches to rise to the fullest expression of their role and offer simple, practical ways to get there.
Outcome
You’ll walk away from the course with your personal coaching improvement backlog – a tangible plan you can use to thoughtfully improve your coaching when you’re back in your daily circumstances. We use your real world situations and scenarios throughout the class allowing you to craft powerful ways to address the challenges you face. You’ll also have many new things to try with your teams and you will probably depart with a few provocative ideas to chew on (in fact, maybe wrangle with for a while). All of these outcomes add up to your ability to become the excellent agile coach your teams need.
Register for Coaching Teams Class here!
http://www.eventbrite.com/event/6102981181?discount=Berteig_promo
OpenAgile London 2013 is the first annual conference focused on OpenAgile and how it is used in organizations by real teams. London was chosen due to the great learning environment with both the University of Western Ontario and Fanshawe College being located here. This conference is meant to help both students and professionals by providing learning and networking opportunities.
The purpose of OpenAgile is to create an environment in which people are free to express their true nature and capacities to contribute to the betterment of their organization.
We welcome you to participate in this informative and inspirational event that will give you the tools for the future of management!
For Registration and more info visit visit http://www.openagilelondon.com/index.html
Hi Everyone,
I’m pleased to announce that a mini-conference for OpenAgile, with some great speakers, has been planned and is ready to accept early-bird registrations! The conference takes place in London, Ontario (yes, there is an airport) at the University of Western Ontario on March 18th.
Check out the conference information at http://www.openagilelondon.com/
I will be one of the speakers, along with some great industry leaders! I look forward to seeing some of you there!