This caught me once. We sized a project using the estimates as a range technique, and convinced management to use the upper numbers.

We then estimated our team velocity and again, used a conservative number around how fast we thought we could go.

Turns out we the project was simpler than we thought, and we ended up going faster than we thought we could go, and came in way ahead of where we thought we were going to be. Great news!

Now, I would way rather be on this side of a project (ahead of schedule and under budget) than the other. But when I look back and wondered why our numbers were so big I realized were conservative in our estimates twice:

• Once for the estimates.
• Once for the team velocity.

It’s not the end of the world. This was a really scary project, and our inception deck highlighted a lot of unknowns and first times for the company. There was also some fear and pressure to get things right. But I didn’t quite appreciate at the time that we were sizing conservatively twice here.

I don’t regret sizing it this way. Hindsight is always 20/20.

The more interesting question is now that we are aware of it, what will we do next time.

Happy planning!

You might do this if you inherit a project and you discover it’s bigger than the sponsors originally thought. Or after doing an inception deck and you discover some stuff that was originally missed.

The nice thing about this picture is it’s highly visible or colored. Red can mean new, or bigger than we thought. And the new number at the bottom quickly quantifies the difference and hopefully resets some expectations about what this project is going to take.

The following is a semi-transcript of the parts of the interview I found most interesting.

Culture of Facebook

Interviewer: Can you paint a picture of the culture of Facebook?

You would experience unfinished ceilings.
Concrete floors.
Desks everywhere – no offices. Not even Mark has an office.
And writing all over the walls.
And posters.

And you would see company slogans like:

- This journey is 1% finished.
- Move fast and break things.
- Fail harder

And facebook was born out of disruption and out of trying things and seeing what happened. And trying again and trying harder. And never being daunted by failure. Doesn’t mean we set out to fail. It means we are not afraid of it. And we are willing to keep taking risks.

And the entire environment is meant to keep you from feeling complacent, or comfortable or we’ve won. We never want to feel like we have won. We are pretty hungry. And someone could come and eat our lunch tomorrow. Because somebody could. And we never want to take it for granted. It’s the most humble successful company I have ever known. It may sound strange to say that facebook is a humble company. But it really is.

We don’t take our success for granted. We think our users are choosing to be there and could just as easily choose not to be there if we don’t deliver a great service.

The Facebook workspace

Interviewer: What sort of things did people think about in creating the facebook workspace?

It’s very deliberate. It’s absolutely deliberate. You can not just think of the culture you want and then create it. Culture arises from so many small things. A professor of mine once said:

Culture is the behaviors you reward and punish.

At the end of the day, people look around, and mimic the behaviors that reward them, and avoid the ones that punish.

But you’ve also got to try and show people the behaviors you want. And the space is one of those things that sneaks under your radar as not being important. But it truly is.

When you walk on those concrete floors you know we are not finished.
We are not luxurious.
We are not taking it for granted.
We’re scrappy.

The openspace is another huge one. You know that if you program you need focused attention. You need flow time. And you know that even small interruptions takes a long time to get back into the stream of things.

And so the idea of having programmers set out in open space at open desks with desks all around with walking and conversation and foot traffic … that’s controversial. For many years it was the ‘gold standard’ in silicon valley to have offices. Engineers were housed in offices.

When we took over the campuses from Sun we told the contracts to start knocking down every wall that wasn’t structural. Got as big an empty space in the office as we could and we would fill it in from there.

And why? Why was it so important to us that we would even consider sacrificing our productivity. Which is what we are doing having everyone out in these open spaces.

It’s because one of the key values of facebook is to be open.

It’s what the product is for. It’s fundamental to our DNA as a culture too. We expect every individual to be informed and in the know about what is going on empowers you to make good decisions. And so sort of set the expectation that everything is out in the open. Everybody is plugged in and aware of what is going on.

And then we put headphones in the vending machines and try to create private spaces that way. Give everybody a laptop and have pretty loose rules about working from home policy. So we do everything we can to mitigate the productivity impact of that openness. But every time we have to choose we choose openness.

Onboarding at Facebook

We call it boot camp.
It is a six week on boarding program.
And everybody goes into it.

As the VP of Engineering at VMWare, I had not written code for 7 years and I went to facebook and they said:

Here’s your desk.
Here’s your laptop.
Here’s your unix account.
And here’s five bugs that are assigned to you to fix.

And you spend your first 6 weeks at Facebook fixing bugs and implementing small features all over the site. And attending lectures and you have a boot camp mentor who is a full time software engineer who’s job is to help you get code reviews, to help you figure out what tasks to work on. And at the end of the six weeks they will help you find a team.

I give facebooks introduction to culture for bootcampers. And one of the many great things boot camp does is build empathy. Before you identify with a particular team you fix code. Even if you want in determined to do back end services, we will make you fix some UI bugs. We will make you fix an issue on mobile. No matter what you are going to do we are going to at least give you the tools to inspect, investigate, to know, about what is going on in other parts of the world.

It really sends the message we want to send which is – engineers are connected to one another. The facebook employees is just another subset of the social graph.

And so in boot camp you hook up your social graph. With your first setup of co-workers who then spread out to the 4 corners of engineering and give you connections in every part of the company.

But you know a little bit about something of everything.

And that’s an incredible asset for a new hire.

Interviewing at Facebook

Interviewer: So what are you looking for when you interview at Facebook? I know the standards are incredibly high. How important are technical skills as well as creativity and being about to work on teams.

The number one thing we are looking for in hiring a software engineer is ability to write code. And the ability to reason, be analytical, find mistakes and fix them quickly, and to analyze the running time so later on you can demonstrate you have the potential to solve hard systems issues.

If you are a new grad, that is the primary thing.

We also want to make sure you are not a jerk. Want people at facebook who are nice. ut we want people how have enthusiasm. Have fire in their belly. Aren’t going to take no for an answer. People who are not afraid. Going to attack making software with gusto.

The reason you see so much writing on the walls at facebook is we want people to write and share things the see – good or bad.

Pop open the hood.
The cement is never dry.
You can mess with it.
You can change it.

One thing that made engineers really successful at facebook is they had really good intuition for what would be a really good feature.

The difference between good intuition and just working iteratively is that the person with good intuition will get there in three hops while the person without will take x10 tries. So we started interviewing specifically for intuition. Its something that distinguishes good from great software engineers.

Mark Zuckerberg

Interviewer: How involved is Mark in decision very granular decision making?

Mark will definitely give you advice about pixels. Mark has organized the company so he can spend the build of his time on product and product strategy. He has basically set up his calendar so that for each day of the week theres a theme, and on day the theme might be mobile, platform, and then there will be a block of 4 hours and teams just rotate through and present stuff to him and talk through it with him and it’s amazing because he is probably the most gifted product thinker in the company, and maybe in the valley, maybe in the world (that’s probably stretching it) but definitely in our space.

He so like having a half an hour of his time is just amazing. You do have to parse the advice he is giving you and know whether he has is CEO hat on, designer hat, or Product Manager hat because he can operate at some many levels of abstraction.

So, yes. He will be very involved and he has structured his time to be involved. But he can only pay attention to so many things at a time to. So if he is not paying attention, he expects you to run forward while he is not looking.

Advice for grads

(31:31)

Interviewer: Imagine you are flashing back in time and you are a student back here at Stanford again. What advice do you wish someone had given you?

Ah man. That’s a hard question… Um…

I think that umm… you know you hear this all the time but be brave. Like you really don’t have any bad choices you. You can’t go wrong. Now is the time in your life to take a lot of risks.

I think that ahh.. I would have said… don’t worry about what you are going to be when you grow up. Just be. It will come and find you.

I feel like, you know, when I was in highschool and college so many people were like follow your passion, follow your dream and I was like: “How do I find my passion. How do I find my dream.”

No one had particularly good advice for what to do. To figure out what you are passionate about. So I would say:

It’s OK not to know.

Just keep trying things and you will find stuff that you are passionate about and excited about.

I would have told myself not be afraid to code for a living. I was afraid to code. I was afraid that other people would be better at it than me. I was afraid that I would be buried in detail and not get to be strategic. And I learned over time that writing code is one of the most strategic things you can do. And every time I meet a college grad who wants to skip being a software engineer and move straight into Product Management I am like uh… you learn so much from writing code that the devil is truly in the details. Embrace it. Relish it. You may not end up doing it forever but every minute you spend coding will make you 1000x better at being a manager or product manager or anything else. Even if you decide you want to do something else, your time writing code will make you better for it. If you want any career in software. Any career.

This was a great interview. I highly recommend you download and listen to the audio.

Cheers – Jonathan

It’s target at people who need to build Agile plans, and are wondering how Agile estimation works.

This is part of a new Agile video series I am starting targeted at people who are brand new to Agile (i.e. your boss, your co-workers, your mom/dad, or anyone you just want to know and understand how you work).

If you have any suggestions on topics, things you would like to see, or how to make these better I would love to here them.

You can reach me here.

Hope you enjoy this latest video. Here are some of the slides from the slidedeck.

Agile Estimation

The 1 Pager

On this one I am trying to communicate all the important stuff on a single page.

At the top I’ve got how we are doing for time, money and scope. To the right I put any headlines or issues. I’ve got a risk section showing the problems we are facing and how we are addressing. Then the velocity and projected date on the right.

So at a glance I should be able to see whether we are in trouble (via the red, yellow, green stop light) and how we are trending on time, money, and scope.

The Burndown

Ah. My favorite graph – the burndown. The burndown never lies. It’s the story of your project. It shows you how you are trending. It can show where you need to be. It shows you changes in scope. It also tells you when you are in trouble.

Changes in Scope

Every project is different. On some scope management is easy and built around trust. On others you have to watch it like a hawk.

If I think scope management is going to be an issue on a project, I will make any changes to scope crystal clear with a slide like this:

Others

Every company is different. And sometimes I will create dedicated presentations if there is a really important message I need to deliver. But if you basically make everything visible, and ask yourself:

What would I like to see if it was my project?

you’ll probably come close to what your sponsor wants to see to.

I had to do that recently. I suspected the project was bigger than it looked (thankfully we hadn’t started yet). I did an inception deck with the team and all the sponsors, and lo and behold – it was bigger than anyone expected.

I had to deliver some bad news.

Here is a sanitized form of the letter where I explained to the sponsor why the numbers were what they were, and why the team didn’t feel like it would be safe to go with the lower more aggressive numbers.

Hi Mr. Smith,

After sitting down with the team, and going over the estimates, the team’s best guess is that XXX Project is in the neighborhood of:

325 – 490 days with a strong feeling towards the higher number.

I asked the team if there were areas we could simplify, cut back on, or reduce size in, and was cautioned against the lowering the numbers.

The fact that it is:
- A cross cutting project (lots of stakeholders)
- Distributed team (x3 cities)
- There is no in-house expertise
- Many first times (never done x, y, or z, etc)

tilts the team towards believing this project be slow, with a good chance of surprises along the way.
It’s big. And the team feels there is little risk in finishing early ahead of schedule.

Let me know if you’d like to get together to look at options on how best to present this number and how we should proceed with the budget and schedule.

Jonathan

Actual vs Original Estimate

Unpacking it

There’s a lot going on here (and a lot of missing context and background behind the project). Don’t worry about that for now. Here is what I wanted to share:

1. Estimates as a range.

Even though the original estimates were in days, I like showing stakeholders than when we first give estimates, we don’t really know upfront how long things are going to take (see Cone of Uncertainty).

By showing the estimates as a range, I convey that sense of uncertainty, and it’s a nice lead into Agile planning where I explain how I will soon be able to tell him the exact date.

2. Why the higher number.

This project was about as risky as they get. It was cross company, brand new work with no inhouse expertise, spread across three cities. Nothing in this project was going to go fast, and I needed to alleviate the fear that by some chance the team might finish early and not need the extra funding.

We owe it to our sponsors to be as transparent and visible with regards to where these guesses come from. So I always try to frame it in ways they understand.

3. Actuals vs Estimate.

This project missed a lot of important stuff first time round. That’s why those boxes are red. They represent new stuff (or scope). I like highlighting this and making it really visible, so people can see and feel the size difference. On some ThoughtWorks projects we would use bubbles to actually represent the size to make it feel even more visceral. But you get the point.

That’s it. I just wanted to share this letter/email. I find when writing these it’s best to be clear, simple, and straight to the point.

It’s never fun. But it needs to be done. Bad news early is the Agile way and the sooner you let your sponsor know their project is in trouble the better.

Good luck!

Visual workspaces are great for communicating a lot information fast. While Story walls are popular for showing the state of an iteration, don’t let that limit what you show. Create and visualize anything important to you and your team.

Here what we are radiating from the current project I am working on.

Release Schedule

This wall shows all the days of the month and what we plan on releasing when. It’s handy for scheduling releases, showing important dates when doing daily standups, and just giving everyone a quick update on any important release dates. Great for coordinating and getting everyone on the same page.

Inception Deck

The inception deck gives people an overview of the project at a glance. We don’t always start with full teams, and it’s handy to be able to walk someone over to the wall, and give them an overview of the project at a glance.

Delivering Value

This wall may seem a bit defensive, but if you want to show what you and your team have done, create a card for every major milestone or release and make it visible.

Here we are proudly showing that we’ve done a major release every month, while working closely with the support team to crush about x15 bugs per month. Ya!

This morning while listening to the Stanford ECorner Podcast, I heard of an alternative form of retrospective taught at Stanford’s Institute of Design.

Instead of getting together at the end of a sprint and asking:

• what are we doing well
• what could we be doing better

The gets together at the end of the day, sits in a circle, and everyone gets a chance to say anything on their mind. The only requirement is the sentence must start with:

• I like …
• I wish …
• I wonder …

This seems like a nice, open, gently way to let people vent, congratulate, speculate, and release whatever is on their mind.

Stanford School of Design (dschool) positions this as more of a feedback tool for getting feedback on designs, but I think it’s super useful and could be applied in just about any context.

Check out this one pager to learn more about how it’s used in design.

I’ve just posted some thoughts here on how to deal with it.

.bash_profile

export PATH=$PATH:~/scripts
alias nutshell='cd /Users/jrasmusson/Developer/agilenutshell'
alias reduce='sips --resampleWidth 200 a.png --out b.png'
alias ios='cd /Users/jrasmusson/Developer/iosbyexample'
alias gs='git status'
alias test='bundle exec rspec spec'

My scripts directory:

ci.sh easy git checkin

!/bin/bash
echo "Checking in..." 

git add .

if [ -z "$1" ]
then
 git commit -a -m "cleanup"
else
 git commit -a -m "$1"
fi

git push
echo "Done!"

reset.sh resets my git repository

!/bin/bash
echo "Reseting git repository"
git reset --hard HEAD^
git clean -f
git merge origin/master