Note To Self Retrospective

post-it-notesWe have recently gotten a few new team members, and we started to get to a size where we felt it was no longer practical to be one team. So, we decided to split into two teams.

Because of this split it felt kind of strange to conduct a traditional retrospective as we could not commit to actions as a team. So, I decided to try out a different format which turned out to be one of the best retrospectives I have ever had.

Note to Self Retrospective

I got the idea from this post: http://www.funretrospectives.com/note-to-self/ which I modified slightly to be more fit to our purpose.

The basic idea is to have people reflect personally, and come up with something they personally want to change in the future.

Preparation

On the whiteboard I wrote some simple introduction text so everyone would know what this was all about.

Purpose: To improve yourself

Goal: To create one actionable item for yourself and experiment with a new behaviour, practice, attitude, or method in the coming two weeks.

Output: A Post-It note for your screen or laptop to remind you about this change.

Agenda

Introduction (5 minutes)
I simply showed everyone the into text and agenda for the sessions, and made sure everyone understood.

Reflection (15 minutes)
During this time people think and create their notes.

Discussion (15 minutes)
I made it clear that passing was totally acceptable during this phase so people could feel free to be as personal as they wanted. No one did. We discussed as a group what everyone decided to do.

Feedback (5 minutes)
A quick go around the table to see what people thought about this activity.

Conclusions

The Good

This was a fantastic retrospective! Primarily because people ended up going much deeper than I expected they would, and shared very openly with one another. Results are at the end of this post.

One team member commented that sharing them aloud was very good, because then you felt more committed to achieving it.

It was also super quick, 5 minutes to setup and ended up 30 minutes to execute.

The Bad

Not everyone’s takeaways were actionable. Maybe that’s OK, but I like actionable.

The Output:

People were so open they even said I could post the result here! I had them as a picture but the quality was bad, so I typed them. Some probably require more context to make sense, but I will post them without that.

”Keep Back
Don’t code alone
Don’t offer solutions directly
Wait until asked for help”

”Proactively deal with upcoming issues”

”Spend more time reading up on items and be more thorough.”

”More structure for retro output
Book time for debrief/admin work after each retro.
Document output.
Follow up.”

”Stop worrying about everything”

”Improve knowledge about (component name)
Get to know team members and their roles.
Get to know my own role in the team.
Get to know everyone’s name, role, and skills.”

”Less sarcasm.
More listening.
Better at (component name).”

”Self confidence over all.
Believe in myself and my work.”

”Be focused.
Don’t waste time.
Be more motivated.”

”Listen More”

Annonser

Keeping track of things

chaos-485493_1280

This is a post about how to manage yourself and being a better Scrum Master. In short, this means that you:

  • always keep an up-to-date, personal todo-list
  • follow up on that todo-list.

Read on, for the slightly longer version…

The other tasks

An appreciated quality in a Scrum Master (or project manager or really any responsible leader) is the ability to keep track of things that needs to be done, and make sure that they happen. Now, I am not talking about things that should go on the teams Kanban board, but rather other stuff for which the Scrum Master typically is responsible: talk to people in the project, discuss with stake holders outside the project, book meetings, arrange team activities, negotiate with resource owners, etc.

(It does not have to be the Scrum Master that performs these tasks, but with a team of developers, there is a non-negligble risk that nobody else is interested in doing this work.)

These tasks originates from a number of sources, but common for all of them is that somebody relies on you, as a Scrum Master, to see to it that they get done. If you do, chances are the work will run more smoothly, and it also comes with the personal benefit that people will see you as a responsible person. If you don’t… well, the really important stuff will be remembered anyway, but you just missed an opportunity to help the team with one of the things they really need you for.

Keeping track of it

One of the things that I practice, is to keep a notebook with me to every meeting. You should too. It should be a nice notebook that you feel comfortable carrying around. It is also important that you do not loose it, and just use whatever you have lying around on your desk (you will see why in a moment). And it should be with you always, even if it is just a stand-up meeting or a brief chat with a colleague. Writing stuff down helps your memory, so write at least a few lines every meeting. Now, things that you are responsible for, mark them clearly in the notebook with an arrow in the margin.

Back from the meeting, or at the very latest at the end of the day, transfer all your yet unresolved arrows from the notebook to your todo-list software. You could use any todo-list, but I tend to use Outlook, mostly because its always there and its also, automatically, on my phone. I can also flag emails directly – in Outlook or on the phone – and make them show up in the todo-list.

This transfer into the todo-list might not always be that simple, since there might be information in the notebook that needs to go with the todo item, or the todo item might need to be broken down into multiple tasks. But here’s the thing: it does not need to be perfect. As long as it is on the list, you can always go back and find the note – or the email, or the contact information, or the special circumstance surrounding the item – fairly easy.

notebook-258310_1280

Forgetting it

With your responsibility now on the list, and synced with your phone, you can now forget it. Don’t worry, chances are you won’t, now that you have written it down, but its okay if you do. And if you do, it is still there the next day you open Outlook or your todo-list on your phone.

Sorting it

The todo-list might need some attention, once a while, when you categorize the items, set end dates, or do whatever your todo-list software allows you to do. I have found that it helps to add information, such as phone numbers or due dates, directly to the title of the item – but really, I’m sure that you will find a way to suits your own needs.

But, and this is very important, remember to clean your list often, preferably at least once a week. Set aside time to do this, perhaps 15 minutes every Friday morning. Remove stuff that has already been done, or are no longer current. Prioritize the remaining items. If you do not, and keep adding stuff, you will soon stop using it because you just end up staring at stuff that are irrelevant.

Getting it done

Now, what do you do with your prioritized, cleaned todo list? Well, that is easy: you start from the top and work your way down.

But I can think of at least one other use for the list. Before going into a meeting – no matter what it is – scan your list of todo-items and see which ones are relevant to bring. Do you remember the notebook that comes with you into every meeting? Write the relevant items down into that notebook, and use that as a simple agenda.

Used right, the notebook-todo-list combo can function as a sort of collective memory for the team; put it into your notebook with an arrow, and that thing that you simply should not forget to bring up in the next meeting is there when you need it.

Reflecting on it

While your team mates are busy producing high quality software and are steadily moving things on your board into the ”done” column, the work you do as a Scrum Master is typically not that readily visible. Well, until you look at your own todo list, and unhide the amount of ”done” items. It is a good idea to now and then look at this list, just to get an idea of the amount of work you actually do – and it can be quite a lot, at least with a mature team that happily leaves managerial task to you.


I am sure there are other ways to keep track of things, but I have found that this combination of analogue and digital works excellent. It might be preferable to use a computer or a tablet instead of a notebook, but I have found that the notebook disturbs a meeting less than the alternatives. I have also tried personal Kanban boards, but I have found that I do not need the extra complexity – a list suits me fine.

What is your experience with todo lists from your work as a Scrum Master/project manager?

Agile Practices Retrospective

Our Retrospectives

We like to keep our retrospectives fresh. We find it helps to reveal things we might not otherwise have found if we alter the format frequently. With this goal in mind, we follow a simple system:

Once a month we use our ”normal” retro format. Everyone in the team is familiar with this, and we can perform them quite quickly, with minimal prep work and explanation required. Basically, effective with very little admin.

Once a month we have our ”experimental” retrospective. A little more set-up time required, but a good opportunity for experimentation and explorations.

This is the story of one such retrospective.

Agile Practices

Obviously you can perform many Agile practices, but not be Agile. However, there are a lot practices out there and sometimes teams can become focused solely on those that they are currently using, rather than looking at other tools they might bring to bear. This is where the Agile Practices Retrospective comes in.

Prep Work

image (1)In preparation for the retrospective, we created cards with various Agile practices as headlines, and a brief explanation of each listed on it. I also colour coded them under various categories so they could be more easily identified from afar. Then we simply taped all these cards to a wall in their respective categories. There were about 50 cards in all.

Special thanks to Jurgen Appelo for providing the initial list I worked from:
http://www.noop.nl/2009/04/the-big-list-of-agile-practices.html

Here is a link to a google doc with the prep work I have done, to save you some time:
https://tinyurl.com/l8loec6

Reducing the complexity

image (2)With over 50 cards, there was a lot of information. We split into groups and started categorising the cards under a new set of headings, it was made clear to all that they were not expected to read all the cards.

Headings:

  • Doing (Working Well): Things we are currently doing, and quite happy with they way they currently work.
  • Doing (Could be better): Things we are currently practising, but could use improvement.
  • Not doing (By choice): Things we are not currently practising, but have made a choice not to use in our context.
  • Not doing (Not tried): Things we are not doing, and have never really tried.
  • WTF!?!: We have no idea what this is, or what it means.

Deciding what to focus on

We obviously cannot talk about all these things. So, we used dot voting to decide what topics to focus on. Each team member was given 3 ”dots” for each of these types of vote:

  • We should start and or alter this practice in some way. (Indicated by a dot)
  • We would like to learn more about this practice. (Indicated by a +)

I also printed out simple list versions of the same information, as I knew it would be hard for everyone to gather around the board when deciding how to use their votes. Despite this, this was still not as successful as we would have hoped. Part of this is because we are actually two teams and our 3 customer representatives, so the whiteboard was too crowded. I feel this would go better with a single team.

Discussions and action points

We had open discussions and tried to create action points/experiments around the topics we had discussed. I will just give a very brief of what we arrived at:

Root Cause Analysis/ 5 Why’s

Discussion:
We even arrived at the fact that without formal tools, we are still quite good at root cause analysis. But perhaps a formal tool might revel something we would have otherwise been unaware of.

Experiments:
1)Focus on using our discussion time during retrospectives (Generate Insight) to use more formal tools like 5 why’s.
2) When events are added to our timeline at daily stand ups, then we should also consider doing a more in-depth analysis of those items.

Product Vision

Discussion:
We felt that we very likely do have a product vision, and even a fair amount of impact mapping done for that, but this is not communicated to the entire team at a frequent enough rate. Also, we need to get better at following up these things.

Experiments:
1)Make the product vision more concrete and communicate it at a regular interval.
2)Follow the vision and impact map up at a regular interval.

Behaviour Driven Development (BDD):

Discussion:
This is a discussion point we wanted to learn more about. So, the discussion was brief. We basically arrived at the fact that it was intriguing and we want to know more.

Experiments:
1)The two team members who know something on the subject will provide some links and a quick intro for everyone else.
2) Some of the team will experiment with these concepts in our ”Brain Day” next week.

Conclusions:

The Good:

This retrospective was reviewed well by the team, everyone generally liked it.

It was a fairly active retrospective, because of all the moving things around and working in teams, so the energy level remained high throughout.

Probably the best aspect of this retrospective was the addition of fresh concepts into the team, the idea to focus on things we wanted to learn more about was a good one. In the future we would probably recommend only focusing on these things.

The Bad:

There was a fair amount of prep work involved in this one, although I consider it worth the investment, it wasn’t free. Hopefully a bit cheaper for you, as we have provided the work we have done. Once again: https://tinyurl.com/l8loec6

It was too hard to get an overview with so many items, this may have been due to team size, and might have been possible to mitigate by having the team read the list before hand.

Despite there being so many items, the list was no even close to exhaustive, and it was hard to leave off some practices that really should have been included.

Visualising your backlog

Far too often the backlog is housed in a tool somewhere, often in purely text form, with no way of knowing at a glance the status of each item. This makes it difficult to manage in many ways, and generally hard to work with. I have found that taking the time to visualise your backlog will not only increase the quality of the output, but make it a lot easier and less time consuming to work with. This is an example from my current project of how that works.

Your backlog as a process:

backlogMost people don’t take the time to see their backlog as an actual flow, but it is. Items usually have a sort of process that they flow through to arrive in a state where they can actually be worked on, and being aware of what that flow is can help a lot in creating stability.

This ”refinement process” is, in my opinion, one of the easiest wins in most teams. Our team went from having 1-2 day Sprint Planning meetings, to usually getting through them in a just a few hours, with a much higher quality of output.

The backlog on its side:

The first step in creating a refinement process, is to visualise it. In the simplest sense this can be accomplished by simply turning the backlog on its side and seeing each section of the backlog as a column in your flow.

backlog_side

The tool we use for this is KanbanFlow. The images you see here are simplified slightly for the sake of clarity, they only show one teams flow, when in reality we have multiple teams working in this flow.

Below you see the complete flow, and we examine each section in turn.

flow_noinfo

The bottom:

bottomHere sit the totally unrefined items. Some of them may be too big to work on, most are too unclear, and all are only ”lightly prioritised”. We like to visualise the different flows in to the backlog separately. This makes it easier to balance priorities against one another when planning upcoming work.

  • Backlog
    • Full of large, unclear stories.
    • Many of these may never reach the top, we try to clean this out every so often and remove things we are certain will never be top priority.
    • Most of these items come from our Product Owners / Customers.
  • Teknik
    • Holds much of our technical debt.
    • These generally tend to be concise, but somewhat large.
    • These items primarily come from the teams working on the product.
  • Bug list
    • A list of bugs that were not quite important enough to be a priority right away.
    • We try to keep this list as small as possible, but some things do need to wait until they are worth the investment to fix.
    • These items usually come from users who find them in production.

The middle:

middleThis is where the bulk of planning and discussions happen. There is a column where action from the customer is needed, and one for when action is required on our side. Most of what takes place here comes down to regular discussions which bring up question that need to be answered before development can start. Very often, large stories are split into smaller items here, and some of the lesser priority things go back to the bottom of the backlog, and the prioritised items continue forward.

Items do not leave this area without a clear priority.

The top:

topThis consists of items that are ”Ready” to be worked on, and items on which work has begun. Many teams choose to have a formal definition of ready, our team keeps it fairly simple: ”Everyone in the team agrees these items can be worked on now”.

Items which are pulled into the Sprint column are being worked on by the team. At this point, these items are made into smaller and more specific tasks, and are visualised using the physical tool for the team. This is important, because it is the main points where details are obfuscated. Our customer does not need to know exactly what is being done on an item, what matters to them is that the feature or functionality is started, and when it has been completed. This setup allows them the appropriate amount of detail.

The output:

deployAt the moment we have a slightly heavy deployment process, which involves handovers to the customers organisation and wait times. Visualising this helps our customers to understand when things are ”done”, but they still don’t have them due to internal processes. This has aided in our customer driving many initiatives to simplify and streamline this process. While we still feel it could be improved further, it is definitely an easier process today than it was before we started visualising this part of the process.

Summary:

Being aware of how items flow in your backlog from the initial request to the actual delivery can help significantly in many ways:

  • Clear status of items in process for both you and your customer.
  • A shared understanding by all involved what is in the pipeline.
  • Easier planning session because everyone has more insight when items arrive.
  • Higher quality to items arriving at the ”ready for development” stage.

But be careful not to present unneeded information as it only serves to make the needed information harder to find.

And most importantly, the tools used in the process are much less important than the process itself. Having the discussions regularly and openly, creating the feedback loop as quickly as possible, are the keys to success not the tools being used to present the information.

This process can be tricky at first, but as with all things, the more often you do it the better you will get at it!

Massor av kolumner

1280px-Schema_Saeulenordnungen

Att visualisera backloggen och hur arbetet fortskrider är viktigt (läs också Jeffs post om detta här ovanför). Vi använde förut TFS, men i jakten efter någonting som var enklare att använda och visuellt mer slående, fastnade vi för ett annat verktyg: KanbanFlow.

Vi hade fram till dess haft tre stadier för en punkt i backloggen: ”Todo”, ”In progress”, ”Done”. Vid övergången till vårt nya verktyg, fullkomligt exploderade Teamet i kreativa förslag på hur visualiseringen borde ordnas för bästa överblick. Så här ser våra kolumner ut idag:

Namn Innehåll Prioriteras av
Backlog Utvecklingspunkter på längre sikt Produktägarna
Teknik Tekniska förbättringar, rensning av teknisk skuld Teamet
Buggar Mindre buggar eller ärenden Produktägarna och teamet gemensamt.
Produktägare – refinement Punkter där produktägaren behöver göra en insats för att arbetet ska komma framåt. Typiskt innebär detta en workshop, en utredning eller kunskap från tredje part.
Team – refinement Punkter där teamet behöver göra en insats för att arbetet ska komma framåt. Typiskt innebär detta diskussion, nedbrytning och tidsuppskattning. Alla eventuella frågetecken ska rätas ut innan punkten får flyttas.
Ready Punkter som är redo att implementeras. Produktägare och team, gemensamt.
Sprint Punkter som teamet åtagit sig att implementera under denna sprint.  Teamet
Väntar på test Punkter som är färdigimplementerade enligt vår definition-of-done.
Väntar på produktionssättning Punkter som är testade i produktionstestmiljön och väntar på driftsättning.
Färdigt. Punkter som är… tja, färdiga.

Man kan fråga sig hur prioritering sker mellan backlog, teknik och buggar-kolumnerna. Mer om det i en senare post.