Finding Marbles – Page 20 – How work can be

What is this “Agile Mindset” anyway?

UPDATE 2013: There’s a condensed, infographic-y version here

If you’re new to the agile world, what are behaviors to look for? In the chart you find examples of what I deem “agile” and “not quite so agile” behavior.

These are, of course, completely subjective! Also I think there are rather too many scales. What would you change? Which are superfluous?

PS: Be sure to also watch Linda Rising’s keynote on this topic. She concentrates on the “success through effort” vs. “fixed” aspect.

PPS: Here’s the document on Google, if you want to export it.

Update: See this article by Johanna Rothmann for some questions you can ask during a job interview to check for a Lean mindset (via Matthias Bohlen).

Don’t keep stuck to your daily routine

There’s a certain type of quiet movie that I like a lot. It usually starts with a stranger entering a closed group, e.g. a village and the dynamics that enfold because of it. “The Adventures of Priscilla, Queen of the Desert“, “Fried Green Tomatoes” or “Kitchen Stories” are excellent examples. Did you ever stop to wonder, why the movies show that particular point in time, when the new element is introduced? Why not the 5 or 10 years before that?

Because such a movie would be bor-*yawn*-ing: A closed “system” tends to reach an equilibrium and stay there. Even things that make you think “WTF?” when starting a new job will become “the way things are done” a few weeks down the road. And once we’ve gotten used to stupid things, we stop seeing the madness and stop initiating improvements. Continue reading “Don’t keep stuck to your daily routine”

Assess your agile engineering practices

Some weeks ago I read a slide deck by Jeff Nielsen about “Five Key Numbers to Gauge your Agile Engineering Efforts“. Even though using agile engineering practices is no goal in itself, the practices are usually helpful in reaching the ultimate goal of useful software. That’s why I compiled the five numbers into a single page to print out and let teams self-assess.

Feel free to use the image, e.g. during a retrospective. You could even repeat the assessment a few months later to track improvements 🙂
[This is Activity #35 in Retr-O-Mat]

PS: Thanks to Jeff Nielsen for the data

Scrum Master Emergency Kit

The other day at work, I was asked to moderate an impromptu meeting and while I gathered markers and stickie notes to rush to the meeting, I thought how nice it would be to have a ready-packed kit. Something to just grab and you’re good to go for basic moderation.

As white boards and flip charts are a bit to large for something rightfully called a “kit” here’s a stylized version of what my Scrum Master Emergency Kit would look like:

Scrum Master Emergency Kit - Bright'n'Shiny-Edition — Edition “Bright’n’Shiny”

Sticky notes, magnets, board marker – That’s it. For the more understated and / or serious among you, here’s the same in sedated colors: Continue reading “Scrum Master Emergency Kit”

My Appreciation Card for ALE 2011

Last week I attended ALE 2011, an unconference organized by members of Agile Lean Europe (ALE) – “A network for collaboration of Agile & Lean thinkers and activists across Europe”. I’d like to go full circle and give to ALE 2011 something that I got to know at the conference: an appreciation card.

Appreciation cards in all colors — Appreciation Cards

Continue reading “My Appreciation Card for ALE 2011”

Agile @ Universities

Don’t you love it, when you’re sitting in a talk with a “this sounds vaguely interesting”-attitude and it turns out to be really inspiring? Happened to me at ALE 2011 with Bruce Scharlau‘s talk about “Agile at the University”. He presented the various ways, he teaches agile at Aberdeen and how all of us in attendance could help spread the word about agile methods.

Thinking back, I don’t recall ever having heard anything about agile development during university.* But it would be much easier to instill people with an agile mindset during their education than to have them unlearn “big design up front”-thinking when they start working. And agile study assignments would probably be more fun, too.

Bruce convinced me and I’ve already written to two universities offering a talk or guest lecture. Christoph will contact a third one.

If you’d also like to take action, record your efforts in this wiki. Who knows, in a few years time, we might all enjoy colleagues fresh from university that are already familiar with agile development 🙂

*For me the saving grace were several courses in human computer interaction, which contained the “Design – Implement – Analyze”-cycle. So when I left my alma mater I already thought that short iterations are a pretty neat idea.

Software Craftsmanship

A couple of days ago we talked about the Software Craftsmanship movement at work. I thought of the movement as an extension to the agile movement, that goes full circle to agile’s roots in software development, and focuses on practising coding skills.

This is the Software Craftsmanship Manifesto:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software,

but also well-crafted software

Not only responding to change,

but also steadily adding value

Not only individuals and interactions,

but also a community of professionals

Not only customer collaboration,

but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

Source

Some colleagues were irritated that it’s called “craftsmanship”, after all they spent years at university becoming software engineers. But today (the first day of ALE 2011) it made perfect sense, when Markus Gärtner explained the second important aspect of Software Craftsmanship: How new developers are taught and mentored – The ideas include apprenticeship and traveling the world afterwards, the same way journeymen to do, learning from different masters of the craft in each location. There’s even a map showing where software journeymen and -women are welcome.

Thanks, Markus, for a very interesting talk!

Scrum Masters’ Occupational Hazards?

[Something light for the weekend (the sun is finally shining, yay!)]

When taking notes on white boards or flip charts all day you’ll eventually lose grip on an uncapped marker:

Shirt with marker stain — Exhibit A: Marker stains on polo shirt

The marker stains weren’t impressed by my washing machine. I guess that’s why they are called “dry-erase” markers and not “wet-washed”… Too bad, I liked that shirt.

I wonder what other occupational “hazards” SMs are prone to? A slight addicition to marker and / or post-it fumes? Leg cramps due to standing, standing, standing? What else?

Getting things done: Daily goals

Searching for ways to stay more focused on the stories, several of our teams use the following trick: Each morning during standup they set themselves a daily goal.

daily-goals_per-person — Daily goals (“Tagesziele”) for each team member

In some teams these goals are for the whole team, in others each team member sets a goal for themselves (or pairs). Either way works fine for us and achieves several things:

It creates a mini-deadline that helps those who thrive on deadlines and for whom the end of a 2-week sprint is to far ahead
Finding the next day that you reached the goal gives a sense of achievement (a bit more than moving stickies)
If the goal doesn’t change (because it’s not reached) it becomes blatantly obvious that there is an impediment and you can thus address it

daily-goals_team — Daily goals for a team

So if you’ve got problems focusing or with impediments not being raised, daily goals might do the trick 🙂

PS: In case it wasn’t obvious: The teams set their own goals, not someone else.

That goes without saying! Not.

Whenever someone complains about a third (absent) person I usually suggest talking to said person directly. In my mind it makes perfect sense that we can’t expect someone to behave differently in the future, if they’re unaware that their behavior offended someone.

Surprisingly often I get replies like:

“But that should be self-evident! I really shouldn’t have to spell it out for her.”
“He knows that! … or at least he should!”
“Should be obvious, shouldn’t it?”

The irony is not lost on me, given that the conversation only takes place, because it didn’t work out as expected and it most probably wasn’t clear. But instead of assuming “wasn’t clear” the offending behavior is often attributed to malicious intent and / or laziness. In my experience these reasons apply only in a minority of cases. The following reasons are much more common: Continue reading “That goes without saying! Not.”