What ever happened to XP?

In June InfoQ published a very interesting talk by Rachel Davies “Back to the Future: What Ever Happened to Being eXtreme?

I think Rachel is spot on about a lot of things such as:

  • Some craftsmen care too much about code and too little about what problem it solves
  • There’s a  sad lack of developers at agile confs

While listening I noticed that we do a lot of the XP practices at work. And we introduced them via the backdoor Scrum. By now I’m pretty convinced that (in the software business) Scrum can’t work longterm without XP. But XP probably works fine without Scrum… You may draw your own conclusions. (And yes, I’ve tried to find a job in place where they use just XP to test this theory. At least in Germany I couldn’t find any.)

Anyway, go watch the video. It was time well invested for me: “Back to the Future: What Ever Happened to Being eXtreme?

Rules are made up

Do you sometimes observe something awesome at work which makes you realize how much everybody’s mindset has already shifted towards lean and agile thinking? Lately I have a lot of these moments. I always savour them, because in every day routine it’s easy to see only problems and forget all the things that are already working great. It’s uplifting to not always look at the road ahead, but to take the time to turn around and rejoice in all the ground you’ve already covered. I had one such rejoicing moment 2 weeks ago.

How far we’ve come

I took part in an Inhouse Podojo, i.e. all attendants were colleagues of mine. Spoiler Alert: If you’re thinking of joining a Podojo, please don’t read on! I mean it, shush, go away!

Still there? Okay. Part of the Podojo was the inevitable Lego simulation. In the simulation we had 2 Scrum Teams with 8 people each. Each team had its own lanes of stories and its own table to build on, though we were to work on the same product and had to “integrate” on Team A’s table at the end of each sprint. 3 sprints to go.

In the first sprint planning (3 minutes) our PO went to take a first pick of stories from our 2 story lanes and the team decided how many to take. We got all of it built, but at integration time we found that the other team had built some of the exact same stuff, because their 2 lanes had had some of the same stories. At least we had similar priorities in picking these overlapping stories first ;)

Building stuff twice was the obvious problem to fix during the first retrospective. And that’s where it got interesting: Both team’s independently of each other decided that a) the POs should go pick the stories together and b) we should all work on one table. And so we pushed the tables together to make one big workspace.

It worked great. So great in fact, that neither team had any great complaints or improvement ideas during the last two retros.

Why do I think the table-merging thingy is remarkable?

Continue reading

Wall-Skills: Design the Box, Japanese Terms in Lean, User Stories, less +F

Recent 1-pagers on Wall-Skills.com:

Is the vision for your product rather fuzzy? Design the box is an awesome technique to bring clarity and focus.

If you’re in a Scrum environment you’ll might encounter Lean at one point. Here’s a vocab cheat sheet: Japanese Terms in Lean

User Stories in a nutshell 1 page

Does your job entail keeping an eye on log files? Try less +F for viewing logs

A team has a common goal

At the moment I’m part of a really great team. We don’t even have a proper backlog, but it still works, because we have common long-term and short-term goals and a very clear shared vision.

However, in 2010, we already had teams, too. Well, “teams”. Teams in the name only.  See, back in 2010 we were still siloed. The “teams” were actually just a bunch of people sitting in the same room, doing similar things. We would say “backend team” although everyone in the group build and maintained their own system. To say it with Shakespeare:

Sharing a room doth not a team make.

A team has a common goal. Team members help each other reach this goal. None of the members has an individual goal more important than reaching the team’s goal. If there’s no common goal, don’t call them “team”. Call them “group”. Thank you!

Lean – Holding Precious What it is to be Human

lean-heart-bookAt the moment I’m working on a new talk “The Long Way to Lean” for the International PHP Conference in October. As I can’t expect everyone in the audience to have a concept of “Lean” I want to add a short introduction. And I don’t want it to be about “waste”!

So much more than “Reduce Waste”

I hate how much the discussion is centered on waste. At least in Germany that’s the most prominent feature of Lean. To make matters worse, value is not always part of the discussion. One would think that in order to define “waste” you would also have to strive for “value”, but, nope, in my experience it’s not necessarily so.

Though I definitely prefer to frame things in terms of “value” than in terms of “waste”, it still didn’t feel right to me. And then I remembered the two pillars of lean are “Continuous improvement” and

Respect for people

The other things derive from that. Creating value is a way to respect your customers and reducing waste is a way to respect your colleagues’ / employees’ time.

When I started researching the phrase I found that a more literal translation reads:

Holding Precious What it is to be Human

Isn’t that beautiful? We’re humans, we fail and make mistakes all the time. And that’s okay. We also have the ability to be kind, to learn and to work together to accomplish greatness. In its creators minds’ the saying also contained the imperative to invest in people as well as for everyone to improve:

Respect for people is the attitude that regards people’s ability to think most

I totally get why Taiichi Ohno refused to put his approach into writing for so long. People tend to look for rules, easy fixes. They find and implement JIT and limit WIP and yada yada yada. But without caring about people as its core, Lean just streamlines unpleasent workplaces without substantially improving lives. I’d also suspect that heartless Lean can’t change the bottomline much, because the people who know what needs to change are still ignored and company politics continue to rule the day…

Let’s take heart and hold humans precious when we strive for leanliness!

Bias for Action

… or the Anti-”Somebody else’s problem field

At one point I worked at a company where I would waste 5 minutes every time I wrote an email, thinking about the recipients of that mail. Not about who needed the information, but about who would be pissed – for vanity or political reasons -, if I didn’t include them. Besides time it wasted a lot of my energy because I disliked these games so much. A “cover your own ass” environment like that is toxic for initiative. It leads to a “not my job” attitude, if even slight deviation yields repercussions.

How much could we have achieved if us lower level employees could have run with our ideas? If we had been encouraged to show initiative and implement improvements right away?
Fortunately I work in the promised land right now: People running with their ideas and taking responsibility happen all the time at my employer and it’s awesome!

Example: Demo time

It was demo day. For us that means that all teams present what they launched in the previous 2 weeks. All in all 30-50 people. Usually we do this in the big conference room, but it was closed that week due to water damage.

10 minutes prior to the demo my colleague looked up from his screen and asked “Huh, where are we going to demo with the conf room out of order?”

In pre-agile 2010 times that would have been it. End of story. We would have assumed that “somebody”, e.g. the scrum masters, took care of it. All teams would have congregated somewhere and spend 10+ minutes watching someone set up a projector and screen and laptop and … 40 people looking on for 10 minutes? That’s a whole work day we would have collectively wasted.

Not nowadays, though. We were aware of the problem and we were capable of solving it. So we did.We used 10 minutes of 4 team members to get the equipment, set it up and gather everyone in the new location. Everything was set up and running at demo time. Nobody bored. Nobody annoyed. No time wasted.

How did we get here?

What happened between pre-agile 2010 and today? Do we just have more initiative? Though we do hire differently now, I think that only a small part of it boils down to how much drive individual employees have.

Here’s what’s IMO more important: Knowing that #1 you are permitted – heck, encouraged! – to improve whatever needs improving and #2 you have the time to do so. Your time and the time of other people that you need to make it happen. (Money is less important, but it helps that even bigger amounts are just one question away.) Continue reading

The NOT operator in Meteor.js (Spacebars, Handlebars)

Because a colleague praised Meteor.js I’m currently working through the tutorial and was stumped by trying to create an “if not” condition. Neither {{#if !myVar}} nor {{#if not myVar}} worked.

Maybe it’s just my inability to google, but I did not find the solution as quickly as I would have expected, so is there a NOT operator in Meteor? Can I negate an if condition?

The answer is “kind of”. You’re probably looking for:

{{#unless myVar}} ... {{/unless}}

unless is the opposite of if
(Source)

I also learned that Meteor’s templating mechanism is called “Spacebars“, which is derived from “Handlebars.js”. Both know “unless”.

PS: The colleague was completely right about Meteor: It’s awesome! I love it! You should totally try it!

Newsletters are great motivational tools

For the one sending the newsletter, not necessarily the readers ;)

Last month, when newsletter-sendout-time was nigh, I realized that I had not done anything agile-y all month. Nada. Zip. Zilch. There’s nothing like the prospect of sending out an empty newsletter to make you sit down and do stuff, like finish the 1-pager that’s been in the work for ages or finally add the 100th activity to Retr-O-Mat.

Offering an alternative to RSS for updates and connecting to my audience are both worthy ends. But ass-kicking in the GTD department? I did not foresee the newsletter doing this. Hope, I’ll not come to rely on it though …

Do you have a newsletter or something similar? Does it spur your productivity?

100 Activities in Retromat!

Rejoice with me for Retromat now features 100 activities!

Screen Shot 2015-04-07 at 9.33.04 PM

It’s come a long way since its humble launch with 16 activities 3 years ago (May 2012). It started with activities from Diana Larsen and Esther Derby‘s “Agile Retrospectives” and in an attempt to come full circle activity #100 is by Diana Larsen again.

Huge thanks to everybody who made that happen: People who thought of activities, suggested them, translated, sent photos, supported the print version, spread the word, … All you of you: Thank you!