Here is a real world story about Steve Jobs:

"I wish you could have seen Steve in action with Lee Clow of Chiat/Day, working on Apple's ‘Think Different’ campaign. Lee, the living legend whose creations ranged from the ‘1984’ Apple commercial to ‘Yo Quiero Taco Bell,’ showed an early version of ‘Here's to the crazy ones’ from the ‘Think Different’ campaign. A full minute of black-and-white pictures of Picasso, Einstein, Muhammad Ali, Rosa Parks, Bucky Fuller, amazing music and Richard Dreyfus reading this poem, seeing it for the first time brought the hair up on the back of my neck. So here I am, practically with tears rolling down my face, and Steve just looks at Lee, shakes his head, and says, ‘You've lost it.’ I thought, ‘What?! That's one of the greatest ads I've ever seen!’ And here's Steve going, ‘No. The music isn't right. It was right before. And you've changed the pace of the pictures, and you've got them in the wrong order.’ He sends them packing, back to LA. They came back after probably 30 hours with no bodily functions, and I was stunned. It was a lot better. Steve has a vision of what great is, and he's never going to settle for anybody else's standard of great.

(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.

Read more...

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? :)

Read more...

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.

Read more...

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

Read more...

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?

Read more...

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

Read more...

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

Inside Crisp Software Factory.avi

Read more...

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

Read more...

I held a seminar at NFI today "Introduction to Lean Software Development".  Afterwards, I got the question "where is a good starting point to learn more?" - and realized that while there is new material, much is still "in work" (for example: Mary and David are both working in new books).  So updated information it is not easily found.

If you are completely new to the subject:

• Implementing Lean Software Development - Mary & Tom Poppendieck
  [comment] While there is newer material, this is a good starting point.

"I have the basic understanding and now want to move on to the software specific stuff"

• David Anderson Kanban for software presentation
  [comment] good visualization of concepts in practice
  
  
• Mary has a great essay page
  [comment] nice inspiration
  
  
• ..or grab my slides from today  "Introduction to Lean software development"
  [comment] ..note, at least half of the content was delivered verbally, but the stuff in here is up to date

Psst!: Two great opportunities exists in May to get the latest in Lean here in Sweden:

• Deep Lean 18-19 May -  with Mary Poppendieck and Jeff Sutherland
  
• Future of Agile - with David Anderson, Mattias Skarin and Henrik Kniberg

Read more...

I attended the Lean & Kanban conference last week. The first of it's kind, a big boost of energy and I certainly hope to see more on this subject.

It was striking how, in case after case, the simple introduction of visual management and matching work to capacity (Kanban) sent teams off on a journey exploring Queues, Pull, System Thinking and even Deming(!). 

Here are my biggest takeaways:

• Even highly performing senior teams get a boost by using Kanban (a bit of surprice to me)
  
  
• Classes of service enables teams to self organize around risk elimination. (David Anderson). If you have been thinking of  "is there any way around analysing full test suite/architecture up front - this is what you are looking for. Extremely interesting stuff.
• It was nice to hear the community has picked up that the primary model for software is Lean Product development first, then ideas from lean manufacturing
  
  
• How system thinking quickly was perceived as the primary constraint when scaling and how Deming holds many answers
  
  
• Talking to Dean Leffingwell an confirming my thoughts regarding the need for a cooperation model

I 'll probably come back more on this subject :)

Read more...

When applying Lean, or thinking about scaling agile benefits to the Enterprise we tend to "home in" on the practices (Release cadance, Kanban, Flow, Portfolio management, risk etc). These are all valuable and the world would be a happier place if used more :) . But - it is as important to not to forget to bundle those practices with a cooperation model.

Basically, practices without a cooperation model = high risk of failure.

Read more...

I have updated the original quick reference originally created for system administration teams now to focus on introducing Kanban. A two page A4 visual of "what is it all about".



So here is Kanban in 5 min.

Read more...

Back from Japan! It was a very learning week. Among other we met

• Manager for Toyota automotive  software
• CEO of Fujitsu Siemens Software
  
• Representatives from the Agile community in Japan
• Agile pioneers such as Eiwa and Azzuri
• Cheif engineer of Lexus and Supra program, Katyama-san
• Former IT manager of Toyota Kuriowa-san

And of course visited a Toyota plant :)

It was really interesting to see:

• Toyota's response to the current crises, totally different from what I'd expect western companies to do
• How continuous improvement, Kaizen, is on top of the agenda. Especially CEO's. "It is in our DNA"
• How Kanban is the center of the modern Japanese software shop
• How the Agile community of Japan is spearheading changes
• How new cars got developed and how people leading these efforts where picked (comparison: Product Owner in Scrum)

I am going to talk more about this in my session at Future of Agile.
Big thanks to Bent and Kenji who made this possible.

Read more...

I am currently on a visit to Japan to meet Toyota and representatives from Japan's industry to learn about their challenges. Already on day one, things got really interesting.

We met today with the CEO of a Fujitsu subsidiary, specialized in software. The company is applying TPS to improve their practices. It was interesting to see that:

• The CEO was puts improving engineering and kaizen practices on top of his agenda. He is committed and actively involved, driving improvements. In his world improvements comes first, operations second.
  
  
• A sign of the ambition is the fact that the company employs a mathematical expert to help out with analysis. When would that happen in a western company :)
  
  
• They are experimenting a lot with estimation techniques! The technique currently favored is "Function Scale" -  a simplified version of Function Points. The technique is based on user interface design and is fast, only takes 1-2 minute compared to what a skilled function point analysis would take 30 min or more to do.

Some reflections:

• Culture and local experiences affects solutions looked at. Turning to TPS, Kaizen and statistical process techniques for improving software products is therefore logical
  
• But - using best practices based on other's success, without thinking (what problem it was intended to solve, how this would help our situation) - is dangerous. Not only can this stop you from solving the right problem (you might be in another situation!) it can also dilute your competitiveness no longer staying ahead. Something to think about when we apply Scrum, Lean or any practice.

Anyway, a really interesting week up ahead! Tomorrow, first visit at Toyota plant, later in week , meeting the former Lexus cheif engineer Kataymy-san and the former IT manager of Toyota.

Read more...

The schedule is taking shape for May 27:th,  we now announce two more sessions:

• Kanban vs. Scrum - Henrik Kniberg
  
• Roots of Lean and Agile  - direct report from Toyota visit
  

Also, meet the experts face2face in the afternoon open space session. Here is your chance to discuss in person with the father of Kanban, David Anderson and with Henrik Kniberg.

More is to come. Seats are limited. Don't miss out.

http://www.crisp.se/futureofagile

Read more...

In the 2:nd of April I held a talk for the danish public sector at the ISA conference in Aarhus called  "Agile - Myth or Magic?"



The slides are avaliable here

It was interesting to meet many from the public sector and discuss their challenges. The Danish Ministry of Technology and Development has come a far way in Agile Contracting. I hope to see more reports from this!

Read more...

In times when filling in story cards and updating burndown charts feels like a discriminating overhead, it can be joyful to know even the Apollo crews could not leave without proper formalia :)

Read more...

When running Scrum (or Kanban), you will need management involvement. And it is actually better that you secure it from the start.

Don't get me wrong - I am not advocating  detailed control and interference. No, what I am talking about is getting some punch behind dealing with impediments that your team will surface.

Read more...

When I have worked with scaling Scrum over several teams (up to 10 in parallell), I have strived to strengthen the same processes that gives traction to a single team.

Alistair Cockburn compiles this beautifully in his Software engineering in 21:st century

People issues determining a projects speed

• Can they easily detect something needs attention? (Good at Looking Around)
• Will they care enough to do something about it? (Pride-in-work; Amicability)
• Can they effectively pass along the information?  (Proximity; face-to-face)

Read more...

For all you heroes fighting a daily battles convincing teams, managers, tester, that deploying  software work to production anytime using CI it's possible, well here is a story that might encourage you. (Thanks to Xavier Allue).

In the 1950's, a japanese team struggled with a big die press. The die press could not be changed to new conditions fast enough, so they always had to work with big batches in order to make up for lost setup time.  (big software project ring a bell?). The team decided to get that setup time down from double digit to single digit number. It took them years. But - they actually finally made it.

At the time, there was an alternative point of view:

"While these japanese guys like to promote the notion of fast setup
changes, this simply isn't viable on very large scale activities. For
example, this die press here next to me uses 3-ton dies and takes five
foremen a full day to configure..."

Read more...