“Earth to Anders! It’s the daily stand-up!”

It felt like being a boy again, hearing my mother calling me in for dinner when it finally was my turn to be Darth Vader.

I didn’t want to attend that meeting. Agile was great, but I wanted to code. To learn my tools. To be an awesome engineer.

Two weeks into my first iterative project, I was in conflict with myself.

It came unexpectedly; not only was this an agile project – I finally had the chance to code Enterprise Java using this innovative IDE with refactoring tools and other sophisticated code manipulation features called Eclipse. The project of my dreams, in other words.

(You guessed right, it’s some 10 years ago.)

My team and I had also read books about agile methodology, and we just loved throwing away late testing, early specifications and other anachronisms of the checkered past of software engineering. Our focus was on feedback: We had daily stand-ups, long retrospectives and pair programming.

But there was a snag:

I finally had the chance to code Enterprise Java using Eclipse. What a feeling it was, to put on my headsets, start Winamp and load my Jazz mp3s. Extract interface. Quick fix. Generate getters and setters. That’s when they would call for me. “Stand up time! Stand up!”

It is frustrating to be pulled out of flow.

I often see this conflict surface when we discuss iteration (sprint) duration. Or feedback cycle, to be more general. I’m seeing many teams these days that want longer iterations because they spend too much time in “non-productive” interactions. But beware: This is where we betray our less glamorous attitudes.

I was a flow fanatic for some time, until I got tired of the consequences of work in isolation: Lack of flow is less frustrating than lack feedback – nobody wants to efficiently build a product that sucks. To realize this requires a longer perspective, a logical way thinking. Broken flows are short-term feeling and they are more powerful than logic. Hence, flow wins, by default.

Iterations are here to help us produce the right software, at the right time, and this overall goal is not proportional to each and every team members’ feeling of productivity at any given time. Engineering skills will always be important, as will the opportunity to apply your skills productively. But we need to be clear with our selves and with each other:

At the end of the day, what’s more important – feeling productive or creating value?

It’s the long-term perspective that matters in the long run. So no. Don’t go with the flow.

Anders Haugeto (36) is entrepreneur, engineer and experiment designer helping the customers of Iterate innovate faster. He uses systems thinking, business model generation and Lean Startup to create innovation monsters – intrapreneurs – who’s mission in life is to disrupt their organization from within. Follow his tweets about experiments and entrepreneurship here: @hauge2.