Photo
6 months ago
In the San Francisco Bay area, we have endured a few years of bridge closures and weird hazardous s-turns to replace the east span of the Emperor Norton* Bay Bridge. You may remember in the San Francisco earthquake of 1989, one section of this span collapsed because it was too rigid to give way to the shaking of the earth below. With the earthquake behind us, we all now accept that the earth will move again and the bridge we are using just won’t work.
When many of us think of project management, we picture ourselves executing a plan where a number of set tasks with quantifiable time estimates are bundled to become a perfect project plan; finishing on an ideal target date. It is all very 007 in it’s precision; at least in our intention. In reality,  projects planned in advance are like rigid structures. Like the east span of the bay bridge, they are not flexible. As soon as dates start slipping and changing, the entire project is at risk. Usually because too much importance has been put on when each section of the project starts and ends. Why do parts of the plan have to change? Are we really that bad at estimating?
If you are lucky, you are being encouraged by your company and your customers to build innovative features. They also expect them as quickly as possible. Using emerging technologies to craft sweet new services is rewarding,but those rewards come with a risk. 
Successfully making something out of nothing requires a lot of testing, trial, and error. With enough time, engineers and designers can do the prototyping necessary to know exactly how long the larger project will take to build. Prototyping however, is not valuable. It is extra time spent making things which are not noticed by the end user. 
The Time-box
Now that I have convinced you that the ground below our product team is constantly moving, lets find the best way to allow our project teams to create in a less rigid structure. 
A time-box is a goal set to make the most minimal useful version of a product or feature. This is known by agile teams as a sprint. A sprint is specifically defined as a couple of weeks where a team starts with a goal and estimates the tasks required to accomplish that goal. Sounds similar to one of those rigid project plans only there are some improvements:
The timespan of this plan is purposefully short. Estimates are hard to make in advance. You are better off estimating as short of a time ahead as possible.
We accept that some things will slip and there is no shame in that. In fact, getting rid of the guilt around having a task take longer than originally estimated will make it easy for people to be transparent and get the help they need when they need early.
It is important, in the beginning of a sprint, to agree on a reasonable scope. A team building a contact list may not have time in two weeks to build the entire product in a sprint, but starting from scratch they might be able to build a simple list of names. They can start adding other things in a later sprint but nothing is made which does not directly aim at the agreed goal for this sprint. In agile terms, this goal is a minimum viable product (MVP). Every two weeks we will have something to show the business and our assumptions get tested and shared more often. The larger group of designers and engineers get to see each others work more often.
Now we have data
Every day that a product team is working on an MVP, they are leaving behind useful data. The difference in estimated time left, relative to the when the sprint started. You can track this estimated time left averaged across the team. If this average time left is ever above or below the amount of days left in the sprint, you know it is time to take action to re-prioritize or get more help. Parts of the MVP might not get done as originally expected. You can prioritize the most important parts to be done at the end of the sprint and get creative to make things work towards the MVP goal. Some things might end up being done more cleverly and finish faster than originally estimated. By shortening the amount of time between estimates and deadline, you are giving the team more opportunities to adapt and your products will ship more often and more predictably.
Photo Credit: Bay Bridge Eastern Span by Kartik Ramanathan
*the “Emperor Norton Bay Bridge” is a disputed name. Proposed by people who are awesome.

In the San Francisco Bay area, we have endured a few years of bridge closures and weird hazardous s-turns to replace the east span of the Emperor Norton* Bay Bridge. You may remember in the San Francisco earthquake of 1989, one section of this span collapsed because it was too rigid to give way to the shaking of the earth below. With the earthquake behind us, we all now accept that the earth will move again and the bridge we are using just won’t work.

When many of us think of project management, we picture ourselves executing a plan where a number of set tasks with quantifiable time estimates are bundled to become a perfect project plan; finishing on an ideal target date. It is all very 007 in it’s precision; at least in our intention. In reality,  projects planned in advance are like rigid structures. Like the east span of the bay bridge, they are not flexible. As soon as dates start slipping and changing, the entire project is at risk. Usually because too much importance has been put on when each section of the project starts and ends. Why do parts of the plan have to change? Are we really that bad at estimating?

If you are lucky, you are being encouraged by your company and your customers to build innovative features. They also expect them as quickly as possible. Using emerging technologies to craft sweet new services is rewarding,but those rewards come with a risk. 

Successfully making something out of nothing requires a lot of testing, trial, and error. With enough time, engineers and designers can do the prototyping necessary to know exactly how long the larger project will take to build. Prototyping however, is not valuable. It is extra time spent making things which are not noticed by the end user. 

The Time-box

Now that I have convinced you that the ground below our product team is constantly moving, lets find the best way to allow our project teams to create in a less rigid structure. 

A time-box is a goal set to make the most minimal useful version of a product or feature. This is known by agile teams as a sprint. A sprint is specifically defined as a couple of weeks where a team starts with a goal and estimates the tasks required to accomplish that goal. Sounds similar to one of those rigid project plans only there are some improvements:

  • The timespan of this plan is purposefully short. Estimates are hard to make in advance. You are better off estimating as short of a time ahead as possible.
  • We accept that some things will slip and there is no shame in that. In fact, getting rid of the guilt around having a task take longer than originally estimated will make it easy for people to be transparent and get the help they need when they need early.

It is important, in the beginning of a sprint, to agree on a reasonable scope. A team building a contact list may not have time in two weeks to build the entire product in a sprint, but starting from scratch they might be able to build a simple list of names. They can start adding other things in a later sprint but nothing is made which does not directly aim at the agreed goal for this sprint. In agile terms, this goal is a minimum viable product (MVP). Every two weeks we will have something to show the business and our assumptions get tested and shared more often. The larger group of designers and engineers get to see each others work more often.

Now we have data

Every day that a product team is working on an MVP, they are leaving behind useful data. The difference in estimated time left, relative to the when the sprint started. You can track this estimated time left averaged across the team. If this average time left is ever above or below the amount of days left in the sprint, you know it is time to take action to re-prioritize or get more help. Parts of the MVP might not get done as originally expected. You can prioritize the most important parts to be done at the end of the sprint and get creative to make things work towards the MVP goal. Some things might end up being done more cleverly and finish faster than originally estimated. By shortening the amount of time between estimates and deadline, you are giving the team more opportunities to adapt and your products will ship more often and more predictably.


Photo Credit: Bay Bridge Eastern Span by Kartik Ramanathan

*the “Emperor Norton Bay Bridge” is a disputed name. Proposed by people who are awesome.

Loading...


Photo
8 months ago
thrillist
la
sf
http://www.thrillist.com/entertainment/san-francisco/why-la-is-totally-inferior-to-sf

http://www.thrillist.com/entertainment/los-angeles/why-la-beats-the-out-of-san-francisco

Thrillist plays both sides. 
I have never liked editorial on Thrillist. I subscribe because they happen to be really good at announcing when new restaurants in the city are opening. When ever I see something like this, I reconsider my subscription. Seriously, what is the point making posts like this?

http://www.thrillist.com/entertainment/san-francisco/why-la-is-totally-inferior-to-sf

http://www.thrillist.com/entertainment/los-angeles/why-la-beats-the-out-of-san-francisco

Thrillist plays both sides. 

I have never liked editorial on Thrillist. I subscribe because they happen to be really good at announcing when new restaurants in the city are opening. When ever I see something like this, I reconsider my subscription. Seriously, what is the point making posts like this?

Loading...


Human scale Agile

Canal at duskCanal at dusk by Jorge Lascar, on Flickr

One of my favorite books in the past few years is “Bicycle Diaries" by David Byrne of the Talking Heads. He shares stories of his experiences exploring cities around the world by bike. Obviously his music career brought him to cities large and small all over the world. Some of his favorite cities were ones he described as "human scale", a term used by architect Jan Gehl in his book "Cities for People “. Parts of San Francisco fall into this category. Byrne mentions cities like Valencia, California (a Los Angeles suburb) which he did not like because the town was too spread out with very few things close enough to be walkable. We like to live in places that are approachable. We like to live in places which give us space to interact and play, as well as do the practical things we need to do. Our work is no different. 

I have been working with one agile process or an other for over seven years. I have tried more than a few flavors of agile and more than a few tools meant to make the whole process easier to adopt. Funny thing is that there were only two times in the last seven years where agile has actually done what it set out to do; make my life easier. Both of these times I was on a team who was learning agile from scratch and was light on tools and process. Where it has not worked is where it had become something which tries to solve so many problems that the process became unapproachable for the people who use it every day. The process did not stay out of the way and make things organized, it became a big giant burden.

Sprawling agile

A lot of the time an Agile process is prescribed to us in full by a consultant or co-worker who’s job it is to dream up a process at scale. Their prescription is handed to us with tools and tenets and we are told it is all we need to succeed. In actuality, the tools didn’t fit our need exactly and there were parts of the process which just didn’t make sense to the team. We found ourselves doing things we didn’t need to do for the sake of the process. This is because scaling became the goal, not the daily needs of the people using it. Just like how a multi-level highway interchange improves the over-all flow of traffic through a city, it is far less effective and ascetically pleasing to locals trying to get from point a to point b.

As an example, an employer of mine decided to use an over-customized instance of the Bugzilla issue tracking system. At some point somebody thought that it would be great if each user story on the scrum board or kan ban board could also be a ticket in our developer ticketing system. This ticketing system also has hooks into our source control system so for each story we would be able to see all of the people assigned and even the commits which are being made. Since a lot of corporate dashboards and tools had already been built around Bugzilla, only the product teams would need to worry about the agile process and the rest of the company can hum along as usual. This sounds like a nice feature until you list the things it prevented. First, this function of the tool was obviously designed by developers. Though often the largest group in the team they are not the only ones. What this did was make the tool uninviting to product managers and designers (to be honest, developers weren’t crazy about the design either). Non-developers did not need to use bugzilla on a daily basis and these features were not added to it in the most elegant way. This tool also took a lot of the process of updating status and buried it several levels deep in a complicated web interface. I remember somebody on my team looking at this tool and saying, “god I hate this agile nonsense”.

The street and the square

Jan Gehl describes good cities being built around streets and squares. Streets are what people use to get places and squares are where people meet. This meets the goal of a city which is to give people a place to live, work, and come together. The goals of an agile process should be to instrument the team so that progress and workload can be measured from day to day. It should also help organize work and scope so that the most important things get done first.

The most successful agile processes I have seen keep the status as publicly visible as possible. A physical board with cards and online tools like Trello and Basecamp can all be used for this purpose. Choose the right one for your team and don’t be afraid to change them from sprint to sprint before deciding which one is right. Changing the tool people look at every day to some nicely designed alternative might actually be refreshing.

Think of the daily standup meeting as your square, it should be inviting for those who need to meet and interact but not get in the way of the function of getting where you need to go. The board is the street where you actually get from place to place every day. Keep traffic moving by removing roadblocks quickly. 

Loading...


Photo
11 months ago
Hey Tumblr. Welcome to Yahoo! -Flickr

Hey Tumblr. Welcome to Yahoo! -Flickr

Loading...



Post
1 year ago

Looking around this morning

Last night I stayed in Mill Valley and had to take the Golden Gate bus to work. So here I was, being driven across the golden gate bridge on a beautiful and bright morning. All of the beauty of a summer morning in the bay was around me. I felt so lucky. Then I noticed that nobody else on the bus was even looking up from their phones. I realized it must be because they take this trip every day. It is procedure and just an annoying delay for them. This is why I don’t think I would ever move far from the city for more space or prettier surroundings. After a while, people who like to work and socialize in the city will just stop appreciating the commute. For me, I appreciate it as an occasional adventure.

Loading...


Link
1 year ago

Loading...


Photo
2 years ago
Flickr :-) on Flickr.I was pretty sure this would be the case.

Flickr :-) on Flickr.

I was pretty sure this would be the case.

Loading...


Link
2 years ago

Loading...


Link
2 years ago

Loading...