We’ve also included the instructions for the game below.
If you are interested in using games to help your Scrum teams, we discuss the topic on our latest episode of The Board, The Board – Episode 6
—————–
The rope game
Time:
3 to 7 minutes
Materials
6 to 10 people –> to form the circle
1 person to stand out of the group
1 metre piece of rope, per person in the circle
How to play
PART 1
Ask one person to volunteer to be a “Project Manager” and step out of the team.
Have the team form a circle (facing in).
Give each team member a rope and ask them to hold it in their right hand and pass the other end to a person standing across from them.
Ask each person, in turn, to pass their ropes across in the same manner until everyone is holding two ropes.
Ask the Project Manager to direct the team so that it is untangled and standing side by side in a circle.
We normally allow them a minute to a minute and a half until we stop the exercise
PART 2
Get the team to form a circle again
Ask them to repeat handing across the ropes to re-tangle themselves.
This time, ask the Project Manager to simply observe and not say anything
Ask the team to untangle itself (typically takes between 20 to 40 seconds)
Learning
This exercise demonstrates the power of a team’s ability to solve complex problems when they collaborate. It resonates with Scrum in that you encourage the team to be self organising to get the full benefit of their abilities.
If you try the game, please let us know how it went in the comments below!
This is the line that made me think Agile was crazy talk. Forever and as long as I can remember contracts were those magical force fields powered by legalese to help protect the customer from us and us from the customer. Admittedly contracts would never work. At best, an issue or change pops up and you go into renegotiation and a new agreement is established and signed and everyone is happy about the forcefield being back up and then BAM! It breaks again.
“What is more insane? Trying something new after what you’ve done doesn’t work or doing the same thing over and over again and expecting a different result?”
Of course when you go into business with someone you want a contract. You want to define the cost of work, budget, resources, etc. Those things are all relatively static. But when it comes to software, why would you sign off on features or specifics about a product that doesn’t exist yet? How can you be sure what you think you want, is really what you need?
Unless you or your customer comes with a crystal ball or a supped up custom DeLorean, it’s unlikely either of you will know for sure what will end up being the most important features in the product. As the project evolves and work is continuously prioritized, those truths reveal themselves. This is even without considering the likelihood that the requirements will need to change for the customer to keep a competitive advantage.
So if our perception of the product will change as we get to know it better through working with it, who better to ensure the quality of the product than the customer? No one. Having the customer with you every step of the way, available for quick questions and clarifications ensures that there is no misunderstanding when the product is delivered. A living and interactive “contract”… some people call it a relationship.
Like any relationship it requires a commitment of time from the customer. Though this may seem like a big ask; the bigger question is this: How important is this product to them?
In Scrum this means that in addition to being readily available, the customer (or Product Owner – PO) also creates User Stories to define the features they need. They then prioritise these stories in order of business value. This small but important act of organization forces the PO to separate the work they need from the ones they want and thus helps the team to continuously deliver a product of the highest business value.
As the project progresses, User Stories the PO thought they needed “without a doubt” in the beginning of the project can often find themselves at the bottom of the pile, with little likelihood of ever getting picked up. As the PO works with the team and prioritizes the solutions they need, they learn more about what those solutions actually are, versus what they expected them to be. Often the team will provide simpler and more elegant solutions than original thought necessary.
Thus the act of creation is also an act of learning, for everyone involved. Understanding this and embracing it as the norm has created some amazing results here at Boost. Not just in terms of products, but also in terms of people’s outlook on future projects.
Getting a client to become a Product Owner can be difficult. Do any of you have any strategies for bringing them over? Or even just some favorite stories about the changes you see people make as they stop being a passive client and become and active PO?
One of the things I enjoy about the Agile Manifesto is it’s depth whilst remaining simple. For instance, the left part of the statements (in this case “Working software”) are preferred to the right (“comprehensive documentation”) though the right is recognized as having importance as well. It’s through comparing the value of one part to another that it eloquently lays out the algorithm for how to evaluate choices in an Agile manner.
In my journey to becoming an Agile Coach I’ve read many articles written by people using Agile to work on interesting projects. Often I run into an argument about the need for documentation and as I see it, it tends to run along these lines:
A) No documentation is needed with well built software and unit tests, because the software should be intuitive and the unit tests read as explanations of the software they test.
B) Documentation is needed on complex systems for other developers to understand software they will have to support but did not create.
I think it is important to note what sort of documentation they are talking about.
Is it a large document defining all the features and interactions of the product before it is made? I would argue that approach is not Agile. It breaks three and perhaps four of the Agile Manifestos (2,3,4 – see below) so I don’t imagine that is the issue.
Is it the Help documentation a user references (search/tutorial) to learn how to use special features of the software? No, that sort of documentation is more of a feature to be requested from the client.
Is it a large document describing the API and explaining the theory behind the features for future developers? I think this is the brunt of it. This could be an actual written document or a reference to detailed comment blocks around each bit of code. While this is not preferred and may not be as lean as it could be, it technically does not violate the Manifesto. After all, the line uses the word “OVER” it doesn’t say Working Software NOT Comprehensive Documentation. The only thing the Manifesto is asking is that if you decide to create comprehensive documentation, you first ask yourself if there is a better way to accomplish the same thing.
At the end of the day it’s up to the customer to decide what is more valuable to them. Writing documentation is not just heavy in time to create it, it is also extremely difficult to maintain. But that doesn’t mean that it should never happen. There may be circumstances when small amounts of comprehensive documentation would be needed. For instance, if an API has a wide range of uses and it is important to point out the features that may not be immediately intuitive. Plus the people using the API would not usually have access to the unit tests that describe it.
Either argument may be Agile as long as they weighed the solution on it’s independant circumstance and not as a rule of thumb.
Are you an Agile Coach or do you work as a developer on an Agile team? How do you view the need for documentation on your projects?
Agile Manifesto
Individuals and Interactions over Processes and Tools
This is a fantastic statement, mainly because it is counter intuitive to how I would think running an efficient group would work. When I first began at Boost I was a bit put off that despite the fact that we are a technology company we still work primarily on whiteboards and with sticky notes.
I have a tic that makes me think that if I am not contributing, then I don’t have value. To an extent it’s a true statement, but I often forget is that perhaps the way I think I should contribute is not what is needed. With that said, when I first began working at Boost I thought of a possible “fix” for them and asked, “Why are we still using sticky notes and whiteboards? Have you considered interactive screens and virtual notes? We could reference, search and track everything digitally?”
Thankfully the people at Boost are patient and nodded and smiled and simply said “We prefer this method. You’ll get a feel for it.”
I most definitely did. It wasn’t long before I noticed how portable, tactile and easy the boards and notes were. Plus when we sat around a table there were no screens to distract us from each other. When tasking out User Stories the team would crowd around them, into a tighter circle and quickly discuss possible actions. When it came time for rating the level of effort of a story everyone played with cards. Their eyes were free to look around the room at what everyone else threw down and how they felt about it.
I have a tendency to try to solve problems with technology mainly because I like tech so much. But in Agile teams, the people are more important than the technology and so must come first. I’ve learned that it is good to look at your processes and see what choices you’ve made around the team that automates something for them but deprives them of physical interaction.
Sometimes the benefit by far outweighs the disadvantages, but it’s important to know whether streamlining group activities is actually helping the group collaborate better or simply making an important process more convenient.
What examples do any of you have, where taking away a tool/process to encourage more hands on, face to face interactions have helped the team?
A Scrum developer team is made up of 5-9 people. But what if the Development Team is only 2? Is Scrum still the right choice?
I’ve recently shadowed a project where there was 1 developer and 1 designer. We were asked to recreate a website that had taken a year to build with another organisation. We recommended the client start from scratch. The catch was that we only had a budget that would cover us for just five weeks.
With the short timeframe and an existing product (albeit a disliked one) to compare against, Scrum certainly seemed like the right choice. It would allow us to deliver the highest value features to the client first, and quickly. The trick was how to adjust Scrum for 2 workers and avoid becoming a Scrum, but.
The team agreed that one week sprints with the PO coming in three times a week (Monday, Wednesday, Friday) for the morning standups would be a good place to start.
All in all Scrum worked well for us in this situation but with the time pressure and the small team there were a number of issues we had to address.
Story Sizing – Our developers are used to two week sprints or more, plus they usually have a number of other developers to help size user stories. For these two reasons they sized the one story they had for the first sprint too small and failed to deliver. The good news was that they weren’t far off and on the day of the first review (in which we couldn’t show anything) they had closed that story.
The team quickly learned from this and took the time we had set aside for the review to break down the user stories in the backlog into more manageable chunks. The retro went well and all of the bumps of the first sprint were addressed. Going forward, the team’s productivity increased with each sprint and at the end of five weeks they delivered a product the client could use in production and that addressed their most pressing requirements.
Team Work - With only one developer you do not get the benefit of multiple minds to find a solution. After all, the reason we work in teams is to benefit from more than one perspective. This was eventually addressed by opening up conversations between other developers in Boost to share solutions to “unknowns” in our team’s user stories.
How Close? – After sprint 2, the developer and the designer decided that they should work side by side to optimize communication. This definitely improved their performance. This need was recognised primarily due to the time frame in this project, in addition to increasing performance it also lead to better sizing of the stories going forward.
Meetings - This wasn’t a problem, just an observation. I was coming from a larger project (6 developers/2 week sprints/indefinite time) to this quick one and it made me feel like the daily stand-ups, reviews and retros went too quickly. The rapid speed in which choices were being made and actions executed left me worried that maybe we going too fast and not discussing enough. Of course the team took just the amount of time they needed with only two people and such a short timeframe to work in. It wasn’t long until I understood this and was able to enjoy the rapid pace.
In the end, Scrum worked great on the two person team. It was particularly important in respect to the constraints on time/budget as it forced our Product Owner to organize the backlog by the value of the features, for example always asking “so if you ran out of budget on this sprint, which story/feature could you not live without?”.
The quick sprints and retros allowed us to address issues with design and expectations as they appeared. The outcome was a site very different from the one originally built, but one that worked exactly the way the client needed it to.
It was a pleasure to be allowed to participate in this project as it really demonstrated to me the power of the Scrum methodology while working with motivated, open and creative people.
I came back and decided to live in Wellington and Agile was why.
That doesn’t mean anything to you, but to me it is everything. In May 2012 I had quit my job as a Drupal developer and left Wellington, NZ to work as a First Mate on a large motor-yacht in the Mediterranean. It was to be the dream job that would get me back into an industry I had left for a relationship in New Zealand that had not worked out.
I liked yachting because I liked working in teams. It was empowering to be a part of an organization where teamwork could mean the difference between life and death or a couple million dollars.
Unfortunately, the summer that should have been amazing, turned out to be a great disappointment. Some of it had to do with systemic structures; the Captain favoring the Bosun (the deck leader directly under my charge) and hiring a temp First Mate (me) until the Bosun could acquire the proper certificates. Others were a failure on my part to properly address the issues as they came up in a transparent manner.
Despite this, we made it through the summer with happy guests, an uninjured crew and a ship ready for a scheduled yard period and another season. The failures I count were basically in terms of my team’s relationships to each other and myself.
There is a high emphasis on “command and control” in the yachting industry. On the best teams I’ve worked with, this means delegation and communication. Work is trusted down to trained teams and communication is always open. Problems are solved together, attitudes recognized in the open and solutions discussed in collaboration. The best deck teams would allow me to focus on safety, provisioning, scheduling, navigation and all of the other duties that a First Mate is often expected to be responsible for. If deck work slowed or the Bosun could be spared, he/she would be invited to participate in the next level of work on the boat, so the ship was in a constant state of sharing and learning.
On this vessel responsibilities were cordoned off. The Captain did not share bridge duties with the First Mate. The Bosun, with two years of experience on the ship, was expected to run the deck and the deckhands were expected to take orders. This left me in a position of authority, yet no actual job. I focused on a safety program, but the Bosun refused my suggestions for daily use and the Captain did not back me.
It soon became clear that any programs I put into place would be dropped as soon as I left. The crew was “putting up” with my presence for the summer. Tensions rose and eventually I saw the situation for what it was. I unofficially (and voluntarily) stepped down as First Mate and helped out in the capacity of deckhand, under the Bosun, to finish the season. It wasn’t something that I felt great about. It was ego crushing, but the good of the crew was more important than my self image.
The Captain had worked his way from 16 meter boats to 53 meter over the course of twenty-five years. He had been a captain all the way through. A capable and kind man, but I found he lacked a practical empathy for those who worked for him. He maintained a system that lead to a high turnover in crew and left him with a holiday every five years.
So the summer ended and I returned to Wellington. I had heard about Boost through a friend and sent in my CV as a Drupal developer. After a few interviews the owner, Nathan, asked me if I would consider being an Agile Coach. Not fully understanding what that meant I asked him to elaborate. I felt it was perfect for me.
So now I’ve started this Agile journey. At Boost my days are filled with daily stand-ups, retrospectives, inspiration games, and heaps of reading. There is lots of sharing and encouragement and while I am still brand new to Agile I’ve come to appreciate it’s power. Boost is the living example of self regulating teams. Agile has set the expectations high in the areas that matter most to people; achieving excellence through being human.
On boats, it’s easy to think people are waiting to be engaged like the propellers or engines you use daily. In a software company it is equally easy to wish people worked under the same logical algorithms you use to develop your software. Rather than trying to trick people into working like machines, Agile demands that individuals be taken into consideration first and that the product is the team.
I never could have guessed it was going to be a philosophy that would get me to stay in Wellington. But then again, I didn’t know about Agile before I came back.
I’ve had a handful of strange jobs in my life and they have always been fun to try and explain them to my mother. When I was in the Yachting Industry it took a while before she understood the difference between working on a cruise ship and a super yacht. When I tried to explain to her what Drupal was, we just left the job description at “I build websites for small businesses”.
Now that I have decided to walk the road of the Agile Coach, I’ve found that the job is so different in nature to what most people think of as a job, that an accurate one line definition doesn’t easily exist. Often, when asked at BBQs or other non-work gatherings what an Agile Coach is, I default to the old “It’s like a project manager or team leader.” Which is definitely not a great way to describe it, but kept me from having to go into a long winded discussion on my day off.
Recently in a conversation with my mother, she gave me the answer that I now use regularly.
Mother: I know you explained it to us before, but your father and I still don’t understand what an Agile Coach does. Me: I coach the team to help them work better together. Mother: So you are in charge? Me: Yes and no.. but mostly no. Mother: So how do you get them to cooperate? Me: The team has agreed that they want to work under a set of ideals defined as Agile. Mother: A set of ideals? Me: Yeah, like thou shalt not kill and such. Mother: Oh, like commandments. Me: No, more like principles. Maybe “thou shalt not kill” is wrong. I guess it’s more like “a penny saved is a penny earned” Mother: Ok. So they all want to work under these principles and you are the enforcer? Me: There isn’t really any forcing at all. I’m there to help remind them that they want to work under these principles. I’m there to encourage collaboration. Mother: So you remind them of something they want to do? Is that really a job? Me: Okay, try this; You know the classic trope of the coach giving his or her team a pep talk right before a big meet right? Mother: Of course. Me: Well why do you suppose the coach does that? Mother: To get them excited about the game. To get them all to share the same goal? Me: Would you say it’s to create a type of collaboration? Mother: Sure. Me: And why do you suppose a coach would need to do that? The team will have trained together for some time, they all know what the goal is, why they are there. Mother: I don’t know. I’d imagine because even though they are all there for the same reasons, they have a life outside of the game, they could be thinking about anything before getting on that field. Or maybe they have doubts. Me: So the coach synchronizes them? Mother: Exactly!.. So is that what you do? You help synchronize the team? Me: That’s part of it, but there is one more element that makes the biggest difference. Mother: and that is? Me: While a sports coach is always in charge of their team an Agile Coach is only responsible for it’s growth. You have to be aware of the elements in the project the team is working on. You need to be intimate with the details and the pressures surrounding it, but instead of making choices for the team, you empower them to make their own choices collectively. Mother: Wait, the team makes choices for themselves on how they work? Me: Pretty much. I’m there to help them make those choices in an Agile way.
My mother considered this for a bit and then said:
Mother: So what happens when they begin thinking in an Agile way by themselves and then don’t need you? Me: That turns into a job well done! Mother: That doesn’t sound like a very good career. Me: Even the best teams can benefit from the occasional visit from a coach. There are always ways to improve. Plus life changes people and as they change the group dynamic will change as well. An Agile Coach can help the team find its way through the changes. Mother: But your goal is still to put yourself out of a job?
I laughed, shrugged and nodded. That was about as close as I would get at that point.
Hello my name is Joe and I’m in the business of putting myself out of work.
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool to support teams to run Agile retrospectives, which we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.
A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.
As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.
The project kick-off
We kicked off our two days of development with a full team meeting starting at 9am sharp – all under the keen gaze of our documentary team.
Vision
Nathan outlined his vision to build a tool that would support Scrum teams, both co-located and distributed. By the end of the two days, Nathan told us, he wanted to have something ready to take out and show to people as the next step in validating this potential product.
Nathan then introduced the product backlog and read out the first three user stories and their acceptance criteria.
Team charter
Next, Paul, our Scrum Master for the project, lead us to create a team charter – an agreement on how we wanted to work together as a team for the two days.
Team charter for the development of Scrummaker
Format:
Half-day sprints
Retro at lunch time
Retro at end of day
Teams:
Three teams (there’s 17 of us)
Communication:
If you have a problem – put your hand up
Be respectful of each other
Everything done face to face
Pro-active communication between teams.
Definition of done
For the purposes of the two days, ‘done’ meant:
Cross-browser tested (IE8 and above)
Technical debt reduced
Merged to master
Passing tests (full coverage)
Internationalised
Deployed
Metrics in place
Split into teams
We shuffled ourselves into three teams, dividing up devs, designers and UX/content people. Nathan then handed out a story to each team, and we reshuffled a little to suit them, allocating more devs to the first (and largest) story. Once we had our teams we moved into three different parts of the office, tasked up our stories and started our story boards. At about 10am, we all kicked off our first sprints.
The next two posts will cover what we learned from our two-day experiment, and Nathan’s over all thoughts.
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.
A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.
As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.
Customer validation: the research process behind Scrummaker
Customer validation has been at the heart of this project. It’s actually seen us take a completely different direction to the one that, three short weeks ago, we thought we were moving in.
Originally, we’d considered building a tool to solve one of our own pain points: turning stories in Pivotal Tracker into physical objects for sprint planning and visible workspaces. At the moment, our Scrum Master or our Office Manager spend a not-insignificant amount of time each week pulling stories out of Pivotal Tracker as CSVs, dropping them into project templates in Pages, tidying them up, then printing and trimming. We’d identified this as a pain point and poor use of our time, and considered building a tool that would integrate with Pivotal Tracker and automate this as much as possible.
We used two frameworks to conduct and capture our customer research. One was Lean Launch Lab, a product that helps you store and visualise your customer research. The other was the Validation Canvas from Lean Startup Machine, a simple one-page format for displaying assumptions, hypotheses, and pivot points.
Validation canvas for Scrummaker (from Lean Startup Machine)
We conducted research in a number of different ways. The most complex was using unbounce to set up a landing page for our theoretical new product. We used LinkedIn advertising to promote the page, and tracked conversions from people visiting the page to following a call to action to sign up or find out more. We ran a poll through the LinkedIn Scrum Practitioners group, and we also conducted a series of email and face to face interviews with Scrum practitioners in Wellington and around the world.
What our customer research rapidly showed was that our ‘printing out stories is a pain in the ass’ sentiment wasn’t widely shared. (Perhaps, being a design-led company, we worry a tad too much about everything looking good as well as working well.) Instead, what emerged was a cluster of concerns around retrospectives:
they aren’t always valued by teams and/or organisations
they are hard to run with distributed teams
it can be hard to generate actionable improvements
it can be even harder to track whether these actions are taken and what the outcomes are.
Some market research showed us that few tools already exist to tackle these problems. At this point, we felt confident that we had a good problem to solve. What could we build that would help Scrum teams run efficient and valuable retrospectives?
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool for teams running Agile retrospectives that we’ve named Scrummaker.
The purpose of the workshop was three-fold. We wanted to build a new product. We wanted to build a new product as a team. And we wanted to build a new product as a team using the Agile practices we’ve been working with now for about six years.
We’re now publishing a series of blog posts to record the two days of product development: what we made, and how we did in. The blog posts are only the beginning; we also had a crew of student filmmakers along for the two days, recording all the goings-on for a short documentary.
The first posts will cover the project lead-in: customer validation of our product ideas, the experience mapping workshop we ran to generate the user stories for the product backlog, the time-boxed technical discussion the team held to ensure we’d hit Thursday morning ready to work. There’s a post on the project kick-off, and then the meat of the series: what we learned from two days of compressed Scrum, and the product we came out of the end of the process with.
So grab a cup of whatever makes you happy and settle in for the read ….
