Paul has been coaching, consulting and training many organizations in the use of Agile methods since 2008. He has transformed teams using Scrum, Kanban, Extreme Programming, and OpenAgile. He is a Certified ScrumMaster, Certified Scrum Product Owner and a Certified Scrum Professional.
Hi Everyone, I don’t do announcements on here too often, but I wanted to let everyone know about the official launch of our new product: the Scrum Team Assessment – an online tool for your team to get a report on how well they are using the Scrum framework… and most importantly, helpful recommendations on how to improve! This is a fully automated Scrum maturity assessment tool!
The Scrum Team Assessment is based on the years that I and two other coaches (Paul Heidema and Travis Birch) have been working with Scrum and Agile teams to improve business and technical results. The Scrum Team Assessment is a joint effort that has resulted in a fully automated virtual coach for your team.
The analysis is both statistical and expert-system based. This means that the report has basic information about how the team is following Scrum, and, more importantly, clear how-to advice to get your team to make improvements. There are “quick wins” which are easy but will have a significant impact as well as long-term recommendations that are often harder, but will drive your team to a high-performance state.
Every team member fills in the survey to help us generate a valid set of recommendations.
The Scrum Team Assessment is $496/team/use (that’s Canadian dollars). If you have several teams or wish to obtain an enterprise license, please contact us at firstname.lastname@example.org or +1-905-868-9995.
The Agile Manifesto is the founding document of the Agile movement. It can be found at http://www.agilemanifesto.org and if you haven’t read it, it is strongly recommended! Living values and principles is an act of striving for excellence. There are no mechanisms in Scrum to force people to live the values and principles of the Agile Manifesto. Scrum relies on individual team members to strive to develop an understanding and practice of Agile values and principles in and of their own volition. If Team Members do not live the values and principles of the Agile Manifesto in their team many other things will take priority such as creating a complex document. The team could think of Scrum as a tool for project delivery, without really working to change the culture of their organization. Since Scrum empowers individuals and makes obstacles visible, if the team doesn’t live the Agile Manifesto principles then they may be disconnected from the roots of Scrum and make it a lesser version of itself, sometimes known as Scrumerfall (where you blend some elements of Scrum with other elements of waterfall which provides little to no benefit).
As a Team Member, it is my job to figure out how to solve a problem or request that is stated by a Product Backlog Item (PBI), with the help of my team. It is the responsibility of the Product Owner to give us the vision of the product and decide how much scope is to be done to satisfy the PBI. One simple way to think about this concept is that the Product Owner is responsible for the “what” and “why” and the Scrum Team is responsible for the “how” and “who”. If the Team Members decide on the product vision by themselves, they run the risk of misinterpreting features, moving down a path that is not valuable or even creating work disconnected from the needs of those who will be using the software. If the Team Members choose their own scope they may do much less than is needed or much more than is required. There is a balance in the Product Owner providing vision and scope, and the Scrum Team providing knowledge and experience in its execution.
The Product Backlog is a constantly changing artifact, owned by the Product Owner. Stakeholders need real-time visibility into the current state of the Product. Stakeholders should be able to discuss the state of the Product Backlog with the Product Owner at any time, make recommendations and requests. Any change resulting from the request of any stakeholder(s) must be visible in real-time to all other stakeholders. One of the greatest benefits of a highly visible Product Backlog is that it becomes a conversational space for key stakeholders and many others that are connected to or interested in the work of the Scrum team. Of course, a visible Product Backlog also upholds the Scrum value of transparency which is essential for long-term success with Scrum. What if my Product Backlog is not easily visible to every stakeholder? Stakeholders will become disengaged from the work of the Scrum Team, and will forget to give support and/or offer insights into the work. If the Product Backlog is managed in an electronic tool that requires people to login and/or go into a special space that has restricted access then they are much less likely to view it regularly.
The Product Backlog is a list of potential work to be done for future Sprints. This list is most vibrant when as many people as possible contribute to it. Those directly connected (stakeholders such as the Team Members, users of the systems, etc) have a stake in the product’s growth so they also have plenty of ideas that may benefit its value. Adding a Product Backlog Item (PBI) is like brainstorming where all ideas are welcome. Then it is the responsibility of the Product Owner through conversations with others to order the list based on the most value for the least effort (and sometimes to reject PBIs if they are too outside the product vision). If the creation of PBIs is limited to just a few individuals, or even just the Product Owner alone, it is likely that many great ideas will not surface and will be lost. Also by having all stakeholders contribute PBIs, the Product Owner builds collective ownership in the work of the Scrum Team which helps the team overcome obstacles and become supported by a larger group.
One of the key benefits of the using Scrum is that it allows the team to quickly identify defects and obstacles. Now that the team has made these known, the team has the ability to remove and fix these defects. What is the value of identifying problems in the product when nothing is done to repair them? The team will become much faster if it can improve the quality on its own by removing known defects and making the software better. Then the team will be able to take on more audacious goals instead of being weighed down by quality problems. Moving known defects to the top of the Product Backlog places quality work as a central goal for the team to achieve which directly improves the product, makes customers and users of the software much happier and invigorates the team to continue to become more effective. Placing known defects away from the top of the Product Backlog causes morale challenges, acceptance by the team of poor quality work and creates an atmosphere of apathy. These are likely to cause a failure by the Scrum Team to deliver on its goals.
Product Backlog Items are brief descriptions of a feature or function. Usually they are short enough that they could be hand-written on a small note card. This brevity is meant to be just enough information so that the Product Owner and the team can use the PBIs as invitations to conversations. The resulting conversation (ongoing, evolving and involving the whole team and stakeholders) and the shared understanding that comes from that conversation is where the real value of the PBI resides. Part of the conversation occurs when the Product Owner initially writes the PBI so that the team can estimate the effort of building it. Part of the conversation is the actual work being done during a Sprint. Another part of the conversation is during the Sprint Review when stakeholders see the results of the team building the PBIs. If one creates PBIs as detailed specifications then we are essentially handcuffing the team into a set path and a prescriptive solution. The reason we hire qualified people onto our Scrum Team is for their knowledge, experience, and problem solving abilities. If we lock them into a set path, then we are literally turning them into cogs in a machine to spit out specific code. PBIs that are invitations to conversations allow them the flexibility to figure out how to solve the problem by engaging in a conversation on what is needed.
The User Story is a tool developed with Extreme Programming that is almost universally accepted as part of Scrum. The User Story format is an effective way of communicating end user value to the Scrum Team. The first blank is a user (a person, not a system), the second blank is the action of the story (unique), and the third blank is the benefit (for any stakeholder, and outside the system). A User Story is made up of three “C’s”: Card, Conversation and Confirmation. The Card is the written version of the story (usually a physical card on the wall). It is considered to be an “invitation to a conversation”. The Conversation is where the real value resides and potentially involves all stakeholders. The Conversation can cause changes to the Card. Confirmation is the acceptance criteria that, when tested against, confirms the valuable result of the story. A User Story is an extremely effective way of creating light and conversational PBIs – this is why many Scrum teams use them. Another way to view User Stories is that it tells any reader the “who”, the “what”, and the “why” – who cares about this, what is the need/action, and why does the person want this. This is just enough information to make sure that an effective conversation occurs.
All PBIs completed by the team should be “potentially shippable” increments of complete value. In order to do this, they must touch all the layers and components of the product so that the functionality produced is truly complete, not just a prototype… a “slice” through the system. In other words, all of the work that is required for shipping product needs to be completed on all individual PBIs. Creating slices through our system allows the Scrum team to deliver value each and every Sprint and also allows for the Product Owner to change direction to a new feature if it is more valuable for a future Sprint. What happens if we don’t create and complete PBIs that are slices through the system? We risk falling into a pattern of not having a potentially shippable product each Sprint, and, even worse, we may regress into a waterfall type process that produces nothing of value to the customer until the end of the project.
Since the Scrum Team only includes three roles: ScrumMaster, Product Owner, and the Team Members, there is no need to have other people on the team. Each of the Scrum roles has a specific function that requires their full-time attention. These roles are all the roles necessary to accomplish the creation of a high-performance Scrum Team. Adding people to the team who have any other roles will hinder the team from engaging in the requisite amount of self-organizing behaviour.
There are three roles on a Scrum Team, no more and no less. These roles are: ScrumMaster, Product Owner, and the Team Members. It is critical to have all three roles present on the Scrum Team to get all needed responsibilities taken care of in an effective way. The Product Owner is responsible for the product and how the team connects with that product. The ScrumMaster is responsible for improving the use of Scrum in the organization and team, as well as removing any obstacles that slow the team down. The Team Members are responsible for getting the work done by self-organizing and finding ways to improve their own process and work. Without one of these key roles, the team would be missing a key focus and job. As well, Scrum specifically disallows any other roles on the Scrum Team. A person who has an official role of Tester cannot be on a Scrum Team. However, the same person, if given the official role of Team Member can be on a Scrum Team. If people have their official titles, performance evaluations etc. done in their traditional roles, it hinders self-organizing and causes conflicts of interest. A team is not a Scrum Team until those old roles are eliminated.
A very effective learning that has come out of many fields of research is that we function well in small groups, specifically groups that range from five to seven people in total. Scrum allows for a slight expansion of that range up to twelve people. This allows for enough people to be together to discuss issues and solve complex software problems with a diversity of skills and experience. As well as avoiding the problem of having too many people that the lines of communication become overwhelming. If the Scrum Team is only four people, then that means that you only have two people doing the tasks in the Sprint Backlog (since the others are the ScrumMaster and the Product Owner). If the team is thirteen or more people then trying to discuss issues, having a focused Daily Scrum meeting, and even building an effective Scrum Team becomes that much harder. The larger the team, the longer it takes to get to a high-performance state.
Wow! The 3rd and last day of the Scrum Gathering in Seattle was epic! I am tired and thrilled to have participated in such a great day, and such a great conference. Thank you to all who made this happen.
Un-Conference Sessions Using Open Space Technology
This was something that I had some reservations about. What does this mean that we all decide what will happen and how it takes shape? However, this was, by-far, one of the most interesting and engaging parts of the entire conference. Here are the 4 principles of Open Space: (1) The right people show up (2) Whatever happens is the only thing that could (3) It starts when it starts (4) It’s over when it’s over.
There is one law to Open Space: If you are not learning or contributing where you are, find a place when you can learn or contribute.
And there are two roles in Open Space: (1) Bumblebees – these people bounce around to other sessions and add new ideas. (2) Butterflies – these people sit somewhere and look beautiful, and may not attend sessions. I guess that I was neither a bumblebee or butterfly, like most of the participants.
So we were encouraged to come up with topics that we wanted to facilitate and/or learn about and pick a time slot and location. This happened quite naturally – which was added to the marketplace for the participants to choose which sessions they would like to attend and contribute to.
My 1st Session – Team Estimation Game by Chris Sims
This is the first time that I had the privilege of seeing Chris in action. He is a dynamic and very effective teacher and facilitator. The game is another method for teams to estimate effort for User Stories (in Scrum) or Value Drivers (in OpenAgile) or whatever you use for your particular Agile method.
He had us form small teams to estimate effort on consuming various types of fruit (which were on cards) including: grapes, orange, durian, pineapple, apple, blueberries, pomegranate, and coconut.
Step One: This was carried out by each person taking turns and doing one of two things: (1) placing a new card on the wall or (2) changing the position of one card. This was pretty easy and allowed us to have conversations on what we meant when we did an action.
Step Two: Then the team had to add numbers (also on cards) as a way to categorize the effort that would be done. Now each person had three options: (1) place a new card number, (2) moving a single card on the wall, or (3) passing which means that you agree with what is currently on the wall.
My 2nd Session – How to Launch a Team by Roger Brown
Roger showed us a few things to keep in mind when helping to launch an Agile team (usually done by him in a 3 day training on-site).
A ScrumMaster or Coach has certain things to do during the various stages of a team’s development: (1) in Forming, he needs to be directive and tell the team what needs to get done, (2) in Storming, he needs to focus on conflict resolution for the team, (3) in Norming, he needs be a facilitator and observe and then offer ways to improve, and (4) in Performing, he either needs to work on organizational obstacles or move on to another team.
Roger explained how the constant sprint length for a team helps it to get into a rhythm and get data such as the team’s velocity (the speed at which it gets things done). He also offered a great tool for people to use called the Market of Skills which comes from Lyssa Adkin’s book “Coaching Agile Teams”. Other things to use include a team working agreement, team vision, and a definition of done. He said that he likes to spin up 2 or more teams at a time to that they can learn from each other.
My 3rd Session – Collaborative Work Spaces by Skip Angel
Skip made this session very collaborative and got us to add own challenges and questions to a flip chart page and then get us to share how we would solve each others challenges.
Insights included: share visual stories to help the team see benefits, promote outcomes, tools to use for collaboration. Some tools and useful sites: http://sococo.com, http://onemoreagileblog.com, http://cocoo.com, and http://agileadvice.com !
Here is the format that he shared for a User Story: As a (type of user) I want (something) so that (value). Enter the things within the parentheses ( ).
Here are the 4 techniques for splitting stories that he shared: (1) Conjunctions / Connectors – words such as if, and, but or even commas. (2) Generic Words – eg. activities which could be broken into sports, dancing, and board games. (3) Acceptance Criteria – which is a list of pass/fail items that if agreed the story is done. (4) Time-line – which are steps of sequence to get something done.
Met Chris Sims
I spoke for a few minutes with Chris. We talked about David Parker who used to work at Berteig Consulting (where I work) and now works at Agile Learning Labs (where Chris works). Chris had nothing but praise for David!
Sharing by Participants on the entire Scrum Gathering
Each person shared something that they like or enjoyed about the conference. I shared three things: (1) the humility of the Certified Scrum Trainers (CST) and the Certified Scrum Coaches (CSC) to share with all of us their knowledge and their ears, (2) the wisdom of everyone at the conference, and (3) the amount of smiles and laughter that was the reality of all of us who attended.
Closing Keynote by Joe Justice and WikiSpeed
Joe gave an epic keynote on his team that built a car that gets 100+ MPG. It was amazing and super inspiring! I don’t even know what to say about it. He and his distributed, collaborative, and highly Agile team of volunteers did incredible things. I hope to buy one of their cars when I done with my current car. It is that good!
Final Thoughts on the Scrum Gathering in Seattle
So this was my first Scrum Gathering and it was amazing. From the people to the food to sessions to the Open Space to the Certified Scrum Trainers and Certified Scrum Coaches to the people who it made run so well – Fantastic! I hope to attend another Scrum Gathering in the near future. I already plan on attending the one in London, England in October 2011.
So after another day at the Scrum Gathering in Seattle, I am tired! Not just from the sessions, conversations, and the learning but also from waking up in a time zone that is not my own. I live near Toronto which is 3 hours earlier than Seattle. I am slowly getting used to it. Especially that today is a sunny day.
Mastering the Basics of Leadership Storytelling by Steve Denning
Steve Denning showed us how the art of storytelling can uplift and help people to see why a change is needed. He got all of us to do an exercise (1) What’s the problem? (2) What would the world look like if the problem was fixed? (3) Tell the story of the person who doesn’t want the change.
When I did the exercise I though of a client that saw that there was value in using Scrum and Agile but was unable to see the need for organization to adopt them or the urgency to make the change as soon as possible.
Steve also spoke about 3 good ways to get peoples attention: (1) share something unexpected (2) share something relevant to the audience (3) and make it negative. I understand what he is saying but I am more motivated by a positive outlook instead of scaring people by harsh realities. To each his own I guess.
Steve also shared the 7 rules for performing storytelling: (1) maintain eye contact (2) maintain open body stance (3) don’t hide behind notes and podiums (4) use gestures using your whole body (5) dare to pause! (6) practice, practice, practice and (7) be there, be present by planting feet on the ground.
I will co-train with Carlton Nettleton
I met again with Carlton Nettleton who is a Certified Scrum Trainer (CST) out of San Diego. I am excited that will be co-training a Certified ScrumMaster (CSM) training seminar sometime in Toronto during the month of August or September. So… keep those dates open! He is very interesting guy and I have no doubt that he is a great teacher and trainer.
I also met Mike Cohn
If you don’t know who Mike Cohn, I recommend searching for him on the net right now! He is a well-known author, trainer and coach in the Agile and Scrum world. We spoke about our experiences and some of our learnings. I also shared how Mishkin Berteig and I have used OpenAgile to help C-level managers and upper managers to be an Agile team so that the teams on the ground see the example by the leadership. He is open and kind man.
Agile Coach Self-Assessment: Where Do You Stand on Competencies by Lyssa Adkins
This is by far my favourite session that I attended in the first 2 days of the 3 day conference. She got all 30 participants to stand and be players in the session. This is what we need more of in conferences that are in the Scrum and Agile world.
She placed 8 phrases on the ground that were quadrants coming from a centre point that represented parts of an Agile coach. The 8 phrases were: (1) mentoring, (2) technical mastery, (3) transformation mastery, (4) teaching, (5) facilitating, (6) Agile Lean practitioner, (7) business mastery and (8) coaching. We had to do a few things. First, figure which section we were strongest in. Second, choose which section which we wanted to be in. Third, decide which will be our sections to work on (we had to choose 3 in priority) and then choose on section that we would let go.
I also met Vibhu Srinivasan who is one of the newest CSTs (just become one on Sunday). He lives in India and is an extremely nice guy. We were asked to work with one person at the end of the session with Lyssa and then check in with each other to see what progress we made.
Second day was great! Tomorrow we get to be part of the “un-conference” sessions where the participants choose what is important and then prioritize that stuff and work through it together. It should be great!