Author: Martin Oesterberg

Martin Oesterberghttp://agilelogbook.com

Time for a new manager – let the group choose

At the company I work we faced the task of assigning two new managers for a group of consultants that were without a manger and also had grown too big for just one person to look after their needs. Traditionally this was done by our CEO and some other managers who looked for someone in-house by talking to people they thought were suitable for the job or sometimes by looking for people from the outside. Historically this had sometimes worked well and other times not so well.

This time we thought we should try something new. Why not let the members of the group choose?

3-leader

Our process looked something like this:

  1. We informed the group of what we were about to do and why we were doing it.
  2. We created a form with Google Forms that was sent to all the members of the group. It contained these two questions:
    1. Would you be interested in being the new manager for this group? (yes/no/maybe – tell me more)
    2. Who do you think would be suitable to be the next manager?
  3. After everyone had answered we gathered up the results and started talking to everyone who had given a “yes” or “maybe” answer to the first question. During that meeting we discussed their view on leadership and the challenges they saw from their point of view. We also answered any questions about what having this role would mean.
  4. We selected two candidates based on the number of nominations (this was the main thing we considered) but also looked at their view on leadership.
  5. We split the group mainly based on the nominations but we also considered social connections and other similar factors.
  6. We then talked to all the members of the group individually and asked them if they were happy with their manager to be or if they wanted to belong to the other group. If someone wanted to swap we let them without any questions asked.
  7. We talked to the new managers and told them what the groups would look like and helped them get started.
  8. Done.

This process became quite lengthy but the really great thing about this approach is that we have eliminated a lot of risks involved in a change like this. The new manager was instantly accepted by the group and the managers knew what they were getting themselves into and knew that they were accepted in their new role by their group.

This is still quite new and we will see how it plays out in the long run but from we have seen so far this is a really good approach when appointing a new manager or leader for a group.

Shorten your feedback loops with Cafe Testing

One of the teams I have been working with lately develop and maintain a retailing web site. Historically what they should focus on was decided by someone high up in the organization with little to no involvement of the team. After a lot of time and money invested most of those ideas turned out to have little to no impact on the number of purchases made through the site. To remedy this we wanted to leverage the collective intelligence of the team and also use a more scientific approach when deciding what to do. The approach we took drew inspiration from Lean UX and Lean Startup. We also used tools like Impact Mapping where the idea is to have a clear goal of what we want to achieve, see what actors could affect that goal and then look at what assumptions we have about those users related to that goal. After that we have our Impact Map and it’s time to get to work with the assumptions. We did this in really short iterations to keep the investments small if assumption turned out be false. One really useful way of validating ideas we found was to do lightweight usability testing. The way we did it often included theses steps:

  • We have an idea or an assumption about how we can better achieve one of the goals we are striving for at the moment. We selected the assumption that we thought could best contribute to the goal.
  • In the most lightweight way possible we create a mockup, prototype or MVP that could in some way validate or invalidate our assumption.
  • The next step is to do the validation and now it was time to get out of the building. We found that a good place to find test subjects was at a café at the grand central station in Stockholm. The benefit of this is that you find people from all over the country of all different ages. They are very often just waiting for their train and because of that very open to answering some questions in exchange for us buying them a cup of coffee.
  • When we have interviewed about 3-5 persons representing different personas we usually have enough data to go back to the drawing board. Did our assumptions hold true or do we need to focus on something else? Of course we can’t blindly go by what the test subjects were saying but it is usually a good indication.

We can usually go through this cycle in a day and that gives us really fast feedback loops and we avoid investing too much time and money in developing something just because someone high up in the hierarchy decided it was a good idea.

This approach has helped us a lot and perhaps it is something that can help you as well if it fits your context. Please post a comment below if you found this post helpful or if you have tried it yourself and have some insights or experiences to share.

coffee

Avoiding the meeting menace for your development team

Have you ever heard members of a development team complain about too many meetings? And when you look in their calendar all you find is a couple of meetings spread out through the week. As a Manager, Scrum Master, Product Owner etc. you might have thought “That’s nothing – I have meetings a day long!”. This is a natural reaction but the point you are missing is that the nature of your work is radically different compared to that of the development team. While a lot of your work is done in meetings and your days are fragmented the teams work doesn’t work that way. Paul Graham describes it very well in his post from 2009 about the Maker’s Schedule and the Manager’s Schedule (I really recommend reading the whole post). He describes that a developers day may be blown to pieces if meetings are scheduled in a way that prevents them from getting some flow in their work. To remedy this I recommend talking about this within your team and adding it to your Teams Working Agreement (because you have one of those, right?).

closed

Examples of how this could look in practice:

  • Do like Facebook and have a meeting free day per week. During that day the team can completely focus on the work at hand without interruptions.
  • Have something similar to visiting or opening hours for the team. During these hours it is ok to schedule meetings. When you choose these hours I recommend considering having your prime working hours (high energy) as your non-meeting time. On the Working Agreement this could be formulated something like:
    • “We are all in the office at least between 9 am and 4 pm. Meetings are scheduled after 2 pm.”
    • Or “We do meetings after 2 pm. All meetings have a clear agenda and purpose. We are on time.”

I really recommend trying this out. And who knows, maybe you as a non developer find value in getting some uninterrupted thinking time as well.

Ps. You should of course still talk to people if you need help getting unblocked or help someone else get unblocked. “People and interactions over processes and tools” is still what we strive for. This is merely a tool to help getting you meetings under control if that is a problem for your team. Ds.

Staying safe? Impressions after attending a SAFe training

I just attended the SAFe training “Scaled Agilist”. In this post I’ll describe my first impressions. To start off I need to say that I was skeptical about SAFe before taking the training. I wasn’t very impressed about what I had read about it on blogs/twitter and hearing about it in short presentations. But I wanted to learn more about it as I think it is something we will need to get used to in the agile community. I wanted to give it a shot – perhaps it was something in there that was really useful that I just hadn’t seen.

Positives

I’ll start with the positives about the training.

  • It went through a lot of nice basics with flow theory, how to treat knowledge work, lean, queue theory, feedback, decentralized decision making, agile values, early value delivery, WSJF etc. To me this was all good but also a clear way to build ethos. “Yea, we are pals with all these cool agile kids.”
  • It goes through a lot of things considered “best practises” in the agile world like:
    • Using Kanban to handle the portfolio level.
    • It talks about sound code quality practices (XP) in the teams.
    • How to manage the balance between business driven work and architectural driven work (on an epic level).
    • Replacing projects with continuous work.
  • The “Hardening Sprints” have been replaced by a “Innovation and Planning Sprint”. I really disliked the old concept of reserving two weeks for integration and bug fixing. To me that just seemed very waterfall. Now there is that but also room for innovation, hackathons etc.

Alright, so those were the good parts but to be honest, didn’t we already know about all of that? It is not like SAFe came with anything new – it just re-packaged what we already knew. I guess that the value SAFe adds is that it is now a model that can be “sold” to management… well, since it’s a model.

Negatives

To the negatives. Since many others have already bashed SAFe (see the first slides in this presentation) I’ll just stick to some particular things to the training I attended. (A disclaimer is that this was the first time this trainer taught this class so all things might not be according to what others are saying.)

  • It feels very much like RUP with a lot of stuff (artifacts and processes). Some might bring value to your context but others won’t. I see a big risk of people searching for a quick fix or a silver bullet will want to “install” SAFe into their organizations as is. Without understanding why they do it or how they should take it further.
  • In the two day release planning session you lock down in detail what everyone is going to work on over the next ten weeks. Whatever happened to “responding to change over following a plan”?
  • The release planing sessions sounds like it could have been useful to someone in some context. But is it useful to all? I don’t think so. To me it sounds like something you could blog about, for others to draw inspiration from and tweak to their context.
  • So, grouping up a bunch of teams and looking a dependencies is generally a good idea. But instead of trying to break those dependencies to create autonomous teams the direction SAFe is taking is to accept the dependencies and spend a lot of time working around or managing them.

At the end of the course I asked the trainer what companies would really benefit from using SAFe. It was an honest question since I really couldn’t see it. The answers sort of made me fall off my chair. According to him it needed to be really big multinational corporations. In Sweden (this is where I took the training), he said, we only have one of those and it is Ericsson… So why on earth would you then sell this training/model in Sweden to people who are not working at Ericsson? Is this just a new moneymaking machine for trainers to sell certifications? In this case I guess the answer is yes. Since the trainer was also selling his own model for scaling in mid-size corporations I would like to get a second opinion on that statement. Also, if you are already delivering value more frequently and are actively working towards having autonomous teams SAFe (according to the trainer) isn’t for you. Your organization should be pretty messy and would benefit from a hard reset.

So a conclusion is that if you like me is living in Sweden and not working at Ericsson – spend your money elsewhere.

Wrap up

To wrap up I’d like to quote Don Reinertsen in his foreword to Dean Leffingwells Agile Software Requirements (that describes sort of a first version of SAFe).

//…// I suggest paying attention to several things. First, try to understand the reasons why certain of these approaches work, not just what they are. If you understand why things work then you can more easily adopt them to your own unique context. Second, treat these ideas as a portfolio of useful patterns rather than a rigid set of practices that must be adopted as a group. //…//

Unfortunately these wise words are all lost in SAFe. It is taught as a “do all or it will fail”-process. Very similar to the way Scrum is taught in many places. But we all know that you shouldn’t do only Scrum by the book – it is  a starting point. And that is what use I see for SAFe – a starting point if you have a really big messed up organization it could serve as a replacement and a starting point when replacing your process. If you don’t have that – consider it a patterns book. And very much like when you use a design pattern when coding, make sure that you understand what problem you are trying solve and also understand the thinking behind the pattern you are thinking about applying.

Aside

Sharing is caring

Back from a week of training I have decided to start sharing some of the work that I do. So on this blog I’m going to post things related to my work. Mainly this will be related to agile and lean software development, teamwork and leadership.

I have already written some posts that I have backdated to avoid an empty blog.

Some posts that are in the pipeline already:

  • How to work with continuous improvements without doing retrospectives.
  • Building a network of competence groups – by the members for the members.
  • Time for a new manager – let the team choose.
  • Cookbook for initiating a new team.

Stay tuned!

Team (Squad) Health Check

Last year I was helping out at Spotify as an Agile Coach. One thing we developed/introduced when I was there was a new way of measuring how well the teams (or squads as they call them) are doing from a range of different perspectives. The coaches at Spotify have now blogged about this formats so I thought I would mention it here as well.

I can really recommend it as a tool to use in retrospectives. It lifts the discussions to cover important areas that might otherwise not be discussed. In my experience doing it on a quarterly basis works quite well.

The full blogpost can be found on Spotify Labs.

One thing they forgot to mention in the post that we initially had an “What card did we forget”-card. This was to discover important areas that we as coaches had forgotten. If someone were to adopt this tool to their context I would really recommend having that card.

squad-health-check-awesome-cards

Video

How we ditched the backlog to do the right things

On Friday me and a coach colleague talked at the Agile Sweden conference about how we use Impact Mapping and inspiration from Lean Startup and Lean UX to produce better products and to create a more creative working environment.

The talk is in Swedish and can be found here: https://agilasverige.solidtango.com/video/2014-06-05-agila-sverige-loke-06-lisa-sallvin.

Go and see bingo

A few Agile Coaches and me at a customer discussed that some managers rarely had the time to spend time with their teams. To remedy this we gamified visiting stand-ups. We called it “go and see bingo”. We starting by creating a map where you can see the location and times of all teams stand-ups. Then we added a bingo-field where the teams are listed from left to right and the managers from top to bottom. Each team was then given a set of stickers that they awarded managers who visited their stand-up. This sticker was then put on the bingo-field in the corresponding box. The first manager to fill their row won eternal fame and glory.

This initiative was well received by the managers and we could immediately see a shift in behavior from their part. The challenge will now be to make the behavior stick and not just be about the competition.

IMG_4745