coaching and training for adopting agile and scrum
Posted in Agile, Organisations

Organization Structure in 3D?

The traditional way to show the hierarchy of a traditional organization is with the CEO at the top and the workgroups/teams at the bottom. The Toyota way (as far as I know) is to reverse it, with the CEO at the bottom. I don’t think either shows the diagram as I’d really like, although the reversed model feels much better to me.

The reason is, the CEO role is a dual role of support and showing direction. In the support role, the role is certainly “at the bottom”, providing support for everyone else in their jobs. In the showing direction role, it is at the tip of the organization.

I have often wondered how I could show that duality effectively, both at the same time. Tonight, as I was going to sleep, an image came to me. I had to get up and do it (and then blog it) so that I don’t forget it.

LEARN MORE
Posted in Agile Success

Coaching a Team to Get Started

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, …

LEARN MORE
Posted in Agile Success, Scrum

The Importance of Two Things in Agile

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:

LEARN MORE
Posted in Agile, Agile Success, Scrum

UI Design in Scrum

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.

LEARN MORE
Posted in Agile Success, Organisations

Hull Speed for Systems

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.

LEARN MORE
Posted in Agile Success, Project Management

Story of Release Planning

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”.

LEARN MORE
Posted in Agile, Project Management

“We don’t want to pay for X”

It is surprising how many IT customers (some of which are actually expected to know a lot about software development) decline to pay for good development practices. Be it preventive QA, TDD, test automation or whatever, many customers assume those are additional costs to them (i.e. by not doing them, they would get their software faster and cheaper – and then they demand up-front planning!).

What if you went to a surgery and only wanted to pay for the room and the surgeon. Afer all, it’s the surgeon who makes the cut and fixes you. How would that go? What else is happening in a surgery theater? There are other medical professionals ensuring that whatever the surgeon needs is available (or is quickly retrieved). Some monitor patient’s vital signs and some control the anesthesia. What about the cleaning staff who take care that the hospital is clean? Sure, it’s entirely possible to make surgeries unnecessarily expensive, but there is certain level which has to be maintained (or else the patient pays the difference). I don’t even know, really, and I haven’t been watching those TV series to be better educated. And I don’t have to; I expect them to know what they are doing.

On the other hand, why do we software developers so often ask customer permission for those things? I don’t ask the staff at a restaurant on how they create my food (and instruct them on not using certain types of knives or grill/oven/whatever they choose to use). I stick strictly to my needs and desires (“and the steak – well done, please”), and trust them to know what they are doing. And if the outcome, or it’s cost-effectiveness compared to other restaurants, isn’t to my liking, I probably choose to use some other restaurant next time.

LEARN MORE
Posted in Agile, Agile Success, Organisations

“How Does Agile Make Me a Better Developer?”

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.

LEARN MORE
1 2 3