Agile Processes: Making your team effective

Falk GrünewaldBy Falk Grünewald 1 Jahr ago
Home  /  Tech Corner  /  Agile Processes: Making your team effective

Agile Processes: Making your team effective!

When it comes to the organization and workflow that a team uses – especially in an agile environment – there are many important questions to which you won’t find the answer in a book! You won’t be able to look up the “Perfect Agile Workflow” and implement it. Or, at least, you should not expect it to go smoothly. Obviously there has to be an overall structure across the development teams in your company to ensure a stringent and transparent process – but when it comes down to the team, we like to follow our own rule, which is: “Whatever works best!”

Why the Orca broke out of the flux

At Visual Meta, our Scrum-Teams are named after animals, which is very supportive in terms of team bonding and identification. We are the Orcas! The Orcas are covering the extensive, basic areas of our company – i.e. data structure. Database, Caches and more. And like most teams at Visual Meta, we worked in a relatively standard Scrum cycle:

  • We were working in 2-Week Sprints with weekly Releases
  • We had a physical Scrum board on a whiteboard for the two weeks, in front of which we would do our Daily Stand-Up
  • We had a normal Planning Meeting at the start of each Sprint, where we would add tasks for the whole sprint
So, everything was functioning normally. But this process can, sometimes – and dependent on its implementation, also lead to conflicts that probably many Product Owners know:

  • What do I do if I have an urgent research ticket that will spawn another ticket which I want to work on directly?
  • What if something has been overlooked or additional information comes up during the Sprint or a ticket “explodes”, taking much more time than anticipated

In such cases, as mentioned above, you would probably go against at least some of the implemented processes of your company.

So what would you do?

Would you change the content of your sprint and mess with your Burn-Down? Would you under-commit because you wouldn’t have an idea what the research would bring up? Who would you have to inform?

The Orcas decided to take a step back and take a look at what we had:

  • An Epic with the highest priority
  • A lot of stories belonging to that Epic, easily 3-4 Sprints
  • The knowledge that there is a risk-factor of “unknown work” inside that Epic, too

That was all. So we asked ourselves: Do we need to plan for that 2-Week-Cycle? Could we use Kanban? Or could we even use the Sprint Cycles to structure our work?

It was time to find out “What works best”.

Agile Process by Learning & Doing – The Setup!

Here we are now, about two months later, and I (the Product Owner of the Orcas) proudly type this article while the team still works using the process that we created for ourselves.

So what is important to us?

Easily summarized:

  • What will we do today?
  • What is there left to do for the Epic?
  • How are we doing?
  • What changes or findings might have to be discussed?
As you can see in the picture, we have a complete “mission area” for our work: Epic Board

The first thing that we set up was an “Epic Board”. It contains all known stories of the currently processed Epic:

  1. This is the content of the current “Sprint” – we could not fully ignore this as it is used in the company, so we still commit to a certain amount of points and have them all visible
  2. This is the “Backlog” for the Epic. Heavy planners might even split that into upcoming sprints as well – but it always allows us to see the whole project at a glance!
  3. This is the Inbox. Upcoming problems, identification of previously “unknown” tasks – all will be added here and processed on a daily basis (see “Meeting Structure”)
  4. There is, as often, an “Others” area. When we for example know the team has to decide on some monitoring for the project, we can keep a reminder there.

Daily Board

In theory, probably not that different to the “Physical Sprint Board” many teams use. There is, however, one major difference: This board only contains tickets that will actually be worked on during the very same day!

  1. The main part is the lane of tickets currently being worked on, split into „To Do“, „In Progress“, „Code Review“ and „Done“
  2. The upper corner shows something that we call “Daily Goals” – I will explain these later
  3. We also have a “Daily Discussion”. Whenever a team member says “We should really discuss…” that is the place to write it!
  4. We have a “Hotfix Counter” – not so relevant for this article 🙂
  5. Same goes for the Chores.
So, we have a physical backlog for our main epic and a daily board. All clear? Well, we figured there are other areas that every team has to deal with somehow. What was our KPI again? Who is going to release this week? Didn’t we say something in the Retrospective? For that, we use a rather informal “Blue Board” (which is basically because it has always been there and finally could be put to use).

  1. This is where we can hang our “Burn-Up” (more later)
  2. Goals, for example connected KPI, other company goals – everything that affects our team
  3. Roles” – at Visual Meta we have “Bugmasters” and “Releasemasters”, a changing role per team of a developer that carries responsibilities for a smooth process
  4. Retro Actions” – because actions from the Retrospective should be taken seriously!
  5. Other Stuff – let’s be honest, this is like that one cupboard in your house where you throw everything that you don’t know where to put, but you can’t throw out either.
We sum all that up with a nice, clean (well….empty) Whiteboard: Now – I can be rather pedantic. Did someone really use the Epic Backlog Whiteboard and smear some scribbles on it? But scribbles and a quick visualization are very important. So, you need a space for that! It is mostly used by the developers, but when we start refining our next Epic while finishing the current one, it can also be handy:

How we changed the idea of meetings!

Here comes one of my favorite parts. Teams have many meetings. Teams walk to meeting rooms. Sometimes, people come late. The exchange between the team is a very crucial aspect. Yet, the usual “pre-scheduled” meetings were often rather disruptive to our workflow, especially when they are in meeting rooms outside of our work space where you cannot access everything you need easily. This is how the Orcas decided to meet in the new structure: At this point you might be thinking that it doesn’t actually seem so different now from standard Scrum, does it? But it is. Every Day, we have a “Daily Stand Up II”. In that meeting we mainly do two things:

    a) Check the “Inbox” on the Epic Board and discuss every upcoming task:

    • Is this task crucial for the current Epic?
    • In case it is, we refine and estimate it immediately – in case that is not possible, we might add a Daily Goal so it is the next day!
    • When estimated, we immediately discuss the priority: This ticket might be done right away.

This process allows us to react incredibly fast. Risks can be tackled directly, we always see the effect on our Epic. No weird “bug tickets” or additional things done on the side, we are fully transparent.

    b) Keeping the Epic in check
  • How are we doing (also using the Burn-Up, explained later)?
  • Is the priority in the Backlog still accurate? Did things change?

In this part, we even removed smaller features from the Epic, which we identified to not be crucial enough for the first phase. We always worked actively on a dynamic prioritization with the goal on the horizon!

And this has a vast effect on the Refinement and Planning Meetings, especially during an Epic. You see in the graph above, that on the days we have “Refinement” or “Planning” the “Daily II” disappears. This is because we simply use that slot and do it directly in the morning, as kind of an “advanced” Daily II.

Why is this cool?

Our Planning Meeting “inside” of a bigger Epic takes around 10 – 15 minutes, as the team is completely aware of the whole epic and its content. And we don’t have one “exceptional Refinement”, as we do this on a daily basis anyway. Needless to say, we do have these meetings in our office, right in the area I described. You might have seen the couch and the table in the first picture.

Refining an upcoming Epic?

You can do that, just announce it early to the team and you can use the “free” Whiteboard.

So, yes – we spend between 30 and 60 minutes a day in our morning discussion.

But for that, we got rid of interruptions by Planning, Refinement or other meetings and the amount of forgotten topics and issues have been reduced massively.

The team also massively increased their effectiveness – due to this workflow and the two remaining additions.

The daily Burn-Up: Graphs don’t lie

All you need here is all tickets for your epic (including estimation), a risk factor (how much work do you think is hidden, especially for complex or big epics) and an estimated delivery date. These facts allow you to create a “Burn-Up” which I even recommend to update daily: On the graph above you can see all reflections of the daily process.

  • What is the goal and the “ideal line”?
  • What is the Velocity the team has on average for this Epic?
  • What is the Velocity the team would have to have on average for this Epic?
  • What was the “Velocity” of the day – or simply, how many points were burned that day?
  • What is the actual progress and based on average velocity and remaining days?
  • What is the estimated progress? (The red dots mark actual progress, as from the last dot onwards it is an estimate)
Once set up, entering the daily values is quick and it helps. You directly see the effect when you add another story to the Epic or how the team is doing.

Risk Assessment and Buffer

However, the surprise can still be there when you only control work that you know about.

Yes, sure – an Epic should be clear and all tickets should exist before it even starts.

But let’s be honest, how often have you experienced that something either was not possible to estimate because another ticket needed to be done first or some research had to be completed – or simply nobody could foresee it?

The good thing is: You had that feeling before, didn’t you? You knew, working on that project has some risks.

Asses it!

For our last big project we knew that the complete infrastructure implementation could vary based on the work we did, there was a huge unknown.

What we did was to have a second burn-up (and our actual committed ETA): One with a buffer!

It would have been reckless to have given an ETA for only the known work – even in case we would have mentioned potential delays due to risks from the very beginning, it would not have been clear.

So, you decide a risk factor. This could be 10%, or even 30%.

Let’s say your team has an Epic with all stories worth 160 points. But at the end, they need to set something up which they cannot estimate yet. “Shouldn’t be big, but hard to tell”. Add 10% – 15 % risk factor! Make a Burn-Up which has the goal to burn 192 Points, not 160!

And all your additions and ideas when you start “exploiting” that risk will make the effect clearly visible.

Daily Goals – Micromanagement or Performance Boost?

A last word on this. Yes, we have a “Daily Board” with the tickets that the team should work on today. Isn’t that sufficient, why do we need “Daily Goals”?

What sounded like a potential burden and extra pressure on the team turned out to be loved by both the Product Owner and the Developers.

It gives:

  • Daily orientation on priorities
  • The right feel for getting things done
An example is that very often we kept tickets where we “just had to add tests” or it was “just missing a Code Review”. In fact, a story only knows “To Do”, “In Progress”, “Code Review” and “Done”. But the actual process is much more fine-grained.

Especially the code review can be forgotten, and, hey, it is practically done.

What could possibly go wrong? And then this Code Review explodes before the sprint ends and you face an issue. But with our approach the goals are discussed on a daily basis and not “given” from the top. You want to work on a ticket? So where do you want to be with that? Implemented? Coded the first part? Or simply identified all classes you need to change? It’s in your hands.

When we introduced this approach, I felt rather insecure. I asked myself: Could this work? Is it too much to basically have a look at the whole Epic every day? Will Daily Goals feel like assembly-line work and kill creativity and motivation? Is a daily burn-up an overkill?

We ended up with a team that loves it; the PO, the Developers, the Scrum Master. We also ended up with a team that works much more effectively. We have started to proudly present our ideas to other teams and we still aim to always improve our approach.

  Tech Corner
this post was shared 0 times
Falk Grünewald

 Falk Grünewald

  (1 articles)

Falk Grünewald joined Visual Meta in 2013. After working as a Product Owner in Frontend for some time, his technical affection led him to the Backend part of the platform, where today he acts as Product Owner for the "Orcas" and Team Leader for the Product Catalog Team.