Posts Tagged ‘lessons’

I recently attended the regional Scrum Gathering for 2015 in Johannesburg. This is a post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions. 

devops

I was extremely interested in hearing Biase talk about the journey a large bank in South Africa has recently embarked on to realise the benefits of integrated DevOps. Sadly for me, as we have many of the same challenges, their journey is not yet complete so they haven’t yet answered all the questions! I guess no one will ever have the perfect answer, however some recommendations would have been helpful 🙂

Their journey began with a pilot to try to realise the benefits of a team owning the entire value stream and not having different hand-offs between delivery, release management, and support. Some of the benefits of doing this would include:

  • Improved quality
  • Increased knowledge sharing
  • Increased organisational effectiveness
  • Shorter time to market
  • The ability to deploy faster with fewer failures

Their pilot initially consisted of two teams:

  1. A feature team (building the features); and
  2. A DevOps team (building tools to support CI and deployments for the feature team)

The feature team prioritised the work that the DevOps team did and their working relationship was governed by a set of principles and a working agreement. Apparently, through this experiment, they have realised that having two teams doesn’t really work and it is better to integrate DevOps skills into each feature team. Their challenge now is there aren’t enough DevOps skills available for the number of teams that they currently have, so they are trying to find ways to change that. Rather than taking a push approach, they are trying pull techniques like hackathons, demodays and gamification, to encourage the Feature Teams to build the skills from within.

Biase highlighted a number of challenges they experienced at the start of their journey and also the value of finding experts to help teams work through the technical issues. Their next set of experiments on this journey are related to

  • Growing skills from the ground up
  • Creating the necessary culture shift
  • Allowing for organic growth

I look forward to hearing more about their journey to come. What is your experience in including DevOps skills in your cross-functional feature teams?

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:

One of my teams has recently expressed a desire to become more familiar with XP practices, including more formalised pairing and TDD, and when I offered them the option of doing a code kata during one of our retrospective slots, they were happy to give it a go.

Kata

 

Last year I was fortunate enough to attend a kata at the annual South African Scrum Gathering. The session included some information on what a kata is, some advice on how to run one, plus actually pairing up and practicing. Thankfully the kata used during the Scrum Gathering session was a TDD/Pairing Kata, so I was able to use one that I was familiar with for our first session.

Prep

Preparation entailed
– Sending out some kata context (as not everyone knew what they were)
– Having the team select a development and testing framework and make sure it was all set up
– Finding a suitable room (easier said than done, as it turned out!)
– Sending out some pre-reading about pair programming, particularly the roles and red-green-refactor

From my side, I had to source the kata (thank you, Google) and also enlist the help of some co-facilitators. For this I employed the services of another Scrum Master (who was familiar with katas) and our team architect (who is an advocate of TDD and pairing practices). As you will see from the team’s feedback, having the right coaches/advisors in the room added significant value to the exercise, especially if the majority of your team members are new to the techniques being practiced.

The Session

The Agenda

The Agenda

My session started with an overview of the kata concept and I repeated some key points around TDD and pairing. This probably would not have been necessary if your team is quite good at doing their pre-reading. I did get some feedback that there was too much information and too many instructions up-front, which is probably because both the concept (katas) and the topics (TDD/Pairing) were new ones. In hindsight, some way of splitting the learning probably would have been less confusing. I also printing some of the key TDD/Pairing slides on the back of the kata exercise (although I didn’t notice anyone actually referring back to them during the session). It is important to emphasise that the kata is NOT about how quickly/efficiently you solve the problem, but more about practicing the process to get there. Thankfully, although my team can be quite competitive, I think everyone grasped this.

I decided to run the same kata twice as part of the goal was to actually practice the process itself and one could see the team became a lot more comfortable by the time we ran the second round. We only had an hour, so I opted for 15 minutes per round, which unfortunately meant the round ended just as most teams were hitting ‘flow’. Ideally one would run the kata for half an hour, but in the situation where a team is doing a kata for the first time, I’m not sure whether having one thirty minute Kata is better than two shorter katas to get them familiar. Now that my team have done one, I’d be very comfortable running a single thirty minute session.

The other thing I did was mix up the pairs between sessions. This worked well because people got to see how other teams had approached the same problem plus for more ‘reluctant’ participants (mostly the non-developers), they warmed up by the second round when they realised that most of the team were enjoying the process.

Feedback

 

3Hs

I wrapped up the session with a quick 3H (Helped, Hindered, Hypothesis) exercise to get some feedback for myself on how the session went. Overall, I think it went well and it was nice to see the level of interaction and energy it generated. Generally the feedback was good too, so hopefully I’ll have an opportunity to run more of these in the future. In case you’re thinking of running one yourself, here are some of the things the team felt

  • Helped them:
    – Having an early example (built into our selected kata)
    – Coaches for technical and ‘process’ support
    – Certain team members having experience with the techniques we were practicing
    – Switching partners during the exercise
    – Having the developers write the code (based on instructions) even when they weren’t driving
    – Pairing with someone who thought differently to you
    – Learning in pairs
  • Hindered them:
    – Testing framework (the team could pick what they wanted to use)
    – Too little time
    – Inexperience with katas
    – Initial example was not very clear
    – Non developers lacked context

Links

What have you learnt from running katas? Are there any you would particularly recommend?

 

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?

StoryMap

(This is part 1)

I liked the idea of story-mapping from the first time that I read about it. I’d done a couple of up-front sprint zero type exercises to create and size a Product Backlog at my previous company, and the feedback from the team about the exercise was that, once it got down to the relative sizing, it was hard to keep a grasp on the bigger picture and people often got confused about the relationships and boundaries between stories.

Simply, a story map is a way of maintaining a visual connection between stories as it shows the higher level user process (which also intuitively maps dependencies in 99% of cases) while showing the stories underneath. The other cool thing is that it’s a visual way to ensure one is doing vertical slices – by choosing stories in horizontal groups (so across the user process). Stories are also prioritised vertically adding the dimension that comes from the traditional Product Backlog. One of my team members, seeing our story map for the first time, described it as a ‘seven dimensional view’ of the project. Amazingly, although it has these many dimensions, it’s a pretty simple view to understand and can also be used to show progress.

If you haven’t already done so, I recommend you spend a worthwhile hour watching this video. I’ve also added some other links about story-maps below, but the video is still one of the best resources I’ve come across.

For this two-part entry, I’ll describe a bit of how our very first story mapping session went and some of the learnings I gained from running it. I intend to do some follow-up posts over time as our map (hopefully) evolves.

Our ‘project’ is slightly challenging to story map as

  1. We’ve already started working
  2. It’s about replacing something that already exists
  3. It’s related to our security architecture – so it’s very technical and quite difficult to map from a ‘user’ perspective.

My session (which ended up being two) followed the approach in the video quite closely, so had the following parts/steps:

  1. An intro in which I highlighted the desired outcomes and high level process that we would be following in the session. I also introduced the goal that was proposed by the Product Owner. This led to some debate as it was more business focused, whereas work to date (about a year) had been more about the technology. The team felt there were other ways to achieve business value using the existing infrastructure (a valid point). In hindsight, the goal may not have been the best goal for the session, but it did result in some much-needed debate and clarification and still helped keep the group focused on business value rather than technical goals. I did receive feedback that more up-front detail on the overall process we followed may have been useful in the intro as people weren’t always sure when it was the right time to introduce an idea/concept (none of the attendees were familiar with creating a story map before the session).
  2. The team (individually – silent brainstorming) wrote up stickies (all the same colour – purple) about the ‘things people do’. To help stimulate their thinking, I put up some typical users (we ended up trashing one of them). I also took them through the email example (just the user task level) to help get them to the right level. Once everyone was done scribbling, they did the grouping and naming exercise as demonstrated in the video. We actually struggled with our user tasks being too high level (e.g. manage xyz) rather than too low-level: it did help to try to get the team to start tasks with verbs where they had to break it down a level.
  3. We prioritised the groups and user tasks from left to right and ran through some scenarios. This highlighted a lot of gaps that hadn’t been clear before. At this point the group were getting quite tired and it was nearing lunch time. If I’d had time, I probably would have given everyone a long break at this point. As it was, we only had time for a coffee and tea break. Until now, all the work had been done on a large table in the centre of the room: I now put the skeleton up on the board (not wide enough) for the next part of the exercise. You need a very wide space for story maps!
  4. The next part was not done as comprehensively as we would have liked. We skipped writing stories for some user tasks that we knew wouldn’t be in our first slice and didn’t get into the detail of the second application we’d identified. We also did not write stories for work that we’d already done, which created some confusion later. We still got what we needed out of the exercise, but more time would have been good, and we will need to revisit parts of our skeleton. There’s also a (low) risk that some of the tasks we’ve left out for now are actually risky/important for our first slice.

That marked the end of our first session as we were already thirty minutes over time. Throughout the session, I encouraged the team to write down issues, risks and assumptions on bright pink stickies so that we could ensure we addressed them appropriately and did not forget about them. It also automatically created a parking lot, because anything that was relevant overall but not to where we were in the process could be parked (and eventually they did all find a home, either on the story map or as impediments in our impediment backlog).

Things that I felt worked well:

  • Being strict about using certain coloured stickies to represent particular things. This also made it easier to reproduce the map in a different location!
  • The email example was useful for framing what level we were speaking to.
  • The individual brainstorming and grouping approaches both worked really well. They got people on their feet and everyone engaged once they got the hang of it.
  • Do try to stick to the recommended 5-7 person limit.
  • The product owner was happy to see the team focusing on a business goal rather than a tech goal.

Things that didn’t work well:

  • We didn’t cover all the scope when we created our stories. We may have missed something.
  • Time. In the end, we needed three-and-a-half hours to complete both sessions (which wasn’t far off my gut feel of four hours).
  • Related to time, the team got tired. We could have done with more breaks.
  • The conversation about and agreement on the goal should have happened before the session.
  • Ideally this exercise should happen before work has started, as having done and partially done stories did confuse matters when creating the map.

Links

I recently played a Kanban game with my new Kanban team. I’ve never played an Agile game before so was not sure how it would work, but had heard about the airplane game and how successful it is at teaching teams about flow, pull systems, cycle times, limiting work in progress, etc. After doing some online research, I stumbled across some variations of the traditional game, and was attracted to the Kanban Pizza Game. It looked fun and something everyone could relate to, plus it created the opportunity of actually ordering pizza for afterwards 🙂 The link goes into some detail about how to facilitate the game, so I won’t go into that here. I’d rather highlight some of the lessons I learnt trying to facilitate a game I’d never played or watched being played for the first time.

You need a helper!

There is a lot going on this game, not least of which ensuring teams don’t leave the pizza slices in their oven for too short (or too long without penalties). Thankfully I roped our Product Owner in at the last moment and he also helped with quality control and counting up for scoring, as well as keeping track of which slices had been “spoiled”.

Enforce WIP limits at least once

When I facilitated, I mentioned work in progress limits and enforced that each team had at least three stations (of their choice). In the close-out, one of the teams mentioned that they had set WIP limits but had not really stuck to them – or had changed them on the fly. My feeling is that some of the Kanban principles may have been more clear had these been enforced for the round. In hindsight, it may have worked better from a demonstration perspective to have enforced certain base stations and base limits to start with and then allowed the team to tweak them as the rounds progressed.

Track cycle times

The facilitator’s guide says measuring this is optional (perhaps because you really will need more helpers to do this). My feeling is that we lost a lot of the point by not tracking the cycle times between different rounds and changes to the process. We saw a significant improvement in the number of slices produced between rounds 1 and 2 (and one of the teams did observe that having a pull system – the orders – contributed to this), however, as things became more complicated, the points scored at the end of the round did not always correlate to improved efficiency. Cycle times would have also helped illustrate just how much value was being lost through wasted inventory.

Have a practice round

The group all said that they were more efficient in the second round merely because they had a better grasp of the process and rules. It may be an idea to run the first round twice before introducing Kanban concepts to mitigate this ‘learning’ effect on the outcomes.

Don’t give them timelines

The facilitator’s guide does warn why the team shouldn’t know how long a round is (watch out for clever teams timing a round for better planning!). I did let them know when we were busy with the final round, which in hindsight I probably should not have, as then they paced themselves to make sure there was no excess inventory at the end of the round rather than working towards getting as many orders filled as possible. I guess in real development this approach might make sense, but it didn’t really help from a demonstration perspective.

Outcomes

Things I felt came through quite strongly

  • Having stations.
  • The advantages of a pull system.
  • The group had fun!
  • The fact that the whole process was important: it was not helpful to have a highly efficient stickie cutter if the end-to-end process was too slow to consume the parts.

Things that didn’t come through as well

  • Limiting work in progress.
  • Impact of limiting work in progress on cycle times.
  • Having explicit policies (team felt that they were implicit).
  • Idle time.

Have you run this game before? What did or did not work for you?

Links