Improving the world with software
Better software. Better questions.
Essays on software development, teams and the craft of building things that last.
Essays, page 12
147 essays in the archive
-
Learn or else…
Through Elisabeth Hendrickson I got to Brett Pettichord’s post about the role of feedback in Agile. Read it if you haven’t yet. Here are the pearls that made me post this: “If you don’t have meaningful feedback then you’re not agile. You’re just in a new form of chaos.” and “Agile practices build a technical …
-
You are not ready for agile if…
This is a post I’ve been meaning to write for a long time. Who am I kidding, I don’t have the time right now, so I’ll let Andy do the talking: You’re not ready for agile if you: * behave territorially. You mark your territory like an aggressive dog, refusing to share power or information, …
-
Why learning is important (or why you should attend Scan-Agile ’08). The story of grandpa Tony and grandpa Francis
I’ve come to realize lately that today’s ability to learn is similar to last centuries ability to read. Confused? Let me tell you a story.One of my grandfathers (let’s call him grandpa Francis) knew how to read, he was able to keep up with the latest developments in agriculture and even read the weather forecast …
-
Belief without proof is dangerous!
Believing in some far-fetched (or indeed any) explanation without having any proof is dangerous. It is dangerous in the case of the flat-earthers and it is dangerous for project leaders and team members. Whenever a theory emerges why something works (or doesn’t) in your project/company, it is your duty to either prove it right or …
-
Great description of Agile planning sessions
Lasse has written a great post on estimation using the Story Point concept and the Planning poker practice. Some time ago I also wrote a post on how to make these Planning Poker sessions timeboxed but still effective. If you are interested in estimation and planning in Agile Software Development these posts are worth a …
-
The new skill paradigm
In the past we hired managers because they could “keep the people under control” and they could “get things done no matter what”.Although the first one is clearly in contrast with the self-organizing nature of Agile, some people still believe the second one… Well, I propose that the most important skill for managers today (in …
-
Spreading the happy flu, an experiment to study epidemics (meme-style)
In the interest of science (studying epidemics dynamics) I’m posting this “spread the happy flu” post. I got the happy flu from Henrik Mårtensson.
-
For a better format for User Stories
Karl follows up on a post by Liz Keogh about the fact that User Stories need to have a different format. The original format was: As a <customer role> I want <functionality> because <customer value explanation>. Before explaining the new format let me dissect a little bit this old format. Why is it wrong? Clearly …
-
An inconvenient truth, in work management
I bet anyone in my position (Agile Coach) has faced this before: you present a work method to a team or a person (be it scrum, XP, DSDM, FDD, etc.) and they go “yeah, I see what you mean, but that would never work here”. If I only had a dime for every time I …
-
Project smells
Jason suggests that projects, in his experience, face similar problems (I’m assuming he is talking about all projects, including Agile projects). What is your experience? What are the mistakes that happen all the time as Jason suggests? In the waterfall world one of my favorites that happened all the time was: requirements change constantly. Can …
-
The Green Shift Anti-Pattern
This is a pattern that effectively prevents any team from succeeding, and in many cases just causes a whole organization to behave in a dysfunctional way. Check it out. Has it happened to ? No, honestly! Blogged with the Flock Browser
-
Don’t blame, reward people that surface their own mistakes!
In Lean thinking errors or mistakes are seen as opportunity for improvement and growth. But in lean, mistakes don’t come alone, they also provide an opportunity for the team to create a poka-yoke tool/device. Poka-yoke stands for “mistake proofing”, i.e. making sure the same mistake does not happen again. This can only be done by …
Nothing matches that yet.
Keep the conversation going
The essays work best in company. Join the community to keep the questions coming.