Crisp's BlogPage 29

Here’s a new article for you: Cause-effect diagrams: a pragmatic way of doing root-cause analysis Cause-effect diagrams are a simple and pragmatic way of doing root cause analysis. I’ve been using these diagrams for years to help organizations understand and solve all kinds of problems – technical as well as organizational. The purpose of the

For those of you interested in Lean problem solving techniques, Tom Poppendieck and I have created an A3 problem solving example and template. Feel free to use as you please.

If you’ve read Michael Feathers’ book, Working Effectively with Legacy Code, you’ll know that he presents his techniques for refactoring clearly and simply. My favorite is his metaphor of finding the “seams” in the code to break it apart then “sew” it back together again. If you’ve attempted to implement some of these techniques in your own project you’ll also know that it’s not easy. It is slow arduous work, and when there are no unit tests it can be scary.

Crisp hosted Michael Feathers’ course:”TDD and Refactoring Techniques” this week in Stockholm. I hoped that some secret knowledge of how to refactor easily would be revealed, something that was just too elusive to express in a book. Instead my experience that refactoring is difficult was reaffirmed.

Continue reading

 I have been watching several discussions over the years between brilliant people where clear perception of the problem prevented them from solving it.  It is so easy to marry ourselves with our suggestions of action (how) that we loose focus about  what the nature of the problem really was.

For cases like this, I advice teams to follow this problem solving algorithm:

1. Surface problem
2. Concretize problem  – write it down!  (what, when, how, who)
3. Find root cause
4. Surface ideas  (start with those that helps improving the existing situation)

For seeing situations like this, I try to keep the following "aha" reminders in the back of my head..

As an arguing manager, if I can’t concertize the problem it is a sign I need step back and put the right decisions into the right hands – the people closest to the problem.

As an arguing engineer, have I progressed towards engineering a solution, or even evolved into solving another problem (which I felt needed to be sorted first), before concretizing it’s nature with my counter part?

If you’re interested in Kanban I can recommend this course in Stockholm, there are still a few spots left. If you don’t know what Kanban is you might take a look at: http://www.limitedwipsociety.org/resources/ … or my article Kanban vs Scrum or (if you only have a minute) my cartoon One day in Kanban Land. My

Take a look at this chart and tell us how we are doing?

Sometimes it is hard to stop a running meeting. You might have someone so fond of talking he doesn’t realize time is up. Or the daily stand up has gone haywire. How do you break in, politely?

Teach everyone the timeout sign.

  "hey, let me get back to code"  🙂

Your team is coding along, sprints are passing by, your somewhere around sprint 15.. life is ok..  ..or?

As a famous test leader once said:
"Team are happily completing sprints but nothing gets’s done"

Here are a couple of  things to look out for in your Scrum organization..

It is not uncommon I run into a team coding a system in desperate need of refactoring,  at the same with huge pressured to move things out of the door. When trying to refactor we face the bad news of doing nothing but refactoring..

So we need to be a bit more clever. He are two ways;

On September 24-25:th in Stockholm, there is a chance to learn Kanban directly from the source!

Kanban is framework to help improve efficiency and continuous learning, but with a very light weight footprint. It works both in- and outside software environments.  Support is one example.

Hosting the training is David Anderson, one of the most experienced practitioner in the field. So it is a great opportunity to learn from the source.

http://www.crisp.se/kanbanjedi

For those of you who wonder "why would anybody convert a Scrum team to Kanban" (see earlier blog) – it is important that you understand the true intent. (..yes there is one! 🙂    What expected output do you have from a process framework?

This important "why" question is often left out in the debate. The heated "Scrum vs Kanban" discussion is a good example. Try yourself  "why are you using Scrum"? (or Kanban). At what point would you throw the tool out for not delivering?

It is no wonder debates turns heated if we disagree on where we are heading. But if we instead start with clarifying intent ("why") – then the actual choice of tools becomes less important (more like a boring context summary 🙂

Why then? How do you know that the process tool works for you?

• First (obvious) – it helps you deliver running software.
• Second (less obvious) – it makes you do continuous improvement effectively

If you are getting results from continuous improvement – your tool is right. If it is not happening, it is probably wrong. (check yourself, what improvements have you benefited from lately?)

This was the main reason I chose to implement Kanban in the Scrum teams. It was not because the sprints where not delivering, it was because the improvements didn’t happen.

Check out Scrum Checklist version 2.0!

Here are the slides for my 90 minute session "Introduction to Scrum" at Agile 2009 in Chicago in a couple of weeks. The slide deck is mostly pictures and intended primarily for presentation use, not reading. So this stuff will probably make most sense if you attend the session.

I was recently invited to run for the board of directors of the Agile Alliance. After some initial hesitation I decided to go for it! The election will be held at the Agile 2009 conference on Tuesday, August 25 at 6:00 p.m. at the Hyatt Regency Hotel in Chicago. Voting can be done online as

Code quality. It has been haunting me for so long I forgot when I started to think about it. Do other people think about it? For sure. Do everyone? Certainly not.

I was doing RUP and before that some waterfall process from DoD. Before that I was programming Fortran. Now, what has been my single most important recommendation for reaching code quality?

Peer code review.

But enough. It just struck me how much I do not miss code reviews.

I’ll tell you why and I’ll tell you what is the replacement, because there should be one.

Here is a real world story about Steve Jobs:

(Excerpt from an interview with Ed Niehaus at Coopers Journal, full story here)

Two views:

• I’d love we had more product owners working like this! Not about making an ad campaign that has to be this or that, – it’s about making a great experience!
• How would we have experienced Steve in any other role? Probably like a egocentric lunatic complaining and whining  "not good enough" all the time. A "non team player". People like Steve are rare but when whining they simply express a need for role where they can outlive their excellence. Our job is to create an environment so that can happen.

On the Wicket user’s mailing list there was a question about modal windows and it set me off. Since my excellent wisdom 😉 is larger than just modal windows and Wicket, I thought that it would be of interest to all of you, dear readers.

I have discovered that the modal windows that was gone when web applications started to spread, are starting to come back. And they are bad, even if they are not as bad as the goto statement that was accused the same way as I just did: harmful.

A modal window is something that pops up in the face of the user, screaming its importance by not letting the user touch anything else until the modal window had its way.

At a customers site, teams have been using Scrum for year or more (even the sales people run it 🙂 Developers are talented and motivated. In one team, increased visibility was needed, so I helped them convert to Kanban.

A second team took noticed on what went on, copied the Kanban board and started using it on their own.
 
So before, their sprint burndowns looked like this:
(atleast for the last three sprints)

  Now this is a picture of the same team after two weeks of Kanban

Isn’t it a bit cool? 🙂

Here’s a really short and simple kanban intro: Translations: Brazilian Portuguese Chinese Czech French German Japanese Korean Turkish

Here are the slides from my keynote at Integrating Agile 2009, Amsterdam. First three slides are below, the rest are in the PDF document. Take-away points: Know your goal Agile is a tool, not a goal Tools don’t fail or succeed. People do. There is no such thing as a good or bad tool. Only

There are two patterns that I find linked:

• "I am constantly busy, I don’t have time to think!"
• "There are no new ideas. We just keep doing the same old thing."

It is important to understand how our brain does problem solving. It has an active part, thinking. Then there is a background process, solving in new angles.

Have you ever found a new idea pop up while you are in the shower, when dreaming or when walking to the coffee machine? That is your background process in work.  If you want do develop new cool stuff, or find smarter solutions to problems, you need to make room for that process.

Sometimes I work in projects where team uses sprints, but deliverables are compiled over multiple sprints. In these cases, I have found it handy to do simple Release / Project burndown tracking. It helps facilitate a discussion with client and project stakeholders.

So, here is a template I use. It has the feature of  "dropping" the baseline when additions to the projects are made, showing the net effect of things discovered along the road.

It can be used by a Kanban team, Scrum team, well – any team 🙂

Project and Release Burndown Template.xlxs
Project and Release Burndown Template.xls

I use this in my own head when I visit a sprint planning. So why not share it 🙂

• Do all team members understand the meaning of the story?
• Is the definition of done clear?
• Do all team members understand how the solution intends to solve the problem?
• Is the story broken down to a level so that team can cooperate around solving it?
• Is there a high cost of failure such, we need do address risk?
• Are stories related to outside parties in such a way this needs to be cared about?
• Is there a last responsible moment at which we can’t roll back?

Four years ago I spent a few months assembling a rather wide-spread document which I named "State of the art in Server Side Java". It was at the time well researched enough to end up as an entry on The Server Side. Soon thereafter I got sidetracked to follow Ajax for a few years. I

I once worked in a rather large project, about 1000 persons. There are many stories about that project but the one that I’m thinking of now is that we loved to say "stable interface, we must have stable interfaces".

Now, stable means not changing which means nothing gets better. So why would anyone want stable interfaces? And what should we say about the opposite, "unstable"?

Stable interfaces is a cornerstone in tactics for modifiability, so how do stability and modifiability go hand in hand?

Do you see my finger?

Eclipse trashed some code for me today and I had to recreate the workspace. On such days, I can get a bit edgy and maybe I was, when commenting Richard Kronfält’s blog on Scrum and traditional QA.

Sorry about that, Richard, but you are a viking so I guess I can get away with a glass of mjöd if I ever bump into you.

But my point is still, requirements specification is waste. It follows from that the issue tracking is as well. Well, not always.

Here are the slides for my presentation Kanban vs Scrum. I’m glad people enjoyed it! The participants were asked to rate how valuable the presentation was on a scale 1-3. The average rating was 3.0 at Deep Lean and 2.9 at Future of Agile :o) This presentation is based on my Kanban vs Scrum article,

Experience the humbleness and energy of so many people in one single place was a great experience. I would have liked to stay longer just do discuss and share experiences.

Takeaways:

• As Agile practitioners, we need to continue to evolve
• Kanban is a promising tool for sharing Lean benefits outside teams
• Pick the right tools for the job! Kanban and Scrum have their advantages, start with your problem and then pick the right tool
• David shared my experiences with Kanban teams demonstrating a "white box" behaviour instead of a "black box" (not your business) towards its stakeholders
• Classes of Service is a hot upcoming topic around Risk Management
• In Japan the "why" is the most important thing. Therefore rigorous effort is spent on understanding Values and Princinples, compared to our Western approach of staring with the Practices (therefore not being able to adopt when situation change)

Enough chat. Here are the slides:

• Future of Agile – David Anderson
  http://www.crisp.se/futureofagile/slides/davidanderson

• Kanban vs. Scrum – Henrik Kniberg
  http://www.crisp.se/futureofagile/slides/henrikkniberg
  
  
• Roots of Lean, visiting Toyota – Mattias Skarin
  http://www.crisp.se/futureofagile/slides/mattisskarin

Have a look inside the mythical Crisp software factory. Discover the secret of how we really build software 😮

Inside Crisp Software Factory.avi

In a famous Leadership IQ study, we surveyed 48,012 CEOs, Managers & Employees about their performance appraisals. Here’s the shocking results: Only 13% of Managers & Employees thought their performance appraisals were effective. And only 6% of CEOs thought their appraisals were effective. We also discovered that only 14% of employees say their performance appraisal conversation offered meaningful and relevant feedback.

So are we
 a) continuously allowing people work on what they like to do, with minimum overhead, or
 b) adding makeup to broken processes

Read Esther Derbys excellent followup