More on this book
Kindle Notes & Highlights
Read between
January 9 - January 13, 2019
make all the important information visible in one place and then decide what to do together.
The longer we wait between releases, the more bugs and incorrect assumptions we will embed in the code.
Finally, at precisely 10 a.m., the project sync meeting takes place in front of the project board. The people at this meeting are informally referred to as the cross-team (or tvärgrupp in Swedish)—a cross-section of the whole project. In our case, that equates to one person from each specialty and one person from each feature team, plus a few other folks such as the project manager, configuration manager, and myself. The project sync meeting is where we look at the big picture, focusing on the flow of functionality from analysis to production: Which team is doing what today? What is blocking
...more
Instead of setting up policy rules for this, the teams simply talk about
this during the daily meetings and make decisions on-the-fly based on the current situation. This is the key to staying agile in a big project and not getting bogged down in bureaucracy.
The epic card sooner or later gets pulled into the second column (analysis ongoing), where it gets analyzed and split into user stories at a feature level. These are written down on feature cards in the third column.
When an epic has been analyzed (that is, broken into features), the epic card is thrown away and replaced by a handful of more detailed feature cards in the third column.
Demo and system test is done in a continuous fashion, as features get done.
Demo and reviews are done continuously now, but we’re considering doing a high-level product demo/review every second week.
The speed of a project is largely determined by how well everyone understands what’s going on. If everyone knows where we are right now and where we’re going, it’s much easier for everyone to move in the same direction.
Our high-level project goal is usually posted right on the Kanban board.
if people don’t understand the goal or don’t believe the goal is achievable, they will unconsciously disassociate themselves from the business goal and focus on personal goals such as “have fun coding” or “just get my part of the work done and go home.”
If you do cause-effect analysis on your bugs, you’ll find that bugs aren’t really a problem; they are a symptom. Bugs in your product are a symptom of bugs in your process.
Our process was discovered rather than designed. The first thing I did was put in place a process improvement engine. Well, I didn’t use those words, but that is in effect what it was. The basic formula is as follows: Clarity: Have physical boards in prominent locations that show everyone what is going on. And have a clear goal for the delivery that everyone can understand. Communication: Do process improvement workshops on a regular basis (weekly or biweekly), both locally within each team and at the cross-team level. Data: Track some simple metrics that show us whether our process is
...more
The strategy is pretty simple: it’s based on the assumption that people inherently want to succeed with their projects and that people inherently like to solve problems and improve their way of working. So, create an environment that enables and encourages these behaviors. If everyone knows where we are going and where we are right now and if we have the right communication forums in place, then chances are people will self-organize to move in the right direction and continuously figure out ways of getting there faster.
Noticing and celebrating improvement is important to fuel further improvement.
Complex product development of this sort is a creative process done by creative people, and the most important currency is motivation. In this context, gut feel beats hard metrics. If something feels like an important problem, it most likely is an important problem, whether or not we have metrics to prove it. And the nice thing about gut feel is that it often is a leading indicator of a problem that’s about to occur, while hard metrics often show a problem only after it has occurred.
The breakout discussions usually result in several concrete proposals, or options, which I list on the whiteboard. The default option is always the status quo (“Don’t change anything”), a reminder of what will happen if we don’t agree on any other option by the end of this meeting.
By aiming for 100 percent consensus for each change (that is, 100 percent of the people present at the workshop), we dramatically reduce the risk of resistance and thereby dramatically increase the likelihood that the change will work. So, the few extra minutes spent on consensus building pays off in a big way.
Remember that the stated purpose of the meeting is to clarify and improve our way of working. Sometimes we don’t change anything; instead, we just clarify our current process—that is, resolve some source of confusion and
provide a clear description that everyone at the meeting can relay to their teams.
The process improvement proposal template forces you to think about why you want to make this change. “What problem are you trying to solve?” “Who is affected by this change?” “What steps are involved in executing this change?”
if the smaller features aren’t each independently valuable to the customer, then a title should be written at the top of the card in bold blue text, showing that several smaller features fit together into a bigger feature. This helps keep these features together from a release perspective.
By clearly visualizing buffers on the board, we are more likely to keep asking ourselves whether we really need all these buffers and what we can do to reduce them.
That’s why we don’t include tech stories in the WIP limit, because we want to encourage team members to work on tech stories when the WIP limit is full.
Another way to do this is reserve capacity via work type limits on the kanban.
WIP limits sometimes constrain people to do something different from what they would normally do (for example, help test instead of developing a new feature). In that situation, the prioritized what-do-I-do-today guide on the board is useful.
It turned out that size wasn’t the main factor influencing cycle time; other factors such as focus and access to key people were more important.
The goal is to have a low enough WIP limit to keep people collaborating and to expose problems—but not low enough to expose all problems at once (which just causes frustration and unstable flow).
A great process isn’t designed; it is evolved. So, the important thing isn’t your process; the important thing is your process for improving your process.
Whenever you’re trying to change something, ask yourself continuously, “What problem am I trying to solve? Is it real or hypothetical? Is there any other more important problem that I should focus on instead?” When in doubt, ask people! It is very easy to fall into the trap of focusing on irrelevant or imagined problems, especially as external coach on a part-time basis.
If people resist your great change proposal, you probably haven’t made the problem clear enough. Or you’re solving the wrong problem.
don’t even make the change proposal yourself. Instead, visualize the problem that you think you see, and engage the people
affected by the problem to propose solutions. People are much more likely to accept a change if it was their own idea!
The key to effective problem solving is first to make sure you understand the problem you are trying to solve—why it needs to be solved, how you’ll know when you’ve solved it, and what the root cause of it is.
Most problems in organizations are systemic. The “system” (your organization) has a glitch that needs to be fixed. Until you find the source of the glitch, most attempts to fix the problem will be futile or even counterproductive.
A problem is a problem only if it conflicts with your goal. So, start by defining your goal, and think about the consequences of this problem in terms of your goal.
