Posts Tagged ‘agile’

chasm1I’m currently a member of a coaching circle and our topic last week was “Non co-located or distributed teams”. Then this week someone from our marketing department approached me. We’ve decided to bring our public website in-house and they need a new team, but history has shown us that finding new developers of the calibre we want is no easy feat. One option we haven’t explored to date is developers who work remotely (which would mean we could look farther afield) and he wanted to know what my opinions were. I offered to compile some information for him, including some of the conclusions from my coaching circle discussion, and then figured it was worth adding it to my blog too.

I have worked in distributed teams before – from formal project teams with developers on-site in Cape Town working with off-site analysts, testers and project managers in London; to informal ‘leadership’ teams across offices over three locations and two countries; to performance managing direct reports working in an office 2000 km away. The common point of success or failure every time? The people on the team. The next biggest point of frustration every time? The type and quality of communication tools available.

People

There is a lot of literature out there around the types of behaviours you want in agile team members and, obviously, each company also has its own set of values and culture it looks for in new hires. This list is a list of traits that stood out for me as things that made someone great to collaborate with when working in a distributed fashion. All too often, people without these traits made distributed collaboration quite difficult and sometimes impossible!

  • Emotional maturity – able to communicate without getting emotional about things; can handle openness.
  • Strong team norms – when the team agrees to try something or work in a particular way, this person will take accountability for whatever they have to do even if it wasn’t their preferred way of doing things
  • Effective communication – verbal and written. Can write and read well. Can get their point across and summarise well.
  • Takes responsibility for preparation – if things are distributed beforehand for people to read or prepare, then this work is done. Doesn’t walk into meetings “blind”.
  • Knows how to use tools and knows about conference call etiquette (this could be covered as training for the whole team).
  • Is proactive in staying ‘in the loop’ – will ask questions if they see something that they don’t know about (defaults to information gathering rather than assuming if it was important enough someone would let them know).
  • A T-shaped person – or at least someone who is prepared to do tasks that are not ‘part of their job description’

 

Other Success Factors

This list was compiled by my coaching circle:

  1. Face-to-face is necessary for initial trust building and to create coherence. Where possible, having everyone co-located for a period at the start of the project makes a huge difference. Also gets people used to the way others work without the ‘noise’ of not being co-located.
  2. Would be helpful to find ways to have online virtual interaction (outside of work) e.g. online games/ice breakers/other experiences.
  3. Face-to-face tools are a must.
  4. After an extended period, it helps to have team members ‘rotate’ as traveling ambassadors.
  5. Need to understand cultural differences. Probably worth having a facilitated session to highlight/understand these.
  6. If you have teams working in areas, then have an on-site SM/coach per team.
  7. Keep teams small.
  8. Try pair/collaborate with an offsite person as often as possible.
  9. If you have teams in different locations, have a dedicated facilitator in each location for meetings (like planning, review).

CoherenceCulture

Links

What has your experience been with working in or with distributed teams? What did and did not work for you?

These are some tweets I made while reading “User Story Mapping” by Jeff Patton.

It’s a great read that I highly recommend!

2

How inspirational!

1

 

 

 

 

4

I like this because it can be applied regardless of the type of product you’re delivering or product life-cycle stage you are in.

3

 

5

If you have the book, I’m referring to the picture on page 71

 

 

6

10

A.k.a. an organisational profile

 

789

1

Grooming ideas

 

2

Grooming to envision a product that is valuable, usable and possible to build.

 

 

 

 

 

 

 

 

 

 

3

Grooming to plan your development strategy. Intention is building what you need to learn the most, first.

4

Grooming to plan your next development cycle (sprint).

5

I’ve always struggled a little with the concept of sustainable pace. Most examples are around team burn-out and not having a ‘death march’. I can buy into that kind of work-life balance idea(l) – although humans generally like a little bit of pressure to get things going – but always felt there must be more to it than that. Then I stumbled across this quote in an article:

‘Sustainable pace’ means that speed takes second place to good QA practices that keep technical debt low.

I like that. How do you feel about this statement?

StoriesThis photo is the list of actions/changes/learnings one of my teams came up with in their most recent retrospective. This did not come from someone who went on training or read an article. It also didn’t come from a new Agile coach or Scrum Master. It came from them missing their sprint commitment and goal. This team only managed (on paper) to complete 8 out of 18 points; but they all knew they had delivered and learned a lot more than that measure reflected.  Here are some things that they decided to do going forward:

1. If the team cannot reach consensus about the size of a story, then split it into two stories and size the smaller stories

One of the main reasons the team had such a poor burn-down is that they took in one quite large story which did not quite meet the INVEST requirements. For one, it was a ‘common component’ that was to be used in most of the later stories (so not independent). It also was not small enough – and turned out to be even bigger than the team had thought. During sizing, there had been some debate about its size and eventually reluctant consensus was to make it the smaller size. Turns out the less optimistic team members were right. This was one of the stories that was not done at the end of the sprint.

2. Keep Planning II – and use it to verify the sprint commitment

This is a team that often decides to skip Planning II (I don’t like it, but ultimately it is the team’s decision and so far we’ve muddled along without it). For this sprint, they decided that they did need a session to unpack the stories and how they would be implemented. Everyone agreed that without Planning II we would have been even worse off. They also realised that at the end of Planning II, there were already some red flags that the big story was bigger than everyone had thought and they could have flagged,  at that point, that the commitment for the sprint was optimistic. The team agreed that, in future, if going into the detail during Planning II revealed some mistaken assumptions, then the team would review the sprint commitment with the Product Owner before kicking off the sprint.

3. Feel free to review story-splits in-sprint

Early in the sprint, the team were already aware that the big story was very big and probably could be split into smaller components. Their assumption was that this wasn’t possible once the sprint had started. For me, re-visiting a story split mid-sprint or once you start the work is not a bad thing: sometimes you don’t know everything up-front. It also, in the case where a story is bigger than expected, gives the Product Owner some more wiggle room (negotiation part of INVEST) to drop/keep parts of the story to successfully meet the sprint goal. Of course, where we have got things really wrong, then sometimes the sprint goal cannot be rescued and the sprint would be cancelled.

4. Raise issues as they happen

Pretty much summarises most of the above points. One of the agile principles is responding to change over following a plan, so when change happens make it visible and decide how to adjust the plan at that point. There’s no point in battling on as planned when you know that the planned path is doomed to fail.

Some references:

This year I managed to float an idea I thought would not see the light of day for a while yet: I convinced my domain owner to let us try a team self-selection exercise. In the end, he and the rest of the management team didn’t need much convincing, and we were given the green light to start the process.

We relied heavily on the very comprehensive self-selection toolkit from NOMAD8 and pretty much followed it as suggested, with a couple of customisations to suit our context. The first piece of work was agreeing on our three missions (for three teams) which for various reasons led to some debate and much to-ing and fro-ing. The conversations to clarify the three missions proved really valuable and I think influenced some better decisions than otherwise would have been made if we hadn’t gone through the process.

Missions agreed we sat down and agreed what kind of skills (hats) would be required to deliver each mission end-to-end. We decided to extend this list to include capabilities that we did not necessarily currently have within the team itself (sadly, our organisation is still organised along components/technologies) to create awareness and hopefully improve cross-team communication. Once we had those, I compiled one slide summaries for each mission with the help of each Product Owner, and emailed them together with a modified FAQ to everyone who would be involved.

Before sending off the self-selection pack, we did also try to ensure every team member had had some face time to know about the new process we were trying. Most people heard about it during team retrospectives (when the question around ‘what happens next’ came up), but I did have to have some one-on-ones with certain team members who had missed out on such sessions for whatever reasons. Feedback was that people appreciated this: some people don’t enjoy finding out about stuff for the first time via email!

Once the missions were defined and the packs sent out, it didn’t feel like a lot of preparation was really required for the session itself. On the day I spent some time setting up the room, but otherwise from a facilitation point of view, everything was pretty much covered in the pack. People expressed various levels of nervousness and excitement leading up to the event, but thankfully everyone was happy to take things as it came and see what happened. I did have a detailed walk-through of the plan for the day with my Product Owners to ensure that they were suitably prepped on their role and involvement.

The session itself went really well. There were about 25 attendees so I’d booked the session for two hours. In the end, we only used just over an hour. Levels of engagement were high. We did about four rounds before stopping and there was a lot of good conversation and switching based on needs highlighted in each squad review. Making the Product Owner’s green/red vote on the viability of the team very visible also helped highlight a problem in rounds three and four: no matter how the teams shuffled, we didn’t have enough developers to create three effective teams. This was very visible to all and has subsequently led to the re-consideration of priorities in line with the capacity that we do have.

Feedback on the session in general has been good. The Product Owners were very happy with the outcomes of the session. Various team members said it was the most useful and best facilitated session that we’d ever run. Some did express the view that people generally ended up where their managers wanted them anyway so felt that we may as well have just decided on the teams in advance, but I’d like to believe that, even if people had been asked beforehand to select a particular mission, ultimately they still made their final choice/decision using their feet on the day.

Some take-aways:
1. The pack recommends sending information out at least a week in advance. I think this is very important, if only because it forces the Product Owners to commit to what their mission actually is.
2. Having conversations either one-on-one or with groups of people before sending out formal communications is important. It helps them get used to the idea and allows them to ask questions. Don’t be afraid of not knowing all the answers: quite often the answer is that it depends on what team forms on the day.
3. The pack also says this, but I’ll reinforce, because of all the unknowns due to not knowing how the teams will form, don’t expect to have new teams up and running from the very next day. One of our teams kicked off the following working day (with some team members handing over other work over an agreed duration), but another of our teams will only get going in a couple of weeks.
4. Don’t underestimate the power of physical movement. Ensure your stations are far enough apart that people have to physically move to join a station (and can’t hover somewhere in between). Having the Product Owners stand in their own ‘corner’ and then add a green or red sticky to the squad board after each round was also helpful (in our case all the Product Owners had a say in approving the team composition).
5. My biggest challenge was getting people to quieten down when we needed to end a time-box! Ensure you have some mechanism agreed for this up-front. The usual agile workshop “hand up and mouth shut” works well (if some people know what it means). Someone in the session suggested playing music in the background and stopping it when we needed to evaluate the squads: a bit like musical chairs. I thought that sounded quite fun 🙂

Have you ever tried to run a self-selection exercise before? What was your experience?

Sample Squad

Sample Squad

 

Constraints to consider

Constraints to consider

Focus On / Focus OffRecently another team, that had recently read an article around team dysfunctions and appreciation exercises and wanted to explore the health of their team, particularly their trust levels, more closely, asked me to facilitate a retrospective for them. Facilitating a team you don’t know or regularly observe is usually a challenge, but it was one that I was up for, and thankfully the team member who arranged the session had a good idea of the feel/discussions he was hoping for as an outcome.

I started the session with the Focus On / Focus Off exercise. As English was not everyone’s first language, I prepared cards with synonyms for each of the word pairs. I had the team discuss each word pair and what they understood the differences to be together, and then gave them the synonyms to arrange under the correct ‘word’ in the pair. After we had been through the exercise for each word pair, I asked the team whether they were willing to commit to continuing the session with the correct focus (and, thankfully, they said yes!).

From there we moved to a simple Sad/Mad/Glad exercise with a strong focus on the team and its interactions. I’d found out before that the team members were more introverted, so I opted for silent brainstorming separately before each team member shared their feedback. The first two parts of the session actually went by more quickly than I’d planned, so I took the opportunity to then allow the group to move their Sads and Mads into physical circles of control, influence and soup. While they were doing this at the whiteboard, they automatically moved into a space of discussing what actions they wanted to take for the issues within their control. It was nice to see them being so pro-active about taking control.

We finished the one-hour session with a Temperature Reading. As this session was more about sharing and uncovering information rather than actions, I wanted to leave the team with some items for them to possibly work on or think about more deeply in their next sprints. The temperature reading also includes an appreciations section, which I have found really energises teams and helps end the session on a positive and optimistic note.

Feedback is that the guys really enjoyed the session and would be keen to have me back to facilitate another. Hopefully this one wasn’t a fluke! 🙂 Have you ever had to do a once-off session with a team you don’t work with? What tools or activities did you find generated the most valuable outcomes for the session?

Resources

This list from a recent retrospective made me happy :-)

This list from a recent retrospective made me happy 🙂

 

77fb900d0923c2cdff00ab346fa453abOnce upon a time there was a team called the Kanban team. But they didn’t do Kanban. They had a task board and they tracked their work, but that was it. The Kanban team also had a new agile coach. This new coach wasn’t very familiar with Kanban, but did some research and realised that the team was missing some basics. The team met and did some exercises and reviewed their processes and board and made some changes – changes supporting Kanban basics. But these changes didn’t stick. And the team didn’t really like the new board. And the team didn’t feel empowered to improve on the new board. The fact that the lanes were taped onto the whiteboard also meant it was hard to change things on the fly, so in some cases the team could also not be bothered.

The agile coach was frustrated. The team was not learning and they were not growing. Their environment was changing and they were not adapting. They didn’t actually want to do Kanban. They had a broken information radiator. The agile coach decided to watch and wait. The more she watched the more she realised what the gaps were – where the team needed feedback – but she was at a loss as to how to resolve those gaps. She had conversations with certain key team members and stakeholders. She shared her concerns and observations. She created awareness through conversation. However, the team were not yet ready to tackle these things. They needed some guidance and direction. So she waited. And researched. And discussed. And watched some more. And then another agile coach recommended she read “Lean from the Trenches”. And she realised that this was what she had been searching for.

Having learnt from the first attempted iteration of the board, the agile coach decided on a different approach to presenting the changes. Thankfully these changes could coincide with a team reshuffle: the Kanban team would be no more. There would be a new team – a mix of old and new team members. And the incoming team members were familiar with Scrum and simple task boards. This provided a ‘good excuse’ to advocate some changes to the information radiator. So what she did was:

  1. Use the ideas from “Lean from the Trenches” together with her observations of how the team worked and the type of work that they tackled to draft a new task board. She made sure that the new task board still included the information the team found valuable on the current board – even where it was currently hidden or somewhat confusing. She also included some basic changes she hoped would help generate feedback to guide team-driven improvements.
  2. She shared her board with team members individually. She asked them what their thoughts were. She asked them for questions and feedback. She was happy to see that they quickly connected the new and the old and found the new version simpler to understand.
  3. She shared that she was going to remove the permanent lines. The lines would be drawn with whiteboard markers. It would be easy to change the board. Things would be more flexible.

Eventually the big day arrived. The agile coach and one of the analysts mapped the existing stories and tasks to the new board and then the hard work of ripping down the old board began. Come Monday morning, the new board was ready for stand-up. There were still some questions and some of the stories/tasks moved a bit during the session, but even from day one the process was working better:

  1. The team solved discrepancies on the board themselves. With the previous board iteration, they had turned to the agile coach when they had a question or weren’t sure how to use their information radiator instead of finding a solution for themselves.
  2. There were already suggestions from the team around how to tweak the board. They were already taking on ownership of their information radiator.
  3. It was VERY visible that work-in-progress was piling up on one of the key stories – and that there were in progress stories or tasks that were not currently being worked on by anyone.

The key take-aways?

  • Don’t be afraid to try something new.
  • Be ready for failure – ideas won’t always work the first time round, but that’s how one learns.
  • Persevere: if at first you don’t succeed; try, try again.
  • And once it’s initiated, let it go – ultimately the team needs to own the change.

What changes have you struggled then succeeded to make in your team recently? What techniques eventually led to your success?

Dual Track Scrum

Dual Track Scrum

This week I stumbled across an article which referenced something called “Dual Track Scrum” (see the links below). Intrigued, I researched a little more and was fascinated to discover that there was a documented process/approach to product development and delivery that was very similar to what had evolved for a product team I previously worked with.

This isn’t the first time this has happened to me. The last significant deja vu experience was when I found that there was a name for a software development approach that included: time boxing; daily team check-ins; planning and estimation as a team; work defined on a physical card on a white board; a definition of done for the time box that included all delivery activities; and a list of features that could be traded in and out if not yet started. Yes, that was the day I discovered that the approach our team had “created” to successfully deliver an off-shore project was, actually, called Scrum.

Links:

StoryMap2

(Part 2 of 2)

As we were unable to finish the story-mapping process in a single session, we had a second session the following day. As prep and to save time, I asked the team to bring their top six user stories written on separate stickies. Following the approach outlined in the video, we grouped and prioritised their top stories and then I asked the team to pick their overall top five. At this point I also introduced the concept of tarred vs cobblestoned vs dirt roads (stories):

  • A dirt road is minimum implementation with manual workarounds; something that will be in place for a limited time span (throwaway)
  • A cobblestone road is a bare minimum implementation with foundations for a longer term solution
  • A tarred road is a complete implementation: a ‘done done’ story

Cobblestone and dirt road stories were written on an orange sticky, while tarred road stories were yellow. Even with this mechanism, the team were not able to get their first slice down to less than seven tarred stories – which was still great going 🙂 With our first slice agreed and our pink risks/issues added to the appropriate place on the map, we had just enough time to do a bucket estimation exercise. For this, I laid a set of planning poker cards on the floor to create buckets; picked a story as a baseline (I chose one we’d already implemented for more context); and then everyone had to add stories to the buckets according to where they thought they should go relative to the baseline. This is a mostly silent exercise. For the first part each person is given a random pile of stories to place into buckets. For the second part, everyone reviews and (silently) moves stickies to different buckets if they disagree with where they have been placed. If a stickie moves a lot, it is parked. When the stickies stop moving and stabilise in their buckets, then the parked stories are discussed to understand why there are differences in opinion and the team should then reach consensus on which bucket each parked story belongs to. We didn’t have to do this last part as everyone was more or less on the same page about where things belonged.

As an aside, after we’d created our map, I reviewed our completed work and added those stories into it as well. We will be tracking progress on our map as we go. It is recommended practice to write duplicate stickies for your taskboard and not leave gaps in your map. I can see this also making sense where a ‘map story’ may need to be broken down into smaller stories for sprint purposes (if your team is using Scrum). For us, a map story that is in progress gets a dot (sticker) and, once it’s done, we tick the dot. It’s visual and easy to follow.

After a total of three-and-a-half hours we had the following:

  1. A better understanding of the short-term and long-term goals of the project.
  2. A ‘first slice’ to test our architecture, resolve some technical challenges, and deliver some business value in production.
  3. A first pass idea of the size of the full scope of work.
  4. A picture view of all the above with a visual way of showing progress against the overall scope.

Things that I felt worked well in the second session:

  • As we don’t have a team room (so were using a shared meeting room), I did have a challenge with the session being split over two days as I needed a quick way to reproduce the map for the team for the second session. In the end, I took photos of the various sections and printed them out in colour and that was enough for the team to refer back to (helped by the fact that they had all rewritten their top six stories on stickies for the second session anyway).
  • The road analogy helped create a common understanding of the level of work we were targeting and using a different colour to represent work that was not ‘tarred’ made it clear where we would have to revisit items to fully complete the story.
  • Giving people a very strict limit initially. I doubt we would have ended up with a slice of seven stories had I not been so strict about trying to get the team to only pick five.
  • The sizing exercise got people off their feet and moving around (automatically creates more energy).
  • The sizing exercise took all of 15 minutes, so high value for small time investment.

Things that didn’t work well:

  • Some of the team members were unable to attend the second session. We decided to go ahead anyway, but this did impact the perceived value and accuracy of the sizes.
  • The team haven’t taken ownership of the story map (still perceived as ‘my thing’). Need to find a way to change that perception!

Links

  • Part 1
  • More detail on bucket estimation
  • This article describes two techniques: Affinity Estimation and Bucket Estimation. I’ve used both before and I so far have found bucket estimation is quicker so better for large backlogs (value:time ratio for affinity estimation doesn’t seem as good).
  • Affinity Estimation How-to