Trust, Courage, and Greatness

“So – you’re a ScrumMaster?” I’ve been often asked. “Maybe, but in the end it doesn’t matter”, I replied. Right now I’ve got an even more fancy role title in my organization: “Lean Delivery Agent”.

I don’t care.

I’m in the software business since more than ten years. And until now it was quite a ride. Back in 2008 I started with Scrum, implementing it in a SME in Berlin, when I was building up there development department with a team of eight developers and a Product Owner. Before and after this conscious entry into my “Agile career” I met quite some companies, and every had its own, unique culture. Some were great, some were painful – but I don’t regret anything. Because the awesome thing is: I learned from every culture. What made the great things great, why did failures happen, how good went similar stuff in different organizations.

For me it turned out that three things are crucial in the end:

1. Trust

It’s never about the process – it’s about trust. The less people trust each other, the bigger the demand for processes is. But every process is kind of waste. It doesn’t deliver value to the customer. The customer doesn’t care how sophisticated your processes are, how great your financial controlling works, how well documented your roles and responsibilities are in the company. He cares for your products and services, for their quality and how they ease his live. A trustful culture can much more focus on value than a culture based on control. Trust also fosters autonomy, mastery, and purpose, the three main drivers of human motivation, as Dan Pink wrapped it up.

2. Courage

To move ahead you need to break the rules. You have to find out which make sense and which don’t, and why. To do so you need courage. When there is no courage there will be no improvement, no innovation. If everybody is careful not to change, to break something, the organization will stick in the status quo. But the environment changes, regardless of the organization. The market changes, the customer changes, the technology changes, the people change. So also an organization has to change. But since there is no guaranteed road to success (or even survival) you need to find out what may work and learn from failure on your own. And therefore you need courage. The more courageous people you have, who are not afraid of sharing their opinions, challenging decisions, and just doing things a new way to prove their ideas, the higher the possibility for the success and survival of an organization is.

And again trust is helpful. When there is no trust in that people do their best, and if people have to fear failures, it will torpedo courage.

3. Greatness

Go for greatness. As person as well as as an organization. Try to be good in everything you do. Try to learn, to always improve. Don’t be just mediocre. Don’t hire just good people. Hire great people! Don’t just provide the stuff your competitors have. Provide the better! Don’t just give your employees a job. Give them purpose! (And by the way: just making more money or please your shareholders is not a purpose, as little as just keeping your job). Don’t just do your job. Do the best job you can! Don’t just run a company. Create the greatest workplace ever! The more you accept mediocrity the more you will loose the ability to grow and evolve.

If you are unable to be great in the things you are doing, then maybe those are the wrong things for you. And what satisfaction will you find in the end for doing wrong stuff for long time?

So that are the things I care for in my job, I try to seed and grow, whatever my title may be: trust, courage, and greatness.

On Estimation and Planning: Who Cares?

Basically agile estimation and planning is pretty simple. The Product Owner prepares a backlog full of user stories, the developers estimate them, after some sprints the team’s velocity is known – et voilà – you are able to come up with some release plan. So you can either say when a milestone probably will be done – or what probably can be achieved until some fixed date.

But isn’t that to far away from practice? Isn’t it more likely that the Product Owner has detailed stories only for the next one or two sprints, and after that things become somewhat nebulous, more epics then stories?

OK – but what does that mean? When things get nebulous, or big, or even both, the estimation will be more and more inaccurate. Humans are pretty bad in estimating big things. Thus also the release plan              becomes more and more inaccurate. And the risk for everybody who relies somehow on the plan gets bigger and bigger.

So the question is: who cares for your release plan, and any estimated dates? If nobody cares you can basically do what you want, and have your user stories ready for development just in time. On the other hand: is it good if nobody cares? If nobody asks for your product – why do you want to build it? Maybe you are on a completely wrong track?

In contrast if people ask for a pretty good estimation for a release date that means a lot more work. Because in this case you will need a rather complete backlog, with not just epics but user stories up to the milestone. And you need to think about dependency management and technical pitfalls sooner than later. So it should be clear if the more of work for upfront estimation is really needed, if the date asked for is really so important. Because your product won’t be done earlier if you estimate more and more accurately.

In the end the trick is to find a feasible balance between a lot of uncertainty and a lot of upfront work. To plan as much as is needed but as less as possible. Much more important is to regularly align plan and reality by adjusting your estimation based on new insights, like a changed velocity, and to tell your stakeholders about what the new facts mean to the plan.

Agile like the Death Star

Today Daniel and I gave our talk about Agile Software Development to a group of about 10 highly interested people from our sales department. Our goal was to start a discussion about what Agile principles mean to our organization, where we currently stand in terms of Agility, and how we can drive the mindset further all together. It was a really open and amazing event which clearly will lead to some follow-ups.

And: I heard a pretty funny metaphor about agility. In the beginning we asked “So who of you know what Agile development is about?” One of our sales guys answered “Well, it is the thing with the Death Star, isn’t it? They didn’t finish it before they used it the first time, but the weapons and engines were working, and they carried on building all the time.”

And you know what? I think this guy was right because there are even more indications for an Agile mindset:

  • Nearly all employees of the Empire where keen to satisfy their customer (the Imperator) by early and continous delivery of value.
  • The empire accepted changes to its planes quite unexcited and dealt flexible with it.
  • The people who ordered weapons and stuff were pretty close to the development and gave their feedback.
  • All people seemed to be really motivated (thought the reasons may have been disputable in some cases).
  • Communication was often face-to-face, even with distributed teams.
  • Success was measured by results, not plans or documentation.
  • Technical excellence was self-evident.
  • The protagonists reflected on how they are doing and how they can improve.

But an interesting question remains: does an Agile mindset rely on an ethic purpose?