Cyrille Deruel
Transcript (Translated)
I'm not going to talk about Kata, I'm not going to talk about Lego. And in this session, we're not going to build a paper airplane. I'm sorry. Let me introduce myself, my name is Cyril Deruel, I am a Delivery Manager at Octo Technologies. I am a Lean practitioner and the creator of Improve Your Board. This session will be about presenting 12 months of board analysis results that we have received. Octo Technologies is a consulting firm. We have a Y like Poult.
We believe that IT transforms our societies. We know that remarkable achievements are the result of sharing knowledge and the pleasure of working together. And we are constantly seeking a better way of doing things.
My goal at the end of this session is to rediscover board practices, or discover them,
to address and analyze three pain points on a board, on a real project, and analyze the three boards we have received. And behind that, to introduce you to a poor board. Before that, I wanted to start with three small warnings. We are going to talk about best practices. The first one we observed, so a best practice, is a practice we observed on a project that truly addressed a pain point.
We are going to talk about projects, about project implementation, and what I ask of you is to accept that a project is unique, it has a specific team and a particular context. So each project team, you won't actually be able to take what I'm going to present and implement it automatically on Monday morning. I really ask you to analyze the context of your project. And behind that, the situations and characters in this story being purely fictional, any resemblance to existing or past persons or situations can only be coincidental. All the boards I am showing you here, I was asked to keep them anonymous, so the people who sent them to me will recognize themselves. But we won't mention any client or project.
Let's start with the story of Improve Your Board. It started a year ago with a client who called me and said, 'Cyril, there's something wrong with the project, you need to take a look at my devs.' It's not taking off, I don't understand.' I said, 'Okay, send me a photo of your board, maybe I'll understand what's going on.' He sent me the photo and I said, 'Well, at first glance, I'm disappointed because I don't see anything.' I said, 'Well, since you have a problem,' Buy me a coffee and I want to see what your problem actually is.' And I arrived.
And in fact, the problem exploded in my face. We have our two attested and completed columns, which are packed with post-its. And then we thought, I think that just with a photo of a board, but a complete real photo, we should be able to analyze the status of a project, potentially identify pain points,
and potentially propose solutions.
The goal of Improve Your Board is to share best board practices that we have observed and to have a toolbox to address pain points.
After 12 months of boards, we launched a call for board submissions on the Octo blog in June. And the two observations, so we have a positive observation which is that overall the boards we received are clean. That doesn't mean all French boards are clean. It means that the people who dared to send us boards are confident about their boards. I have no idea about the others.
The boards we received range from specifications to production overall. The boards we received are not limited to three columns. We go beyond three or four columns.
Besides that, we had other surprises.
Very few definitions of done.
The definition of done, which allows you to list everything you are allowed to do, everything you had to do to move a task from one column to another.
Few or very few work-in-progress limits. In this example, you can see that the test column is starting to accumulate.
And the third point that surprised us a bit is very few swimlanes. Overall, we received only one board with three swimlanes, with swimlanes. So swimlanes are what will create a separation between the different types of activities, complexity of your project. What I suggest is to look at a first pain point, what you see on the board and what you would have done from a typical perspective. The first pain point is called when you have your head down.
A bit of context, imagine that your project started 6 months ago, you have a team of 7-8 developers, and the machine is starting to speed up. It starts to accelerate, it wants to go faster and faster, there are constraints on all sides, we start to accumulate debt.
And everyone starts to focus on the goal, which is to deliver the application.
When we look at the board, we see a standard board that goes from backlog, specification, development, test, pre-production, and done. And the pain point is that your developer, due to this acceleration, this... speed, forgets the basics of team building which are to share information, share functional and technical information, do code reviews, and exchange together. So you start to have your developers who are each focusing on their own functional module. Oh no, I can't talk about this part. It wasn't me who developed it, I didn't review it. Ask Jean-Michel instead, I think he has more information. What we found is that this pain point could be resolved by modifying your process, which is modeled through your board, by adding a review column. The review column is very simple.
A single step, it's to explain, the developer who developed the module will present his code to another colleague, like a demonstration, but just one-on-one,
from a functional and technical point of view. So you start to return to information sharing, and you start to return to a notion of sharing, whether on the technical or functional aspect.
What we liked about this technique is that behind it, we had six effects that followed.
We saw a diffusion of technical and functional skills among all team members. So everyone started to catch up, to make up for their delay on the project. We had a reduction in the number of bugs through a very simple phenomenon, which is that before delivering to the environment, it had been tested a second time. And then we realized that we had a whole series of malfunctions that had been analyzed by other developers.
The emergence of standards, meaning we start to present code, and there you have two experts exchanging and starting to talk, raising the level of discussion, and discussing a concrete case.
Behind all these discussions, these exchanges, if the problem occurred with one developer and another developer, it's possible that the other 5 devs on the team may not be aware of the problem. So these exchanges helped to feed the practice committee, the COTEC, with the list of all the things we saw that should no longer exist and that we will share together. And the last point, there was a strong reinforcement of team spirit where each person on the team realized that by presenting the application to someone else, they learned something and also taught something to their colleague.
A second example of a pain point, managing bugs.
I'm going to take a little break. The bug is here.
With the left and right arrows. Despite all the processes we see, despite all the techniques we implement on projects, there always comes a time when you have to validate the functionality. Your business analyst comes and tells you, 'I just tested the three features you just delivered to me.' And unfortunately, there's a bug in feature B. On this project, what happened is that they have a norm which is that as soon as there's a bug on a feature, they add a small yellow post-it to indicate there's a bug. The pain point isn't there. The pain point is, okay, I'm a business analyst, I reported a bug on feature B, bug number 14. The question is, how do I know that this bug has been fixed by the developer?
Features A and C disappeared because they were validated. And then we end up with the business analyst who comes by every morning, every hour, every five minutes. He has his seven developers in front of him. He says, 'Is it done, is it coded, is it not coded?'
And we realize that if the dev team and the business analysts haven't communicated, haven't found a way to communicate, they are lost. The BA thinks, 'I'm waiting, as the person who reported the bug, I'm waiting for someone to come and tell me it's fixed.' The devs say, 'But yes, I told you earlier, but you didn't see it.' They looked for each other and in the end, they found a tip, but be careful, it's very, very high level. The tip is to simply tilt the post-it. Which gives us two statuses.
Either our bug is fixed, has been fixed, and the bug is horizontal, and the business analyst says, 'I'm not moving, I know it's on your side, I trust you, and I know you're handling it.' And on the other side, the devs said, 'Here you go, we fixed your bug, okay, but in the meantime, can you validate the fix for us?' And actually, we just tilted it. What's interesting, just this practice which is quite simple, is that there's no longer any waiting on the business analyst side or the developer side, no more follow-ups, and we regain a fluid system between these two teams. But behind this, what we also noticed is that the mini-post-its with the bug history were archived on A4 sheets. After that, they were grouped by category and classified. And then, we started to see frequent errors, spelling mistakes, alignment issues, UI problems, and problems with very specific datasets. This allowed the team to feed into their retrospectives and say, 'Now, we need to reduce bugs related to spelling mistakes, UI bugs, or Mr. Dupont's bank account—every time Business Analysis uses it, they find a bug. Why don't we use it on our side?' Mr. Dupont, every time we use it, Business Analysis uses it, and every time they find a bug. Why wouldn't we use it on our side? This dimension really allowed us to feed data into all project retrospectives, to ask real questions by saying how we're going to improve the quality level of our project.
Third pain point, another problem between business analysts and developers, two different categories.
The Business Analyst released their three features A, B, and C. They see them progressing and think it's perfect. A and B are in development, everything is fine. They check back a little later and see that A is developed, it's about to be tested, so they'll receive it soon.
They check back the next day and see that B was overtaken by A, and C moved ahead. I really feel like my feature isn't progressing.
Did they forget about it? Here, we're only talking about three post-its. I'll show you in less than 10 seconds. You take the same setup with a team of 7-8 devs. You add about ten post-its before and after. You're completely lost. The business analyst's question is, 'Excuse me, but my feature B—are you thinking about it? Because it's been stuck on the board for at least two months.' As soon as you're worried, you always tend to exaggerate things.
And the devs say, 'We took your feature this morning. I don't see what the issue is; we don't see the problem.' One of the first reflexes was to say, 'Okay, from now on, what we'll do is add the date on the post-its.' And the date on the post-its—first, it's a hassle. Second, when you start having a wall of post-its, really full of features, going to identify the date on each post-it and subtracting from today's date is just a pain.
And the thing we saw is something very simple—it's called chickenpox. It was nicknamed chickenpox. Every day that passes, you add a red dot on your post-it, on the columns you identify as pain points, where there's a loss of trust between your business analyst and your development team.
Here, what we see is that feature C moved in two days. So, in the morning, before or after the stand-up, you choose a standard and say, 'Now, someone will put big red dots on each post-it in the 'in development' column.' And very easily, you see that feature B has actually been stuck in your 'in development' column for 15 days and isn't moving, and it will likely need attention because at this rate, it could stay there for another 15 days. The thing is, each day that passes, you add a red dot to your sticky note, on the columns you identify as pain points, where there is a loss of trust between your business analyst and your development team.
What we see here is that feature C was completed in two days. So, in the morning, before or after the stand-up, you choose a standard and say, okay, now someone will put big red dots on each sticky note in the current development column. And very easily, you see that feature B has actually been stuck in your current development column for 15 days, isn’t moving forward, and will likely need attention because at this rate, it could potentially stay there for another 15 days.
With chickenpox over time, what we observed is that you only catch it once per column. From the moment you have a trust issue between the business analysts regarding the ongoing development part, You implement chickenpox, and it will last 3-4 weeks. After 3 or 4 weeks, you have aggregated enough data to restore a sense of trust and for trust to return between the business analyst and the development team.
What we saw is that it only works once per column. But what we also noticed is that business analysts were also criticized for taking too long to recertify features. So, we can apply chickenpox to the current testing column. This feature, I’ve been waiting for it to be validated for three days, three months. So, you have several phases; you can implement it. The idea is to simply succeed in creating a measurement model that allows us to visually observe what is happening to us, what is happening on our board over time. And afterward, as soon as trust is restored, you move on to something else, and this problem will disappear.
We launched the project at the beginning of the year, with a board recovery at the end of 2012. What we observed is that the 15 practices we identified on boards,
The column to revisit. But we also have other simple things like the color of sticky notes, related notebooks, everything related to bug management. In fact, we have one thing in common: these are only simple practices. That is to say, rotating a sticky note a quarter turn remains something very simple. We encountered other practices with clients where they rotated the sticky note an eighth of a turn to say, okay, I’ll talk about this feature at the next stand-up.
Making checklists remains something simple. A good practice on a board will always be something simple that you will learn right away.
What I propose now is that, since you’ve seen 2-3 tips on where we’re going with receiving a photo of a board, we go through 3 boards together and identify the 3 strengths and 3 areas for improvement of a board.
First board.
Does anyone want to start?
Well, you don’t see anything.
You don’t see much; it’s done on purpose. It’s done on purpose for two reasons. The idea is not to go into detail but to get a broad overview of your board.
The first thing we liked about this board is that you see the developers' names grouped under spec, dev, and test. The developers' names are identified in the current development column, which means each developer communicates to their colleagues where they are and implicitly limits their WIP to a maximum of two tasks per developer. So, you don’t have a WIP that varies based on the number of people. With vacations, you’re forced to modify all your calculations. You know you have 4 developers working on this project. You know each developer is allowed to work on a maximum of 2 tasks. Beyond 2 tasks, you have a problem in your process.
The second thing we liked about this board is the DODs. There is an end to the DODs, so you simply see the DODs, which will be the checklist of everything that needs to be done to move from one state to another. And in the testing column, here, they left us a question mark. Just to ask, should we analyze and look at the question mark? They had a doubt; they didn’t know which DOD to put but knew they had to put a DOD in this column. And they told us, we’ll put the sticky note, and we’ll see what to put there. But at least they acknowledged that they didn’t really know what needed to be done at that point.
One of the pain points on this board is in the testing column, and this is a case we’ve seen very frequently: the number of sticky notes in the testing phase is just impressive. Here, if you don’t find about ten bugs, it means either you haven’t tested, or you have an exceptional quality level, or you have a code analysis tool that is present and prevents any technical debt.
Second concern.
Not verified, so we’re just going by feelings based on what we can observe in the photo: the number of user stories in specification. And so, you’re generating a huge backlog. And what you see is that you generally have a bottleneck at the development level. Upstream, you’re ready to strongly feed the development team, so you’re sure they won’t run out of work, at least for a few weeks. However, downstream of the flow, we clearly see a lack in the development team.
The good news is in the last production column. We were surprised to see that the sticky notes are organized by color. So, we imagined that the colors correspond to functional modules. So, specific points of the application. It enters your development process. They are jumbled in all directions. That is to say, the one who finds a color code in the testing column or the previous columns is very skilled. But at the end of your entire process, you find something sorted by green, yellow, and pink colors.
Second board.
A funny board because we didn’t understand why there was a pillar in the middle. The pillar was there before the project started; they kept it. On the right, development. On the left, specifications. It’s random.
Let’s start with the good news on the development side.
They have a WIP per slot. Instead of putting a number, they decided to create slots the size of their sticky notes to say, okay, you can’t exceed 4 tasks in progress in the development phase.
And they replicate this in the next column, the code review column, where they are also forbidden to exceed 5. It was 5 before; I no longer counted. We also liked the calendar at the bottom, which allowed the entire team to be aware of all major delivery dates, not to miss an iteration week, knowing it’s not this week we have a demo, not last week. What we also noticed is that they communicated through this calendar about vacation dates. In fact, just by looking at the calendar, you could know who was present in any given week. You could know the major dates: steering committees, major demos, and major production phases of your project.
And at the bottom right, I admit we zoomed in a bit, there’s a red bin, so a small part of a red bin. which had...
Same thing, it’s wiped with slots, so you’re not allowed to have more than 3 items in progress in the red bin.
Which is actually the basis for continuous improvement in this project. An interesting point: we have dots at the top, and we find them again. And now, we have reflexes that make dots and WIP limits standard and non-negotiable when setting up a board.
A point to review: on the entire specification side, we still have, as before, a backlog. We clearly see that we’re in a mode where we’re starting to push, we’re more in a push flow than a pull flow, where even if we felt we should be at the start of an iteration,
we find ourselves here with about twenty sticky notes ready to be developed. And here, about ten sticky notes that will soon be ready. And behind, more series of sticky notes that will be ready soon. And we imagine that even further upstream, they’ve already planned for several weeks and are already prepared to go very far.
Third board.
And last, this one, quite complicated.
Complicated in the sense that there wasn’t much to criticize. You have data, but you will go further, in that you have DODs and a template for writing your definitions of DODs.
And you don’t miss anything.
You have at the top left
a legend for the color of the sticky notes. And by zooming in, what we see is that the blue sticky note is for debt management. So, at a glance, you can see that there are 5 sticky notes for debt and improving the debt reduction of your application. You have a swimlane, and the swimlane represents a type of application. So now, we're going to be on the mobile part. Here, we're looking at another type. And they used colors to realize, to represent the different swimlanes and the different activities on the project. We didn't find any negative points on this board. We could have dug deeper to try to raise the level.
We have other interesting facts. The thing is, you have an implicit WIP.
If we go back to the activity on mobile, you have 4 mobile lines. So you're not allowed to have more than 4 sticky notes at the same time. And your process, mathematically and in relation to the size of the boxes that were made, ensures that you control what will enter your development process.
What we learned from Improve Your Board is that the more boards we see, the more we learn. We even asked for explanations about... I told you earlier about the sticky note that was rotated an eighth of a turn; we didn't understand why it was rotated, and they explained it to us. So we really engaged in an exchange between the people who sent us their board and us, the analyses we had done, and our knowledge base. As I was telling you, we're used to having practices. So there are four of them on which we are generally... We'll tell you that it's not okay, that you'll need to implement them. Everything related to the Definition of Done. So all the people who responded to us said, no, it's fine, the Definition of Done is implicit; everyone knows it. But when you dig a little deeper, you realize that the whole logic of continuous improvement, it's not there. We're sitting on it and assuming it will improve on its own.
The color and content of the sticky notes. On this, you can immediately see on 2-3 milestones that the color of the sticky notes will matter. Either it's different layers of iPhone applications, Backoffice, or others, but it can be functional modules, and it allows you to have a good vision of your project. And the swimlanes that will be linked to the color of the sticky notes or at least the bug-fixing swimlane.
Behind this, we managed to associate a whole series of pains with good practices. For a pain presented to a team, we are able to trace back to the good practice that helped eliminate this pain on projects. We don't commit to being doctors who will fix all the pains of all boards. But when we've already encountered a pain, we have at least one practice that has proven effective in the context of a project. Sometimes, it may need to be adapted. We managed to... disseminate our practices internally, and what makes us happy is that the practices we shared with the people who sent us their board, they applied them and sent us back a board. So we saw an evolution, we saw some changes, mainly regarding the DOD, DOD, and Swimlanes on what I just presented above. And if you want to try, the blog article is still available on Improve Your Board on Octo's blog.
Four minutes left in the timing. My challenge was to help you discover or rediscover board practices. I think we all agree. The one who doesn't agree should raise their hand.
We addressed three project pains and analyzed three boards together.
And I would have introduced you to Improve Your Board.
Do you have any questions before running to the other sessions?
Thank you.