First of all, welcome to my new website!

Or more precisely, the same website, but with a new appearance. So it just looks new. But anyways, welcome!

Thanks all the people who actually made it happen - you know who you are.

In those times when I have had more time to work with a team to get them started, I have used the following general outline and found it working. By working I mean, it has struck a good balance between effort invested and value delivered. Investing more time could make things even faster, but not proportionally. Investing less time would reduce value and impact disproportionately. You know.

The Plan for Team’s First Sprints

* Pre-game *

1) Kick-off meeting on first day, to get started (this is more
facilitation than training), including

• What are the things we don’t know? How critical are they to know before we start Sprint 1?
• How do we learn together?

2) High level conversations – concept, requirements, UX, design, architecture, technologies, …

To me, there are two things in Agile from which everything else follows. Before moving on, what are those two things in your opinion?

Getting things DONE

The first thing is the potentially shippable product increment, delivered frequently. In Scrum this means that at least at the end of every Sprint, the technical quality of the product meets the criteria of shipping the product (but it doesn’t have to be shipped, for whatever reason, such as not having a shippable feature state). In Kanban flow, this state is reached at the end of every developed item.

This state means, for example:

Again, I’ll post an email response to question from an alumni. This post is also available on Futurice Blog.

The question:

I am working on an agile project and I don’t know when to incorporate prototyping.

TL;DR: Work smarter, not harder.

I have noticed that all systems have some natural capability for productivity, value delivery and quality. As the people in the system gain experience in the system, their performance will start reaching that systemic speed. Just like with a ship, this happens quite easily, but when the “hull speed”* is reached, the amount of effort / power to go faster dramatically increases, up to the point that a certain speed seems unsurmountable regardless of power expended. In systems, we can perceive this e.g. in overtime, which does not yield real benefit since the extra effort translates to more mistakes and other negative factors that detract from real progress.

I continually observe that also in the ball point game, where people psyche themselves to try harder, but they still get the same result.

While I have many stories of release planning, I like to share this one.

Getting started… a little late

I was coaching this game team/organization. The original plan for the next game called for about 6 months of design and development. However, due to other pressures, a lot of things were prioritized over this project and when the first people were able to start the work, only three months were remaining. There was hope that using Agile could help them speed up the development (through prioritization, backlog refinement and faster development), but it was still known that it will be tough.

At the beginning of the work, the game concept was available. A backlog had been built collaboratively with the team. For the first two sprints, only half of the team was available, and they started on the most critical stories. During this time, the backlog was radically refined and prioritized (i.e. features slashed), up to the point that PO started to be concerned that “there was no fun left”.

In this blog post, I’ll share a bit of a conversation I was having with a participant of my CSM course, who had his team ask provoking questions. I’ll share the questions and my responses. Remember that this is a conversation piece, so I can’t guarantee it’s more than opinions :).

Snippety snip, start the email here (the original email in quotes, my response in blue):

I had a great retrospective with the team that was having buy-in issues last week and they expressed some fundamental questions that they had not been given answers to.

I sometimes struggle between relative and absolute quality, and how they affect the way we work in businesses and the success we gain. That is, I really would like to think we should strive for better outcomes as a kind of value on its own (and merit from that as business success), but I so much more see “being better than competition” as “sufficient” for most people (and frankly, it is good enough for many companies to stay in business).

In practice, the questions boils down to “we’re already better than our competition, why over-invest?” The way I hear that is “let’s cash in on our advantage now, until we lose it”. I also hear “let’s gain in short term, and figure out long-term competitiveness later”. And I can see the logic in that. But it’s the same logic that has effectively crippled so many companies and destroyed their long term profitability.

I recall reading somewhere that the founder of Ikea, Ingvar Kamprad, once said that “the worst thing that could happen to Ikea would be to go public.” He was referring to the tendency of publicly traded companies to focus on short term outcomes and shareholder value over any other business priorities. While I’m no fan of Ikea, I can appreciate the success they have built (and yea, some few of the items they have designed have appealed also to me). And I can appreciate the mindset.