Agile transition – workshopping the roles

When going through an Agile transition, companies face all kinds of challenges. One of the biggest challenges is getting everyone on board and excited about the transition. During the transition at my previous employer in Berlin I talked to many colleagues who raised concerns. I did lots of one-to-one meetings trying to get to the root of it and I figured, that most of them were worried because they didn’t know how being Agile would change their role and responsibilities.

In this blog post, I’d like to share a method a colleague of mine introduced, which helped us to get a reluctant team on board.

In order to help them get a better understanding of the new roles, we started with a brainstorming session to identify the tasks and responsibilities of their current roles. For the sake of simplicity and easier reading, I’ve just added a few tasks per role.

role-matrix1

Click image to view full size

The next step was to add a few columns along the top for Agile roles. We asked the team to move the index cards to the right columns without changing the the rows. This helped everyone to get a better understanding about the new roles’ responsibilities.

role-matrix2

Click image to view full size

Some of the index cards sparked lengthy discussions so we asked the team to see if they could identify tasks that didn’t add any value. Soon enough they added another column (stop doing) for those tasks.

role-matrix3

Click image to view full size

All team members had attended in an Agile workshop previously, so we asked them to add a few new tasks for the new roles. We added an extra row (start doing) and let the team discuss which tasks to add.

role-matrix4

Click image to view full size

Going through this exercise didn’t answer all questions, but the team started seeing opportunities instead of being afraid to lose responsibilities. It also helped us as a transition team to bring the discussion to the teams instead of making decisions for them. They were then able to start thinking about suitable candidates for Product Owners and Scrum Masters.

For a successful successful transition it’s important to have someone with change management skills and not only focus on those who welcome change, but also include those who are more reluctant.

‘Product ownership is a team sport’

Yesterday I went to see Shane Hastie’s presentation on Product Ownership. It was interesting to meet some of Wellington’s agile coaches and I enjoyed the presentation a lot. Having said that, I was a bit surprised that some of Shane’s ideas and statements didn’t cause more controversy. Having just moved to NZ two weeks ago, I kept the questions to myself at the time, however having had a longer think about it there are some thoughts I’d like to express.

The main topic of Shane’s presentation was introducing the audience to the idea that good product ownership requires a team rather than a single person.

He started by asking the audience what they think the problems with product ownership are. I didn’t take notes, so I don’t remember all the answers, but here’s a few:

  • “Product Owner is not the Product Owner.”
  • “Product Owner is not empowered.”
  • “Product Owner is not available.”
  • “Product Owner is just a proxy for senior management.”
  • “The architecture is too complex for the Product Owner.”
  • “The Product Owner does not understand technical debt.”

I agree that some of these issues are serious and have to be dealt with. It is natural to start tinkering with the process and it’s a good thing to do. Instituting a Product Ownership team though will probably not solve the problem, but may make it worse.

I’ve seen those symptoms before and most of them were attributable to a bad or half-hearted Scrum implementation.

Shane used the backlog as an example of why he thinks one person must be overwhelmed by the role of Product Owner. He referred to the Scrum Guide where it states

“The Product Owner is the sole person responsible for managing the Product Backlog.”

The problem with this quote is that it is a bit out of context. In the next paragraph the Scrum Guide states:

“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”

For the sake of the discussion I’ll ignore this part of the guide:

“The Product Owner is one person, not a committee.”

As the guide says, the PO is the one accountable for the backlog. But that doesn’t mean he/she has to do all the backlog refinement alone. I know companies who keep their backlogs completely open, so that everyone can pitch in new ideas. What the Scrum guide says though, is that one person has to be accountable. As it is the Product Owner who is responsible for the success of the product, he/she has to be the one who prioritises the stories. When in doubt which feature is more important, the Product Owner can talk to stakeholders, ask the development team for their opinion and so on.

Shane is certainly right when he says that being a good Product Owner is not easy, because you need to have a lot of skills. Here’s an overview from the presentation.

Screen Shot 2015-03-19 at 8.45.01 am

Although I agree with most of the skills listed on this slide, I don’t think that the Product Owner needs to know about UX and graphic design. I’ve seen Product Owners with UX skills spend a lot of time on upfront design instead. I’d rather let the development team figure out a good UX solution which of course requires having a UX designer in the team. Also I’ve not yet met a Product Owner with legal or compliance knowledge, but they have all managed to deliver successful products regardless.

So let’s take a closer look at what Shane proposes:

Screen Shot 2015-03-19 at 8.45.35 am

Some further thoughts I had during the presentation:

  • large management overhead
  • expensive
  • risking design by committee
  • some of the skills should be on the development team (especially UX/graphics)
  • what is the Project Manager for?
  • this resembles SAFe program layer although Shane didn’t talk about scaling
  • this will probably interfere with self-empowered teams
  • longer decision making process hence longer time to market

For me first and foremost, a good Product Owner needs a vision, good communication skills and a good understanding of his or her role and responsibilities. He/she should know whom to talk to when there are open questions and be there for the development team when they have questions. Does that mean we need a Product Ownership team? I’m not convinced.

What’s your opinion?

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.