Crisp's BlogPage 30

I Computer Sweden skriver Ivar Jacobson att Det knakar rejält i Scrums fogar och trots att Ivar låter som en gammal sur gubbe som glömt att även RUP genomgått samma hypekurva som Agile/Scrum nu gör håller jag med honom om riskerna på en punkt: Det finns verkligen en tendens till "ingen arkitektur, ingen modellering, bara koda och strukturera om senare".

There’s a lot of buzz on Kanban right now in the agile software development community. Since Scrum has become quite mainstream now, a common question is “so what is Kanban, and how does it compare to Scrum?” Where do they complement each other? Are there any potential conflicts? Here’s an attempt to clear up some

I teach a course on System Architecture. It is a three-day course attended by experienced developers who want to go further in some respect.

What strikes me most is that the majority has never read any architecture document. Since writing such documents is one of the main topics of the course, I have a long road for them as they haven’t read any.

So, when you are faced with a system that you are about to change, how do you go about to understand it?

Niclas Nillson, Factor10, har just publicerat ritningar för sitt parprogrammeringsbord.

Teams often thinks they need to improve on estimating.
I think it is waste to try do that. 
But difference in actual and estimated velocity is good information, and nothing to be sorry about.
Mike Cohn have taught me this through his books "Agile Estimating and Planning" and "User Stories Applied". 
His teaching has been one of the most influental for me.
Find out more at his site: www.mountaingoatsoftware.com

The Wicket framework is somewhat deceptive when it comes to testing, especially TDD.

A German translation of my book Scrum and XP from the Trenches is now available. Thanks Robert Sösemann & Andreas Schliep! Russian, French, Spanish, Japanese, Chinese, and Portuguese translations are also available. Korean, Italian, and Slovak translations are underway. I never cease to be impressed by the agile community! So far, every time I’ve blogged

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.

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)

My collagues are talking a lot about Lean these days. I thought it would be interesting to simulate one of their examples using JavaFX.

Here is a picture:

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…"

Before we consider agile contracting, or projects in general – there is one thing we must start to be honest about.

We cannot estimate a software problem accurately. In fact, our best estimate will most likely have a variance of at least 100 percent.  There is a reason why people like Alistair Cockburn calls this "the unsolved problem in software development.

• An upfront estimate replacing a 15 year old system I did with a team turned out to have a scope difference of over 100% in the end. To our help we had really skilled Business people with us all the way. (..we met the deadline and customer was excited but that’s an Agile story).
• Typically the scope ends at 189% of original estimate. (The Standish Group’s chaos report).
• Big upfront design results in over 45% of functionality never used (Scott Ambler , Dr Dobbs journal)
• There is a 10 to 1 productivity ratio between developers. So who does the job has a profound inpact (Software Cost Estimation with Cocomo II)

As an Agile/Scrum coach I value commitment from the team at the top of my requirement or wish lists, even higher than Kaizen (Continuous Improvement).

So why is this so important?

David Barnholdt and I recently attended a 1-week PSL workshop (Problem Solving Leadership) with Jerry Weinberg, Esther Derby, and Johanna Rothman, one of the best courses I’ve ever attended. After that course we’ve been thinking about ways to make our own training courses more interactive. David was first out and invented a brilliant exercise demonstrating

Me and Oscar is currently working on a small project, just to learn JavaFX.

We stumbled on some nasty crashes which we at first did not understand.

ArrayIndexOutOfBoundsException? Is there a bug in JavaFX?

It turned out to be a callback from Java. Let us see how we got there.

Webbramverket Lift, skrivet i Scala, har precis släppts i version 1.0. Mycket spännande, tycker jag. Citat från Michael Galpin: Lift is the only new framework in the last four years to offer fresh and innovative approaches to web development. It’s not just some incremental improvements over the status quo, it redefines the state of the

Cross-functional team doesn’t mean everybody has to know everything – this seems to be a common misinterpretation though. Cross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing. Are you unsure if your

Alexey Kritivitsky (Ukraine Agile community) has created a fun Scrum training exercise new teams using Lego.

Since games is such a brilliant teaching tool, you should know about it 🙂
http://tinyurl.com/legoscrum

Vad borde ScrumMaster heta på svenska, och varför heter det ScrumMaster och inte Scrum Master på engelska?

Enligt en anekdot jag hört så var ursprungsnamnet Scrum Slave, men Ken Schwaber och Jeff Sutherland insåg tidigt att det inte skulle vara så säljande. 🙂

6 months after we began using Kanban to two support / system administration teams they realized that the downside of having multiple projects running outweighed the possible upside.

How long time should there be between goals?

Some make a habit of setting yearly goals. Some set quarterly. Small organisations in a turmoil can set weekly goals.

But what is "just right"?

How can anyone say

that they are Lean or agile when they don’t inspect and adapt.

What most companies have in common when they implement process improvement is lack of continuous improvement…..  

Today I held a class in Scrum and Lean.
I was able to test some of my learnings from the PSL class in a exercises I made up just the day before. 
The results were almost too good.

Do you believe a manufactoring plant is a good model for software development?

No? Then what why would you strive so hard to apply Lean in IT?
Think about the answer for a while.

I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt. My conclusion is, not very suprisingly, that  it depends on the situation.

In this entry I take the Scrum T-shirt on.

I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt. My conclusion is, not very surprisingly, that  it depends on the situation.

In this entry I take the Kanban hat on.

Alex Miller har precis bloggat om vad han tycker verkar ske när det gäller Java 7. Vi kan få en preview till JavaOne 2009 (dvs juni) och ett teoretiskt releasedatum på januari 2010, men Miller tycker det är för mycket osäkerheter för att tro på en så pass snabb release. Generellt sett så tror jag

Yesterday, in a post by David Andersson, he so accurately in few words managed to describe the fundaments any Lean implementation.

"In Lean operational decisions, value trumps flow, and flow trumps
waste reduction."

The value of waste reduction (over flow) is for me one of the great misunderstanding of Lean.

En kort sammanfattning av grunderna i Lean på 10 minuter. Concept To Cash, Cykeltid optimering och köer och flaskhalsar.

Lean handlar om att bli snabb genom att sluta göra onödiga saker.

Lean värdesätter det som levereras och inte det som påbörjas. Att få saker ur händerna istället för att jobba hårt.

Here’s a great list of agile tools on Mike Cohn’s User Stories site! Primarily for product backlog and user story management. Only problem is that there are way too few reviews so far. Are you using an agile tool? Go submit a review now and spread the link to your friends! Let’s help build this