Coming out of the closet - the life and adventure of a traditional project manager turned Agilist

I’m coming out of the closet today. No, not that closet. Another closet, the tabu closet in the Agile community. Yes, I was (and to a point still am) a control freak, traditional, command and control project manager. Yes, that’s right you read it correctly. Here’s why this is important: in 2003 when I first started to consider Agile in any shape or form I was a strong believer of the Church of Order. I did all the rites of passage, I did my Gantt charts, my PERT charts, my EVM-charts and, of course, my certification.

I was certified Project Manager by IPMA, the European cousin of PMI.

I too was a control freak, order junkie, command and control project manager. And I've been clean for 9 years and 154 days.

Why did I turn to Agile? No, it wasn’t because I was a failed project manager, just ask anyone who worked with me then. It was the opposite reason. I was a very successful project manager, and that success made me believe I was right. That I had the recipe. After all, I had been successful for many years already at that point.

I was so convinced I was right, that I decided to run our first Agile project. A pilot project that was designed to test Agile - to show how Agile fails miserably (I thought, at that time). So I decided to do the project by the book. I read the book and went to work.

I was so convinced I was right that I wanted to prove Agile was wrong. Turned out, I was wrong.

The project was a success... I swear, I did not see that coming! After that project I could never look back. I found - NO! - I experienced a better way to develop software that spoiled me forever. I could no longer look back to my past as a traditional project manager and continue to believe the things I believed then. I saw a new land, and I knew I was meant to continue my journey in that land. Agile was my new land.

Many of you have probably experienced a similar journey. Maybe it was with Test-Driven Development, or maybe it was with Acceptance Testing, or even Lean Startup. All these methods have one thing in common: they represent a change in context for software development. This means: they fundamentally change the assumptions on which the previous methods were based. They were, in our little software development world a paradigm shift.

Test-driven development, acceptance testing, lean startup are methods that fundamentally change the assumptions on which the previous software development methods were based.

NoEstimates is just another approach that challenges basic assumptions of how we work in software development. It wasn’t the first, it will not be the last, but it is a paradigm shift. I know this because I’ve used traditional, Agile with estimation, and Agile with #NoEstimates approaches to project management and software delivery.

A world premier?

That’s why me and Woody Zuill will be hosting the first ever (unless someone jumps the gun ;) #NoEstimates public workshop in the world. It will happen in Finland, of course, because that’s the country most likely to change the world of software development. A country of only five million people yet with a huge track record of innovation: The first ever mobile phone throwing world championship was created in Finland. The first ever wife-carrying world championship was created in Finland. The first ever swamp football championship was created in Finland. And my favourite: the Air Guitar World Championship is hosted in Finland.

#NoEstimates being such an exotic approach to software development it must, of course, have its first world-premier workshop in Finland as well! Me and Woody Zuill (his blog) will host a workshop on #NoEstimates on the week of October 20th in Helsinki. So whether you love it, or hate it you can meet us both in Helsinki!

In this workshop will cover topics such as:

• Decision making frameworks for projects that do not require estimates.
• Investment models for software projects that do not require estimates.
• Project management (risk management, scope management, progress reporting, etc.) approaches that do not require estimates.
• We will give you the tools and arguments you need to prove the value of #NoEstimates to your boss, and how to get started applying it right away.
• We will discuss where we see #NoEstimates going and what are the likely changes to software development that will come next. This is the future delivered to you!

Which of these topics interest you the most? What topics would you like us to cover in the workshop. Tell us now and you have a chance to affect the topics we will cover.

Contact us at vasco.duarte@oikosofy.com and tell us. We will reply to all emails, even flame bombs! :)

You can receive exclusive content (not available on the blog) on the topic of #NoEstimates, just subscribe to the #NoEstimates mailing list below. As a bonus you will get my #NoEstimates whitepaper, where I review the background and reasons for using #NoEstimates

Subscribe to our mailing list

* indicates required

Email Address *

First Name

Last Name

Picture credit: John Hammink, follow him on twitter

The most valuable question for your software project

Every time a software project is started, a dance starts: the dance of project approval. Decision makers and project delivery team take different positions at a table, some ask questions, others do their best to respond, given that these questions are typically about the future. Some of the questions are so much into the future that it would be foolish to pretend we know the answer. Yet we do.

This was the main lesson I learned in my life as a project manager: you have to learn how to dance.

How to dance...

In the dance-like meetings there are 3 types of people:

• A) Those that pretend to know the future
• B) Those that know they can't know the future
• C) And those that don't want to know the future

The question below is only valid for the people in category B). The other two categories are beyond help from me or anyone else.

What is the likelihood this project will fail?

When a project starts, the best question anyone can ask about the project is this:
The most important question: What is the likelihood this project will fail? Why is this question important?

• First, if you don't have an answer to this question you are either in the first or third category of those listed above, and there's nothing I (or anyone else) can do to help you.
• Second, by discussing the possibility of failure we are actively looking for possible causes of problems for the project (rule 1 of risk management).
• Third, having an actual conversation about the failure probability of a project will give you an indication of the "value at risk" for the project.

For example: let's say the project budget is about 100K dollar, and to make it a worthwhile investment we would need to make it between 120K and 90K in total cost (i.e. if it is likely it will cost more than 120K you should not do it). If the answer to the most important question is: 50/50, then you know that the project is not worth doing. It has very little chance of delivering the necessary value to justify it's existence, in fact: it is likely it will be above 100K and up to as much as 200K in cost.
However, if the answer is that we are 80% confident we will deliver the project on timecost, then the project is worth pursuing (although with some strict scope control in place) because the expected worst case scenario would be a total cost of 120K dollars (the 20% margin implicit in the confidence above). In practice an 80% confidence means you expect the project to cost up to 120K (100K + 20%) in the *worst* case.

In a later post I'll explain how we can answer this most important question using the #NoEstimates approach. For now, let me know what you think of the question and the concept of "value at risk" above.

Definition of Value-at-risk [PDF]: "value-at-risk summarizes the expected maximum loss (or worst loss) over a target horizon within a given confidence interval"

Note: A special thanks to @galleman for the idea of the 3 categories of people from which I derived the 3 categories I present in this post.

Photo credit: Steven Depolo @ flick

Waterfall in a Scrum world, yes it is possible. See how below

Can you do waterfall at the same time you are doing Scrum? Let's explore the subject a bit...

We all know what problems there are with waterfall and long term plans that are not changed. We start executing the plans and see that things don't really work out as we thought but we stick to the original plan anyway just delaying the project but trying to deliver the same scope we agreed to.

This has a knock-on effect on the subsequent projects (there's never only one project), and other projects get delayed, but not changed because that would require changing the plans (portfolio, roadmap, strategy you name it!) and the chain goes on, ad infinitum...

The fact is that any plan that is not changed based on what we learn during the project will have the same effect that a waterfall plan has: delay later projects and provide no visibility when the projects will be completed.

So, here's the problem. Many teams and companies are doing Scrum. They have their Sprints, their Sprint plans and they change the overall scope to meet the deadlines. They may even be releasing those projects on time. But there's something more macabre at play here. Despite being able to release projects on time these teams and companies are still riddled with problems: overtime, being late in some (but not all) projects, not being able to react fast to customer requests such as support requests, fix requests, etc.

How come? What's the problem? Well, the fact is that for Scrum (or any other Agile method) to work you need to really have plans that change. It is not enough to have team-level or single-project plans that change, you need to have the whole R&D, the whole company understand that portfolio plans, roadmaps also need to change!

Imagine this. Your team is working on one project and delivering on time, but, without your knowledge, someone in the company has agreed a roadmap that actually requires that your team start working on another project before you finish the current one. Obviously they never thought to ask you your opinion and your project manager even agreed to it, albeit many months ago.
The consequence: your resource plans are now fixed! Your company booked their R&D 100% without any room for changes (after all, we don't want any people twiddling their thumbs do we?).

Since the project that you are working on changes (as it should), you actually get to work on some features until the last sprint, which in practice means that the project that was supposed to start, cannot. Your roadmap just changed, but the VP of R&D does not accept it. "Just push harder" he says. Your team continues to work overtime and you can actually deliver that "extra" project almost on time. But as it happens, there were other projects you were supposed to be working on at that time, and they could not be started. So the roadmap was again affected. And this negative spiral has no end unless the whole organization acknowledges that company-level plans need to change as much as team-level plans do!

See, you can do waterfall at the portfolio level while you are doing scrum at the team level.

Be at least as careful with your commitments to the long term as you are your Sprint commitments!

Why specialization in Software development is bad for business

Specialization in software development hurts our business! I'm not talking about the kind of specialization that leads to spend some more time in one area than in others. I'm talking about the specialization that leads us to have Database Administrators (DBA) or Database Designers (DBD) or Kernel programmers that don't do anything else!

Take the example of a DBA. The thought that a DBA would not need to know about file systems is simply ludicrous. A DBA cannot do a very good job if he only knows about SQL, stored procedures and other DB characteristics. The competent DBA will need to know about file systems where the data is ultimately stored, about the Operating System which will ultimately ensure that the data is safely kept in memory or flushed to disk, about data structures and algorithms that will inform his decisions on how to configure the DB engine, etc.

The list goes on and on. This is not to say that we don't need people with particular strengths in some areas (called "generalizing specialists"). But this means that specialization as is practiced by many software organizations around the world (banks, finance, large consulting companies, large SW companies, etc.) is a myth and in the example of our DBA completely counter-productive to the point that it actively hurts our business (assuming software can have an impact in the business).

It's illuminating when you look at which software organizations actually implement and defend this specialization strategy: organizations that don't understand software and that it is a science/art in itself. There organizations tend to be large (even if some small ones do the same mistake) and run by people that don't have a background in software development themselves.

Specialization is for insects! If you develop software be aware that you need to understand a lot more then the narrow field in which you have "specialized".

Here's a challenge for you: what's the most dysfunctional specialization story you've encountered in your professional life? Care to share it? Writer your story in the comments below.

Project smells

Jason suggests that projects, in his experience, face similar problems (I'm assuming he is talking about all projects, including Agile projects).

What is your experience? What are the mistakes that happen all the time as Jason suggests?

In the waterfall world one of my favorites that happened all the time was: requirements change constantly. Can you imagine a world where requirements changes were a bad thing? I can't. I guess i've been exposed to Agile for too long (wink, wink).