Agile Manifesto number four – How responding to change is testing a hypothesis

It’s been ten months since my  first blog post on the Four Agile values. At the time, I was transitioning from a transient life crewing on luxury yachts back into a more grounded career in technology. Agile seemed the perfect medium between the two. Today I’d like to address responding to change over following a plan.

Screen Shot 2013-12-13 at 11.15.05 AM

Agile touts collaboration and demands a high level of communication. Working with a crew of 15 to 30 people on a yacht necessitates the same. Agile says that the best way to keep your clients happy is to constantly deliver something of value. Super yachts are just one big delivery train; meals, locations, experience, pampering, attention, privacy, whatever they want, prepared and delivered on whim.

Agile all but straight out says that people need to be autonomous and trusted and supported. While I would hesitate to say a yachting crew is completely autonomous, I would counter that the best crews I’ve worked with supported each other, encouraged learning and building trust was always the goal. When I came to Boost, I thought I understood what Agile was trying to do. I was convinced that it all made sense to me.

I’ve met people who want Agile but only certain parts, people who were told they should want Agile, people who want their company to be Agile so badly but don’t think they can change it, dogmatic Agilistas constantly reminding us, patient Agilistas who listen and encourage, people who think the word Agile is synonymous with chaos and people who are Agile already and don’t know it. These are people experiencing Agile at different stages in their lives. What Agile means to them today will likely change as they interact more with the Agile community. That’s how people learn, that is how we progress.

If you were to ask me ten months ago how I would run an Agile team I would have given you a list of prescribed actions, all textbook and perfectly sound. Now, If you ask me how I would run an Agile team I’d probably give you a cheeky (but honest) answer like: I’d help them to run themselves.

I don’t think my first answer was wrong. It was what I needed to think to get to more information. It was a hypothesis. That hypothesis lead to new learning which lead to another hypothesis and so on until this moment when I think my job is to help Agile teams run themselves. This too is a hypothesis and I am testing it right now. My goal isn’t to be right about Agile, it’s to help people work together in a way that works for them. How I respond to what I’ve learned about Agile and where it will take me becomes the plan I could never have drafted from the start.

Responding to change over following a plan is a shift to listening and observing to better facilitate a goal rather than trying to control the outcome by making it live up to your expectations.

What hypotheses on Agile do you have and how are you testing them?

Do you need a Scrum Master?

huh

Recently Alistair Cockburn, one of the 17 original Agile Manifesto authors, posted a question he was asked by a person called Gaboo, about the role of the Scrum Master.

Part of any Agile process necessitates stopping and thinking about the quality of the product you are producing as well as the quality of the methodology that is being used (12th principle ~  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.) With this in mind, questions about whatever framework we may or may not use should not only be asked, but embraced and seriously thought about when brought up.

Gaboo wanted to know:

  1. Is there anything implicit which says that the Scrum Master must have background in software process improvement and psychology?
  2. If they don’t have a professional background, how can they judge team dynamics and software development issues?
  3. How can the progress of the team or the performance of the Scrum Master be measured?

I immediately saw why Alistair posted this question. These are all extremely valid questions as the role of the Scrum Master is a bit hard to understand in the business world. Managers are responsible for planning, delivering projects and organising the team. If a Scrum Master isn’t directly responsible for delivering the product and the team decides how they want to organize themselves, what is the Scrum Master responsible for and what kind of skills do they need?

I posted a response to Gaboo’s questions and I answered as best I could without using definitions and doctrine. I tried to focus on my experience with the Scrum Master role and how it fits into our team’s dynamic.

  •  Questions 1 & 2 were similar and I tried to tie them together with this response: 
    It doesn’t hurt to have experience in software if you are coaching software teams, but not in order to solve their problems. It may be useful to have similar experiences to that of the team so you can relate to them. The Scrum Master position is concerned with enhancing productivity through collaboration, not through software or a commanding influence.
  • Question 3, about measuring the progress of the team and Scrum Master, I answered with:
    I think the only way I can attempt to share any insight on this is to indirectly answer your question with the thought that Agile (Scrum) is a framework to encourage empirical thinking/reasoning in a team. If a team isn’t iteratively looking at what it’s producing and how it’s producing it, it isn’t progressing. Because of the iterative nature of Agile (and thus Scrum) this evaluation is always being made. Though there are many tools to measure progress and influence, the very act of iteratively analysing the team is a progress indicator unto itself.

To get the full context of my answers, and a few more tid-bits concerning the Scrum Master’s role with impediments, you can read my full response on Alistair’s blog post on Why do we need a Scrum Master?

These are my thoughts on the subject. I’d be interested to hear about anyone else’s experiences/reservations on the role of the Scrum Master.

The Rope Game

We’ve put together a short video segment on one of the many learning games we play with people to help demonstrate the power of Scrum and Agile.

The Rope Game from Boost New Media on Vimeo.

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

  1. 6 to 10 people  –> to form the circle
  2. 1 person to stand out of the group
  3. 1 metre piece of rope, per person in the circle

How to play

PART 1

  1. Ask one person to volunteer to be a “Project Manager” and step out of the team.
  2. Have the team form a circle (facing in).
  3. 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.
  4. Ask each person, in turn, to pass their ropes across in the same manner until everyone is holding two ropes.
  5. 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

  1. Get the team to form a circle again
  2. Ask them to repeat handing across the ropes to re-tangle themselves.
  3. This time, ask the Project Manager to simply observe and not say anything
  4. 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!

Agile Manifesto number three

Customer Collaboration over Contract Negotiation

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?

Agile Manifesto number two

Working Software over Comprehensive Documentation

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

  1. Individuals and Interactions over Processes and Tools
  2. Working Software over Comprehensive Documentation
  3. Customer Collaboration over Contract Negotiation
  4. Responding to Change over Following a Plan

Agile Manifesto numero uno

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?

The tiny Scrum

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.

From boats to Agile

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.

Explaining an Agile Coach to Mother

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.

Scrummaker: The project kick-off

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

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.