Working Agreements

Synopsis

In Certified ScrumMaster courses a common concern of new Scrum Masters is how to be a more effective coach and help their teams improve.  One thing any Scrum Master can do to immediately add value and help the team that they are serving is to facilitate the creation of Working Agreements.  Maybe you’ve referred to these as Team Norms, Core Values or Rules of Engagement but for our purposes I’m going to refer to them as Working Agreements.  Why are these important for a Scrum team? Without working agreements, it’s really just a collection of people and not really a team. An effective Scrum Master, as active facilitator, can certainly help the Development Team and Product Owner create these agreements.

The Scrum Master can also be the steward of the working agreements, ensuring that they are posted where everyone can see them. It’s best to keep these short to ensure that they are well understood and of course, ensuring that they are enforced.

What are typical things found in these agreements? They can be tactical, such as the agreed upon times for all Scrum Events and then being on time for these events. They can also include protocol if someone cannot attend an event and how information is shared to those who are not able to attend.

An example would be sending a group text, posting to a Slack channel or sending a group email, so that everyone on the team is aware.

These agreements can also include more cultural aspects of what it means to be a part of this team.  Here are a few examples from our own Collaborative Leadership Team working agreements. We will assume positive intent. Which means, we won’t make bad assumptions about somebody else when we don't have all of the information. Another example is that it's okay to use humor but not to launch missiles at each other. It’s OK to have fun but not to cross a line to put someone down.

Revisit the working agreements from time to time and add new, relevant items or remove items that are no longer relevant.  This is the active way the team agrees to engage with each other so it should be current and visible. Hopefully, these tips have been helpful to you as you begin establishing Working Agreements with your teams.

Video Transcript

Hi. I'm Angela Johnson, Certified Scrum Trainer and Agile Transformation Coach with the Collaborative Leadership Team. Today, I'd like to talk to you about working agreements. Why are these important for our Scrum team? Well, without working agreements or team norms, you might just be a collection of people and not really a team. A good Scrum Master as active facilitator can certainly help facilitate bringing these about. They can also then be the steward of the working agreements, so that they are posted where everyone can see them. Keeping them short, making sure they are well understood and of course, enforcing them. What's in a working agreement? These can be tactical, such as being on time for Scrum events. What happens if you can't attend a Scrum event? There may be a working agreement that says, send a group text or send a group email, so that everyone on the team is aware.

They can also be things that are more cultural and what it means to be on this team. Let me share just a few examples of those from our own Collaborative Leadership Team working agreements. One of our working agreement says, we're going to assume positive intent. Which means, let's not make bad assumptions about somebody else when we don't have all the information. Another one of our working agreements says, it's okay to use humor but not to launch missiles at each other. Hopefully, these tips around working agreements has been helpful to you as you try to establish a few of your own. For more information about what it takes to be a great Scrum Master, please join one of our classes at https://www.collaborativeleadershipteam.com/upcoming-courses. Thanks for listening.

About Collaborative Leadership Team:

Collaborative Leadership Team (CLT) is the premier Agile Consultancy. We believe in the Values and Principles of the Agile Manifesto. Our mission is to train and coach Individuals, Teams and Leaders. This will improve their ability to deliver valuable, consistent, working product. Companies that adopt this way of working will reduce their cost of change and keep up with the evolving demands of their Customers. CLT helps you achieve your goals through Assessments, Training, Coaching and Mentoring.

Since 2006, CLT has had a significant impact on the way people and organizations achieve higher levels of productivity:

  • Over 15,000 Students trained in Agile & Scrum
  • Over 100 Organizations (Fortune 500 to family businesses) are achieving their goals by transforming and adopting Agile & Scrum

CLT brings Agile experience from all areas of business and technology. The Executive Suite, Software Development, Hardware Development, and Team Dynamics & Optimization.

For more information including Training offerings, Coaching offerings, Client Feedback. and more, please visit us at http://collaborativeleadershipteam.com

Sprint Review

Christian: Hi, I'm Christian Antoine.

Dee: I'm Dee Rhoda. We're with Collaborative Leadership Team. Christian, do you do Sprint Reviews?

Christian: Yes, we do Sprint Reviews at the end of every Sprint.

Dee: Okay. Well, why do you do them?

Christian: This is our chance to see where the Product is at and talk to the Development Team that are building it for to see if we're building the right thing, or if we're heading down the wrong way. Good or bad, we always want to show where we're at or where we're not at and share what we're learning.  This is a very important opportunity for the Stakeholders, Executives, and anybody else that is interested in the product, to come and see how the product is progressing.  They can “see & feel” the product while asking questions and giving the Product Owner new ideas about how the product could evolve.  

Dee: Hmm, because, you know, our team didn't really produce anything this last Sprint so as a Scrum Master I was thinking about canceling the whole thing.  

Christian: I can see why you'd think that, but actually it's not necessarily meant to be a demonstration of what you did do. We would like to strive for a potentially shippable product.  If you don't have anything that you can demonstrate, you still have that Sprint Review because you want to tell them, "Here's what we learned," or, "Here's what we're going to try next."  And let them ask questions and get a better understanding of the product.  This is a great opportunity for everybody to come together and have a face to face conversation about the product.  Status reports are good, but nothing will replace the information that can be shared (flowed) during a face to face conversation.

Who do you see at your Sprint Reviews?

Dee: Anybody and everybody that needs to know what's going on with the Product that we're building. I definitely need my Product Owner there teeing it up. I need my Development Team there because they own pushing this out, and I need Stakeholders, Business Partners, and anybody else from other Scrum Teams that might need to hear about what we're doing.

Christian: What about your Scrum Master?

Dee: They have to be there. They're the facilitator of the whole process. They're the one even before the Sprint Review making sure that the Product Owner is ready to do that sprint review.  This meeting is important for the Product Owner to manage the Stakeholders.. This reduces the need for the Product Owner to have a dozen or more one-off meetings sharing information with individual Stakeholders.  Brining them all together into one room allows for information to be shared between Stakeholders.  Sometimes that information may not even have anything to do with the Product, but it is still essential for the organization.  The Sprint Review can help build all kinds of relationships.  

Christian: Cool.

Dee: Yeah.

Christian: How do you capture feedback? Because I'm sure if you showed somebody something, they might see it and go, "Huh? You know what? I don't know if I like that anymore."

Dee: That stuff has to be captured, as you said, and put on the Product Backlog so that the Product Owner can review that with their Scrum Team and anybody else who might be interested in refining that Product Backlog. We call that a PBR.  Product Backlog Request.  

Christian: I think I heard that somewhere.

Dee: Me too. Me too, yeah.

Christian: Let's say the Scrum Team didn't finish some work. They got some work done but some work is not done. What do they do with that work?

Dee: Well, then that needs to be refined. It needs to be a discussion between the Scrum Team, the Product Owner, Stakeholders and Business Partners to decide whether or not we're even going to complete that work, and if we're going to complete that work when we're going to complete it.  Just because the work was prioritized before, it may not be important anymore  

Christian: Sweet.

Dee: Yeah.

Christian: You know, I think we should point them to where we're supposed to go next if they want more information.

Dee: I think we should too. Why don't you point?

For more information about Agile Training and Coaching from the Collaborative Leadership Team, please visit us at collaborativeleadershipteam.com.

 

Who is the Agile Manager?

Who is the Agile Manager?

Collaborative Leadership Team’s Dee Rhoda, Certified Scrum Professional & Agile Coach, shares her perspectives on the role of an Agile Manager.

We all know that there is a very important and prescribed position for managers in the traditional project management world.  These folks are masters of estimation.  They can estimate schedules, costs, resources and all manner of traditional project planning tasks and administration.  I once worked with a Project Manager who could whip up and submit a Change Request faster than my dog could nab a fallen piece of bacon off the floor!  That’s saying a lot because my dog is freaky fast!

Scrum Framework: Let it Work for You

Hi! I'm Christian Antoine. I'm an Agile instructor and Coach with the Collaborative Leadership Team.

I want to talk to you about the framework and how it's set up to help you. Let it work for you. When people learn a different way to approach their work, change brings about anxiety. I've learned to explain the framework this way to help people figure out that it's okay.

When we look at it this way, the framework is actually set up to make sure we don't get too far down the road before we find out if we're on track or not. And, when we look at it this way, we start with the product vision.  If we miss it in the vision, we'll catch it during the road map. If we miss anything in the road map, we'll catch it during the release plan. If we're missing anything in the release planning, we can catch it in sprint planning. If we miss it in sprint planning and we start the sprint, we'll catch it during the daily scrum. If we miss it during the sprint, we'll catch it at the sprint review. If there's something going on with the team, we'll catch it in sprint retro.

Either way, the whole intent of the framework is to make sure we're getting the right people to have consistent conversations to determine if they're building the right product and they're building the product right. So just start. Start with just enough, let the details flush out as you go and trust that the framework isn't going to let you hurt yourself.

 

Startups and TDD: Building The Next Big Thing with Disciplined Agile Engineering Practices

This blog article was re posted with permission from Rob Myers who will be offering the Certified Scrum Developer (CSD) course in March.  

Click here to learn more about the CSD course coming to the Twin Cities.

I've coached and trained so many start-ups who are in a later round of funding, or are building the next release of their software, and wish they had done things differently. Usually, I'm there to help them establish good Agile engineering practices (and help clean up the mess).

I understand the "just get it delivered" pressure on startups, and that they have to beat the competitors (both known and unknown) to market.  But I don't buy into the notion that excessive technical debt must be accrued in the first delivery. It's not necessary, because test-driven development (TDD), pair programming, continuous integration (CI) and other "Agile Engineering Practices" (a.k.a. "Scrum Developer Practices" a.k.a. "Extreme Programming (XP) Practices") all provide actual, tangible benefits; and much more quickly than most people expect.

In my developer courses, I often quote the Nagappan Paper:

The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.
-- research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf, Nagappan et al,  © Springer Science + Business Media, LLC 2008 

If I were seeing my fellow investors get that kind of return on investment, I'd want to get in too.  And early!

Of course, the choice of whether to take on technical debt or to "pay as you go" by adopting these practices from the start would depend on how long it takes for the practices to pay for themselves.  (And, yes, of course each has a cost.)

My friend and colleague, Arlo Belshee, and I were having a conversation about Agile transitions.  Arlo, like myself, is an old XP aficionado (at least, as far as I can tell...sometimes Arlo is hard to read), and we've both had amazing successes and wonderful experiences on full-blown XP teams.  I must have asked him which practices he would suggest the team implement first, assuming they needed to pick up these practices gradually.  He chose continuous integration and pair-programming.

I was a little surprised he didn't include TDD, because TDD resolves so many root causes of trouble on Agile teams. But his explanation won me over:  These two practices immediately provide very fast feedback loops and high-bandwidth communication for the team.

By emphasizing "immediately" I'm suggesting that these practices pay for themselves right away, so avoiding them because they appear costly is a poor bet.

In my own experience, TDD also starts to pay dividends almost immediately.  Even within my 3-day TDD course, many developers report that a single microtest caught something they could not have foreseen.  Software development has become too complex an endeavor to ignore the benefits of a comprehensive safety-net of unit-tests: It has eroded the Amazing Predictive Powers of most programmers.

One client who put all developers through the TDD course reported, after only about 4-6 months, that their latest release was the least defective release they had delivered in many years.  One developer said that a single trivial unit test had saved him from including a defect that would have crippled one high-end (i.e., $$$$) client, and he felt that disciplined TDD had likely saved him his job.

And by reflecting upon merely two of my own longer-term product development efforts that utilized XP, I can think of three cases where TDD+pairing+CI saved or made the organization a significant amount of money (at least $ 1/2 mil/year). Due to the malleability and maintainability of the software, our teams were able to accept a surprising, radical "mini Black Swan" user-story which:

  1. Opened up an entirely new market in a non-English-speaking country.
  2. Allowed doctors to more efficiently use our emergency-oriented software in their routine, day-to-day operations.
  3. Allowed a handful of highly-paid specialists to regain over 60% of their work-week that was previously spent manually transforming and re-entering patient data.

Each of those events was a surprise triple-win (for the customer, the organization, and the team), and each occurred within 6 months of adopting CI, TDD, and pairing.

If these disciplines reap benefits after such short periods of time, then the accrual of technical debt is only appropriate where the product can be written "in a garage" in a matter of days, and an upgrade will never be necessary.  Such products may exist, and they may even be quite useful and profitable (e.g., perhaps a smart-phone app).  I've never been involved in such a product's development, obviously because there would be no need for my kind of training and coaching.  But if I were called in to help develop one of these from scratch, would I still begin with good Agile engineering practices?  Yes!  Because I do not know what the future holds for that product, and I'd want to build in quality and maintainability, just in case we had built The Next Big Thing.

This blog post was re posted with permission from Rob Myers - click here to visit Rob Myers Agile Institute website.