Agile is a mindset. It is more important how you think than what you do, because your thinking drives your actions and behaviors. Repeating motions without understanding is not very useful, and tends to lead to disappointment.

That said, there are also certain behaviors that support the beliefs we have, so ultimately there should be an alignment between the way we think and the way we behave.

There are different ways in which the mindset (and some of the behaviors) have been captured, in the hopes of making the ideas more easy to understand and express. We do, of course, have the Agile manifesto. We also have Lean Software Development with its principles. Two more recent takes are the Modern Agile and Heart of Agile, both of which try to recapture the essence in four main ideas.

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.

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.

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.

A colleague asked me very recently, regarding Nokia being in the headlines with Elop’s recent internal memo, what has, in my opinion, Nokia done right and wrong over these years. After all, they achieved a massively dominant position in mobile phones and are now losing it all.

I think they did a lot of things right in the late 1990’s and very early 2000’s.

They were the first ones to focus on customer experience. Even if the processes weren’t very refined compared to best practices today, Nokia phones were considered to be the easiest to use for almost a decade (until iPhone hit the market).

I’ve come to realize recently that there are two types of Scrum. One is goal-driven, the other is story-driven.

The Story-Driven Scrum

This approach seeks to identify and prioritize user stories (or any requirements) small enough to fit in the iterations. In these Sprints, the team commits to delivering the selected set of stories. These stories can be estimated and the amount of results can be measured for longer term planning. This approach works best when enough design work can be done in advance to eliminate most significant elements of uncertainty prior to committing to work in a Sprint. I could call this type the Mike Cohn Scrum as this approach is excellently defined in his Agile Estimation and Planning book.

I can’t sleep tonight. My mind is racing. I’m getting to what I really want to do.

I’ve been training people in Agile methods and Scrum for quite a few years now. I’ve seen change happen, I’ve seen people regaining enjoyment at their work, I’ve seen people crank out almost error free code faster than ever before, I’ve seen people conquer problems that seem quite impossible. But none of that is enough.

It is not enough because none of that is creating a sustainable change in their environment. The organizations where these things happen still keep promoting a different environment, an environment where old formalities of management reign, where command-and-control and task-oriented mindset reduces people to doing their work instead of solving problems in collaboration with others. These organizations rule the business scene of today.

Systemation writes in their blog about poor project management being the biggest project risk. I agree. Yet I think the blog fails to recognize that the project manager centred and plan driven approach itself is also a major risk for project success. Just like typical waterfall projects (or ones with long increments) omit the most cost effective risk mitigation strategy of incremental development, traditional project management typically omits building collective commitment as a source for getting visibility and low level actions to project risks.

But I won’t belabor the Agile/Traditional divide. What I want to look at is lack of good project leadership as a risk for Agile projects. Given that I agree on the risk, let’s look at corresponding five steps to improve Agile project leadership (note – leadership, not management).

1. All Scrum team members (I’m using the term in the broad sense as that includes the product owner, ScrumMaster and all the development team members) must receive training in the fundamentals. While some of that training can be given in typical training environment (CSM/CSPO classes, etc.), some is most effectively given in a coaching format within the project itself. Too many projects and organization omit the last item, but it actually happens to be the most cost efficient form of training/coaching.
2. The organization and people working in it must agree on some standard framework for project leadership and management. One size doesn’t fit everyone, so the framework must allow appropriate project level modifications. There should be sufficient internal mentoring to ensure appropriate following of the agreed framework and to ensure all project members have sufficient skills to use it effectively. Also there should be a mechanism by which the project organization routinely reflects on the framework and adapts it to changing business environment and needs.
3. All project members should have access to the tools needed to manage the work and use the framework effectively. Note that I didn’t say “software tools”. Many most effective project management tools aren’t software based. But when the organization decides to use a tool, it must support the agreed process (and not the other way around – the organization adapts to the tool).
4. Projects should strive to deliver fully working functionality in every iteration. The ruthless visibility this provides into real progress is the basis for estimation and tracking.
5. The organization must support the projects in their leadership. The teams must be given appropriate time and resources to do their work right and must not be requested to do shortcuts or disregard good practices. Product owners must have support for their long-term planning and vision setting. ScrumMasters need to be supported in their activities for improving project leadership and removing obstacles from getting work done. This is MUCH more involved than most organizations think. It really means understanding what Agile is, what it takes to do it right, and what is needed from the management itself.

Just like the five actions the Systemation CEO believed will improve project management, I believe that the above five actions will improve Agile project leadership. However, action 5 needs significant clarification in Agile context.