Comments for Agile at Luminis

Comment on Staying lean! by Ed Kirwan

Ed Kirwan — Wed, 21 Oct 2009 06:03:52 +0000

“Combining observations here it becomes increasingly important to stay modular and to really try hard to loosely couple your components because that has tremendous benefits in the long run.”

I can’t help feeling that there’s a tautology in there.

Though I’m not a fan of Kirk’s lack of definition of modularity: it’s too important a term to leave loosely defined.

Still, can’t argue: loose coupling and, “Modularity,” are the way to go.

Ed.

Comment on Issue driven kanban standup by Inanc Gumus

Inanc Gumus — Tue, 20 Oct 2009 07:22:07 +0000

Thanks for the post. May I ask you to provide more explanation? For example: How this is different from: “one member is asking another, what’s up?”. Is the whole team makes the difference?

Comment on Scrum to Kanban: what happened to planning? by sandra407

sandra407 — Wed, 09 Sep 2009 15:41:22 +0000

Hi! I was surfing and found your blog post… nice! I love your blog. Cheers! Sandra. R.

Comment on The right people are not afraid by Twitter Trackbacks for The right people are not afraid « agile.luminis.nl [luminis.nl] on Topsy.com

Mon, 24 Aug 2009 23:24:55 +0000

[...] The right people are not afraid « agile.luminis.nl agile.luminis.nl/?p=227 – view page – cached #agile.luminis.nl RSS Feed agile.luminis.nl Atom Feed agile.luminis.nl » The right people are not afraid Comments Feed agile.luminis.nl Scrum to kanban Things the books don’t tell you — From the page [...]

Comment on Scrum Luminis edition by Things the books don’t tell you « agile.luminis.nl

Things the books don’t tell you « agile.luminis.nl — Tue, 18 Aug 2009 15:47:04 +0000

[...] About « Scrum Luminis edition [...]

Comment on To Scrum or not to Scrum, or ScrumBut? by Scrum Luminis edition « agile.luminis.nl

Scrum Luminis edition « agile.luminis.nl — Tue, 18 Aug 2009 15:19:19 +0000

[...] comes the real interesting stuff. You could call these “violations of Scrum” if you wanted but then listen to the local circumstances which drive the process modifications. Roughly in [...]

Comment on To Scrum or not to Scrum, or ScrumBut? by Wout Lemmens

Wout Lemmens — Thu, 16 Jul 2009 20:07:44 +0000

I agree that the more practices applied, the more benefits you get as they add up. But in some cases ‘customising the process’ is even better, as forcing practices into an organization might even work out counterproductive.

Finding the right balance in ‘customisation’ is the real hard part in this.

Comment on To Scrum or not to Scrum, or ScrumBut? by Siddharta

Siddharta — Thu, 16 Jul 2009 10:27:42 +0000

Nice post.

I think even if you take one or two practices on their own, it can still add value. And as long as you know where you stand and what you are getting then there is no problem with it.

The issue is when you *think* you are doing full Scrum with a modification or two, and then you are confused why you are not getting the benefits. In this case, you are not applying the “buts” with the knowledge of what the tradeoff is going to be like.

Result is that you become disillusioned with results and decide that it doesnt work.

IMHO this is the difference between “customising the process” (good) and “ScrumBut” (bad).

Both are basically the same thing.

Only difference is that in the first case, you are doing changes with full understanding of what you are doing. In the second you are doing something without understanding the consequences.

Comment on To Scrum or not to Scrum, or ScrumBut? by Jack Milunsky

Jack Milunsky — Wed, 15 Jul 2009 19:54:30 +0000

I think there’s benefits in each agile/scrum practice on it’s own but if you’re doing Scrumbut, you don’t get the 1+1 >2 effect.

Additionally, a lot of thought went into figuring out the process and things are there for a reason. So I’d be inclined to want to do thing right from the start.

My 2 cents
jack
blog.agilebuddy.com
twitter.com/agilebuddy

Comment on Scrum & technical debt by Marcel Offermans

Marcel Offermans — Tue, 07 Jul 2009 19:31:44 +0000

One thing that can be done during “debt days” is refactoring your codebase. This usually impacts other developers, giving them a hard time merging their changes, but at the end of a sprint, with the whole team on it, the code in a working state and all tests to help you ensure system integrity, this can be done very efficiently.