Current Articles | RSS Feed RSS Feed

Lava Walk: Taking a Team Down a Treacherous Road

Posted by Michael Chletsos on Wed, Mar 27, 2013

When I first took on the role of CTO at Assembla, I researched Team Building and came upon the dreaded Corporate Retreat with a lava walk or lava flow exercise.  It's a team building exercise, that quite frankly seems boring. Well I currently reside in Hawaii and we have a totally different take on the Lava Walk.  

assembla lava

The Team

Here you see Ben Potts (DevOps extraordinaire), myself, and Nadia Romano (CX Engineer afficionado). These two along with another (Ramsey, not pictured, he snapped the photo) followed me into a lava field for a grueling 13 hour hike, it was meant to be only 2 hours. But once out in that field, the lava beckons you to continue on until you find it.

The Treacherous Road

The terrain was tough. Lava once hardened is not like walking along pavement, so much as walking along pavement with broken bottles littered across it after an earthquake. You have to be careful where you step to say the least. Everything around you is black lava. The air is full of smoke and sulphur smells at times. And of course, we had limited water supplies, flashlights, and mosty appropriate clothing for the terrain (good hiking shoes, long pants, and an additional layer).

wasteland walk

Fortunately we also chose to walk on a nearly Full Moon - which allowed us to not use the flashlights (as the batteries on our smartphones (the flashlight apps are great) were dying) and walk in the pale light of the moon, it was fantastic. 

We made it to the lava fountains after 4 hours or so of walking, it was sheer magnificence. To watch lava ooze down the side of a fountain is a treat to see.

The video does it no justice, smartphones just can't capture the actual image that is unfolding 3 feet (~1 meter) in front of your face.

Lessons Learned

An actual Lava Walk has many lessons to be learned hidden within it. Each person has a role to play:

  • Leader, the one who sets the path and keeps the group moving
  • Enthusiast, the one who remains positive and keeps the group motivated
  • Stalwart, the one who continues on beyond all obstacles and triumphs
  • Supporter, the one who helps others in their time of need

The role is not so much chosen as it is placed upon you. Sometimes the roles shift from person to person. I learned about these people while walking through this barren wasteland and I am sure they learned about me.  Ben is always positive and moving forward. He wants to see things and make things happen. Nadia will accomplish any task no matter how hard.  She is not afraid of an obstacle in her way. I learned that I am stubborn and when I should push people to move faster or harder and when I should allow them to move at their own pace.   

All in all it was a great experience and I hope that I continue doing other Team Building exercises in the real world, maybe not so extreme next time. I do not encourage you to make a real Lava Walk as part of your corporate exercises. This time it ended well, only some bruised ankles and sore feet. I do have to apologize to Ben's wife for keeping him out so late and worrying her half to death:

Shannon - I sincerely apologize, it was all my fault that Ben did not come back until the morning. Sorry.

sunrise over lava

We did get to see a beautiful sunrise in the morning as we left the fields. It was a worthwhile adventure.

Would I do it again?

Absolutely, I would, however not all people want to trudge through lava fields, perhaps just a Magic the Gathering Session would be a good Team Building exercise next time.

magic gathering excitementPeople do love that game. He sure does.

4 Comments Click here to read comments

Code Management versus Project Management

Posted by Andy Singleton on Tue, Apr 05, 2011

What if we could get rid of software project management? On a big project we would save millions of dollars and a lot of boring meetings. As noted in Statistical Proof that Project Managers are Useless, project management is a difficult and thankless job. It's a task ripe for automation

PROJECT MANAGEMENT: We need project managers because we have project plans. The plan describes how multiple people contribute work to a coherent whole. Project managers coordinate this work by reminding contributors about the plan.

VERSUS CODE MANAGEMENT: On a software project, there also a coordination process running around code. As people write code, they have a process to contribute into a shared release. I reviewed some of the ways that we do that in the previous article on Four ways to manage code, simplify projects. The workflow for contributing, reviewing, and accepting code is a different way to assemble the work into a coherent whole.

In the project management case, you assemble the work of multiple people IN ADVANCE. You plan a set of tasks that fit together. In the code acceptance case, you do the work AT THE END, when you decide what code to accept. So, you do the work at different times, but you can get a similar result. The processes can be substitutes for each other.

I can't say which is more effective in general. Most projects do both. Both processes can deliver equivalent results. They both require work. However, I can think of some reasons that you might prefer to work with code.

1) It's sometimes easier to control code than people. Managers have a tough time herding smart programmers. Code, on the other hand, doesn't go anywhere when you run out of Jolt Cola.

2) Project management doesn't scale. The success of project plans declines dramatically with the size of the project. The problem is that big projects have a hierarchical structure with some sort of a boss who makes the plan, and that boss doesn't know everything, and the plan is always wrong in some way. On the other hand, code management can scale. You can imagine a project, maybe with Gerrit, which has hundreds of contributors throwing in code. You could in principle do this without hierarchy, scrums, and scrum of scrums. They might not all be going in the right direction, but at least they are figuring out the right thing to do at an individual level. So, you can see how this thought fits into the broader discussion of project scaling.

1 Comments Click here to read comments

March 30 Release: New Ticket views, Cardwall, Code commenting

Posted by Sergio Romano on Wed, Mar 30, 2011

Tickets (representing issues and tasks) are the core of our workflow.  Today's release includes a big upgrade to the way people see tickets, and an all-new cardwall / scrum board / Kanban board.  These are fun ajax features that you can shape to fit your team.

The Tickets menu features three views: the default Ticket List view, the new Cardwall view, and the Planner view.

Sidebar reporting: The Ticket List now has a sidebar to create and edit reports.  It's faster and more fun than the old "Filters" page.  Plus, it allows you to search text in the selected tickets.  Any user can list and search, and if are an owner, you can save reports for the team.

sidebars resized 600

Cardwall: This is a clean implementation of a cardwall / taskboard / kanban board.  Set your milestone on top, and see what your team is working on.  The columns are defined  with the new custom statuses.

cardwall resized 600


Agile Planner:  We improved speed and reliability and added a popup view of the complete ticket history.  We found that many users sort tickets into a particular order, so the default order is now "manual".

planner resized 600


Pick your view:  What do you want your team to work on?  If you are using a Kanban process, or you like working from a Scrum board, you can set "Cardwall" as the default landing page for tickets.  You can select "Planner", if you want users to land on your sorted list.  Or, you can stay with the default "Ticket List" view, use the sidebar to configure the exact report that you want your team to work from, and set that report as the default.  Look in the Tickets tab, settings subtab, under "Ticket View Settings".

ticket view settings

Inline comments on changesets

When we released on-demand Gerrit last month, we got requests for a simpler code review system that would be similar to Rietveld.  So, in this release you can write comments directly onto a changeet.  I works for subversion, git and mercurial.

As you read a changeset, click a line number to type a comment.  After you write your comments, "submit" to the comment thread at the bottom.  Or, write your overall impressions into the comment thread.  The comment will appear in the activity stream where the changeset author and other developers can see it and respond to it.

code comment resized 600


Portfolio volume discounts and annual packages

We simplified the packaging for Portfolio customers.  You can now get fixed price packages, volume discounts, and annual plans, with two months free.  This provides savings for our best customers, and makes the packages easier to arrange with your accounting person.

In each release we improve Tickets in ways that many users do not notice.  This release lets the light shine, with improvements that every user will appreciate.  We have more on the roadmap.  We also made more than 100 small improvements in other areas.  Thanks for your feedback.

11 Comments Click here to read comments

Secrets of rapid release cycles, from the Google Chrome team

Posted by Andy Singleton on Wed, Jan 12, 2011

The Google Chrome team has released a blog post and a presentation that describes how their process can deliver a new version of Chrome to you every six weeks.  Maybe that is why, when I look at my logs, Chrome use has been climbing so quickly - up to 30% and gaining 2% per month. Their development process is very, very close to the "release early and often" process that I have been recommending, with at least one improvement.

The Chrome team can deliver a quality product with rapid evolution, while avoiding the stress that comes from arguing about scope ... and whether a feature needs to be in the release, and how they will stretch to squeeze it in, or change everybody's schedule .... They just release every six weeks, and people (read meddling managers) have confidence that if a feature doesn't make the release, there will be a new release soon.

Here is the basic structure:

The release goes out on time.  If a feature isn't ready, it just gets moved to the next release.

Features that are not ready can be disabled (hidden).  They have a flag for that.  After you start stabilizing a release, the only major thing that you can do is disable a feature, and you can do that by patching one little configuration.

They don't do development on "long running branches" and then do a big merge.  Everyone works most of the time on one trunk branch.

They have a long "feature freeze" period for testing, translation, and stabilization.  They make a release branch every six weeks and feature freeze it, and then the development team just keeps going. The release team spends the next six weeks stabilizing and building the production release. So, at any time, there is one development version, and one version in stabilization.

chrome dev cycle resized 600


Andy's Notes

I usually ask for a feature show/hide flag if I think a feature is going to pose a problem.  I now realize that I should ask for this on everything.  That's the improvement.

Before we get to the end of a release cycle (milestone), we create a new release milestone and start moving tickets.  This allows us to focus on the stuff that will be completed with quality.

Agile planning tools try to trick you into believing that you need to finish a complete feature inside one release.  This defeats the whole idea of incremental development and causes the sort of stress that makes releases difficult.  We designed the Assembla agile planner so that you can schedule the tasks for one feature into more than one milestone, encouraging a calmer incremental approach.

I also believe that developers should work together on basically the same code, with one branch, and that maintaining and merging feature branches is often not worth the effort.  Assembla will be introducing new workflows for git that make it easier to push, test, and review code in a shared repository.

The reality of continuous development processes is that you do need freeze time to stabilize a production quality release.  This overlapping approach, where you cut a stabilization branch, is the realistic approach to delivering quality releases.

In this process there are three live versions of the software at any given time - the production release, the release that is in stabilization, and the development version.  That's easy to manage for something self-contained like a browser that just requires some local disk space.  If you build Web server software, it's not so easy to have three completely separate environments with databases etc. ( development, stabilization, and production).  It's easier on the infrastructure side to have just one dev/stabilization environment, and switch your team from development mode to stabilization mode on that environment. However, this is the age of cloud computing and on-demand infrastructure.  An investment in infrastructure to build that third environment will allow your dev team to keep going.

3 Comments Click here to read comments

Upgraded Agile Planner for Fast, Fun Roadmapping

Posted by on Fri, Jul 30, 2010
describe the image

It's fast, it's fun.  It powers your planning.  It tames your tickets.  It's the upgraded Agile Planner, our AJAX interface for adding tickets, building stories with tasks, and scheduling them into milestones, iterations, or releases.  For more details, please watch the video, or just select the “Agile Planner” link in the Tickets tool menu, and try it.

During the last year, many users have told me that they use the agile planner every week with their team.  So what is NEW in the Agile Planner this month? 

* It’s fast.  Drag and drop is smooth.  All tickets are loaded into local memory for instant access.  New layouts for “Milestone | Detail” and “Story | Detail” remove EVERY CLICK between mousover and seeing the detail edit form.

* Open tasks and subtasks to unlimited depth, in the Story/Feature column.  This “hierarchical ticket view” was one of our most requested features, with over 300 votes.

* Enter a list of tasks with the same attributes, using a new pop-up UI.

* In-place editing of estimates.  Just click on the number and edit.  The estimates add up correctly for complete features or milestones.

Incremental development is important

The Agile planner will help you with roadmapping, which I described in my article "Save the best for first".  It's a simple way to get what you want, fast, using incremental development.  We write down everything we want to do, and then we sort it by priority, and we try to find the minimum set of high-priority stuff that will get us a great release as soon as possible. 

A whole industry has grown up around incremental development, represented by Agile, minimum releasable product, lean startups, and even behemoths like Linux, which started as a student project. 

Sometimes, a planning view can be one of the biggest obstacles to this process.  If you write a view of your project that shows a feature listed under a milestone or release, and subtasks for that feature, it starts to force you into thinking that you need to finish everything before you can release.  You start to forget that you are in charge, and that you can release a simple version before you release the complete version.  In the Agile Planner, we separate the your grand plan in the Story/Feature view, from the schedule in the Milestones view.

How can you use the Agile Planner?

Use it with a client or business owner to launch a project.  It’s fun to see a plan take shape, which builds the relationship.  If you run a good roadmapping session, you get a big head start on the implementation, which is the biggest revenue earner. 

Use it with your team to plan iterations.  Many Assembla users sit down as a group with the agile planner each week or each month.  I have seen distributed teams do this with screen sharing tools.

Distribute planning.  I like to create a top-level story, and then ask the developer to fill in more detailed tasks.  It makes the developer feel more confident, and it makes the work more visible.

Many of our users like to sort their tasks into a very specific order.  Agile Planner gives you that control.


Here's a quick video of the Agile Planner, so you can see it in action.


3 Comments Click here to read comments

Mythical Man Month revisited, again

Posted by Andy Singleton on Wed, Aug 05, 2009

I took some heat for my article Time to Vanquish the Mythical Man Month, where I brought up was the idea that the analysis in the Mythical Man Month might be wrong, and consequently, I might recommend different ways to manage a big project.  After hearing my comments at the Agile Boston presentation, Dan Mezick sent me an interesting followup question about that.  I'll review the issue here, and then the question.

The Mythical Man Month is a classic book from Frederick Brooks, who was responsible the IBM OS-360 project.  He considers the problem of large software projects, which tend to move slowly and have low productivity.  There are two frustrating aspects to this.  The first frustrating aspect is that everyone gets slowed down.  A programmer who can produce 100 debugged lines per day on a small project might only manage 10 on a big project.  The second frustrating aspect is that it seems impossible to speed up by adding labor.  Brooks famously says something like "Nine women can't produce a baby in one month".

Brooks hypothesizes that this problem stems from a sort of communication overload.  If N people are working on a project, they have N^2 ways to talk to each other, and that gets to be a lot of work as N increases.  He then suggests some ways to reduce communication load through specialization (for example, a tool master) and modularization, breaking the project into functional groups that only communicate inside a small part of the hierarchy.

It's clear that big projects are slow, hard to manage, and hard to accelerate.  However, I am not persuaded by Brooks' analysis of the problem.  There are 6 billion people in the world, but I don't have to send them all a Christmas card, or write on their facebook walls.  Nobody forces you to communicate with them.

I propose an alternate hypothesis based on dependencies.  In a big project, a lot people are waiting for components from other people.  If 100 people are working, and 50 people are waiting for something, then you are already down to 50% of potential productivity.  The problem could actually become a lot worse if everyone is waiting for a few critical components.

If you believe the dependency hypothesis, then you believe that more communication is better, because it helps people work around the obstacles.  You also believe in sharing code, because if someone is waiting for something, and they get desperate enough, they can fix it themselves.  If dependency is the problem, then big open source projects should scale better than projects with more rigid task assignments, and there is some evidence that this is the case.

Dan Mezick wrote:

You state it is not the N^2 connecting points but rather the dependencies generated between code and coders...basically queueing issues. That being the case, does that tend to steer your design decisions towards [dependency injection, inversion of control, loose coupling architectures?? Do you make design decisions with intention to diminish or eliminate code dependencies?

My response illustrated how you would work differently if you were concerned about communication, or about dependency.

I agree that reducing dependency by using modular code is really important.  However, it's so important, that it's important in any methodology. I'm not sure that we place a bigger emphasis on it than anybody else.  And, it's more important when you are doing maintenance, and you want to make sure that changes and upgrades in one place aren't causing a requirement for changes and testing somewhere else.  For new development, you are often in the situation where you just need a capability. It's not implemented, or it's implemented wrong, whether it's coupled or not.  In this case, the organizational structure becomes important.  Can you fix it yourself? Do you have the ability to communicate with the person who you are waiting for?  In this case, you might want increased communication and visibility, which is the opposite of the Mythical Man Month recommendation, and maybe even goes against the idea of modularity.  For example, you might want people to commit incomplete or even broken code to the daily build, so that you can see what is working and what isn't, rather than doing the modular thing and keeping it to themselves until it is ready for someone else to use.


0 Comments Click here to read comments

Using Agile methods to deliver on a fixed-budget, fixed-time commitment

Posted by Andy Singleton on Sun, Jun 28, 2009

Good comments, and some skepticism, greeted my article about 6 things that you can skip to accelerate a software project.  Mirko wrote “You are crazy”.  A more serious criticism came from MikeB, who, like many others, works for customers that want fixed specifications with firm time estimates.  He wrote “What timelines do you have? I work for customers who purchase software or software services from us. This is a huge piece of the agile methodology that I don't see fitting in the provider-customer relationship. Customers need to budget as much as anyone does. You just can't tell them that 'no, we're not going to design this' and that 'we'll get it done when we get it done and just keep charging you along the way'.   Find me a customer that will accept that, and I'll retire right now.”

Timelines and budgets, in my opinion, are the easy part.  You can do a good job with a fixed price/budget, and a fixed timeline, if the deliverable isn't fixed.  So how do you get away without promising a fixed deliverable to a demanding client or sponsor?  You fix the important part.  You create a roadmap, a prioritized list of feaures, where the important things are sorted to the top.  You guarantee a minimum level of capability, and then you go from there.

Then, the whole thing fits together.   Agile methodologies deliver releases on a fixed time cycle.  So, they give you a much better chance of hitting your delivery date than non-iterative methodologies.  Your expenses are based on the time required (mostly, cost of labor per week), so if you can deliver on time, your budget is easily fixed at (cost per week) * (number of weeks).  You take some risk by guaranteeing a minimum deliverable, but that's your job.  At some point, you have to step up, and be good at what you do.

The thread is copied below.  At the end, I present our battle-hardened (but not foolproof) Assembla Consulting recipe for delivering a product on a fixed price / fixed time basis.  And, in extreme circumstances, I suggest this simple scheduling algorithm.

posted @ Friday, May 01, 2009 2:51 PM by MikeB
Hrmm - you develop software for a web platform that customers subscribe to. What timelines do you have? I work for customers who purchase software or software services from us. This is a huge piece of the agile methodology that I don't see fitting in the provider-customer relationship. Customers need to budget as much as anyone does. You just can't tell them that 'no, we're not going to design this' and that 'we'll get it done when we get it done and just keep charging you along the way'.  Find me a customer that will accept that, and I'll retire right now.  The Agile approach sounds all peachy - but in the business world... hmm...

posted @ Friday, May 01, 2009 3:08 PM by Andy Singleton
MikeB, I don't understand your comment. Agile or not, you have prioritize the features that you are working on for customers, and tell them "yes, we will do that" or "no, that is not on the roadmap." You have yes's and no's whatever your methodology. 
If you give a customer an exact time of delivery to an exact specification, and then miss the date, you are actually causing a worse situation than if you don't give a specific date. Under the agile methodologies that I propose, you do better for this customer in two ways. First, you move faster, so you have a higher probability of hitting any given date. Second, you can get them a release on a specific date, if that turns out to be important, by not committing to a fixed spec. 
I usually work with a fixed timeline, fixed budget, and some flexibility on the spec. So, perhaps Assembla's work does fit into the type of customer relationship that you are imagining. 
However, there are a lot of customers that like the idea of getting software when it is ready to be released, soon, but with no timeline. That's the policy that Google uses, with their soft launches and endless betas. Google is one of the biggest software companies in the world counted by either revenue or users, so it's clear that they have found a large number of users that do subscribe to their "we'll get it done when we get it done" approach, as long as the basic underlying service continues to work.

posted @ Friday, May 01, 2009 3:21 PM by MikeB
I see your point Andy - or, really, I -want- to see your point. I love the agile concept - however, again, I'm not sure that it works when a customer is purchasing a deliverable product from you. That is, when we're not building a product internally, or as a beta, to be released later for sale to a community (like Assembla and Google products).  
Let me try to explain my thinking (correct me where you see me wrong) - So in your case, you can certainly work the agile approach because you know that whatever changes you make to the solution are out of your own pockets. If its a worthwhile change, where you see the potential to increase price or number of sales, you'll choose to add it in. 
Contrasting this though with customers coming to you for a specific product to be built specifically for them - they need to know what it is going to cost; they'll require it - 15+ years in this business I've never seen different. Maybe I'm doing somehting wrong, I'm always one to listen to critique...  
So, how can we give a price tag and at least a close timeline if we start so loosely and allow change along the way. 1) we never know what it will cost us to build it and 2) the customer will never know what it will cost them to have it made. 
I know I'm probably in an old school paradigm, but I am able to look outside the box... I just wish I could make more sense of this - I'm even having a tough time explaining it here. But really, I do appreciate your feedback on this as I really do want to visualize this working the way its supposed to. I just haven't found a customer to support it - they have to know how much money they are going to spend - just like everyone else. 

posted @ Friday, May 01, 2009 3:42 PM by Andy Singleton
MikeB, it can work if you assume that the specification is not fixed. At Assembla Consulting we work on fixed cost, fixed timeline development projects, and here is how we quote it.   

First, we make a roadmap, a list of features sorted in priority order. Whenever possible, we pull features apart so that we can deliver a simple feature first, and add to it later.  
Then, we read down the roadmap and we draw a line under the minimum feature set that we think will make a useful release. That's our guarantee. We take some risk to guarantee that you will get that much, within a fixed budget and timeline. There should be a high probability of going considerably beyond with the same budget and timeline.  
Then, we decide on a timeline that includes a first useful build, a beta release, and usually, a full production release. These timelines range from 8 to 26 weeks, and typically are more controlled by the business schedule than the development team.

Then, we design the team or "level of effort" that we think we need. Admittedly, this requires a rough estimate of the work to be done. The team has a certain weekly cost.  
The budget is equal to the cost per week, times the number of weeks. 
Then, we work on the roadmap in order. We assume that the roadmap will change approximately weekly if we see opportunities to improve the product. We release daily for the development team, weekly for the client, and to bigger groups on the dates promised. We try not to make a decision about when to release, but instead, discuss who should see the release, depending on its level of maturity.  
With this technique, the exact deliverable is not fixed, but you have a fixed budget and timeline, and you always get a useful product.  
This method is not appropriate for someone who absolutely requires a fixed spec - probably because their budgeting process is so unwieldy that they only want to go through it once. However, it produces a MUCH more reliable timeline than other methods, and it leaves open the possibility of getting a better product than you initially specified.

posted by MikeB
Very good clarification Andy, thanks. This has spurred a great conversation. I have often wanted to hear how another business owner utilizes this agile approach. I'll take a little time to re-read and further absorb your response - I may reply or may not reply again - but your post allowed me to air something that has been bewildering me for some time. heh  
It was particularly useful hearing a response from a business owner and developer, rather than simply from a developer high strung on agile. 

3 Comments Click here to read comments

Stick your con call up your estimate! 6 things you can skip to save time in a software project

Posted by Andy Singleton on Tue, Apr 21, 2009


The definition of higher productivity is doing less work to get the same result. Maybe that's why most of the feedback on my recent podcast was about the list of "don'ts" - things that you can cut out of a software project to save time.  Or maybe people just found some of this advice surprising.  Let's count down the greatest hits.

6) Travel

Traveling takes a lot of time.  You might think that it's going to speed up your project by bringing different parts of your team together. However, if you know how to manage a distributed team, it's actually a lot faster just to sit down wherever you are and get the work done.

5)  Architect in advance

Agile gurus recommend that you design "as late as possible" - ALAP - meaning that you wait until you need to implement something before you add it to your architecture.  But, most engineers find it unsettling to start a big project without an architecture to match.  Even the people who say they like ALAP often don't really practice it (sort of like pair programming).  But, the reasoning behind the ALAP idea is very sound.  If you wait to do something, you might never have to do it.  The project might go in a different direction, or be canceled, or be great in a simpler form, or you might figure out a better way to do it.  The work you didn't do is 100% time savings.

4) Add project managers

We all know that bigger teams are slower.  According to the statistics in the big fat book "Software Assessments and Best Practices" from Capers Jones, my favorite bedtime reading, programmers are not responsible for this problem.  Actually, teams get slower when you add project managers.

3)  Conference call

I have noticed something when we go to "rescue" a project.  If the team spends a lot of time on conference calls, the project is probably delayed.  Maybe the delay causes the phone time.  All I know is that conference call time is closely correlated with project failure.  It's best to avoid conference calls.  You should write down your tasks in tickets, hold a quick stand-up meeting, and maybe keep a chat thread running.  If you start setting up conference calls, your people will be bored, and you might get sucked into a time warp.  In the two years since I started making this claim, I have never heard someone say "I worked on this project with a lot of conference calls, and it went great!"  This never happens.  Prove me wrong, I dare you.

2) Interview

It takes a long time set up job interviews, and some time to do them.  If you go straight from a resume to a paid trial task, you get to the work more quickly.  You might also get better results.  Job interviews are deceptive.  You might think you are hiring someone because they proved they can do a good job, but statistically, about half of the time, they are just good at interviews, or they matched some preconceived notion that you had about what a good person would look like.  That's why orchestras often hold auditions behind a screen.  Try trials.

1) Estimate

A lot of technology, skill, and time goes into estimating how long things will take.  In many cases, this expenditure of time and treasure is useless.  Maybe you can skip the estimates, and get your real work done faster, or take the time that you save and do something equally useless on Facebook or Twitter. Let's look at the cases where the time estimate is useless:

  • You already know what order you are going to do things in, and no estimate is going to change that.  This is the big escape route.  If you can get things into priority order, with a good roadmap, you will not need to estimate.
  • You already know how much time and money you are willing to spend on the project.  This is the typical reality.  It doesn't matter what your estimate comes to.  The project is worth a certain amount of time and money.  As an entrepreneur, I totally sympathize with this time-boxing money-boxing approach, and I recommend it.  Given a new product idea, I am perfectly happy to say that it should take X weeks to build and not more.  A bigger organization might pretend that they care about how long you think it SHOULD take, but most of the time, they are lying to make you feel better, or self delusional.  You can deal with this by using the agile method of prioritizing, and always having something that you can ship, however incomplete.

  • The estimate is going to be wrong anyway.  There are ways to improve estimates (reduction to detail, self-estimates, historical velocity, etc.)  However, some projects have a lot of dependencies and undertainty, and over a certain size of project, the estimates are almost always wrong.  You can use the tactic of tracking your estimates and comparing them to actual velocity.  If the estimates get better with this technique, then keep doing it.  If they keep going off track, then maybe it's best to give up, and just prioritize better.
Task scheduling is a worse time waster than estimating. You can learn to estimate correctly, but you always do things in a different order than the schedule.  Then, you have to spend time fixing the schedule to match reality. That is why we schedule by stacking a bunch of tasks (not ordered or scheduled) to be done before a milestone date.  That way, you can do them in any order, and you don't have to spend time fixing the schedule.


Now that I am at it, there's more.  These aren't tasks to skip, but rather, situations to avoid altogether.

Do anything with a fixed specification

You may feel like a winner when you purchase services using a fixed specification, but if getting to a spec takes longer than doing the services,  you lose.

Divide work geographically

It might seem like clever management, a nice simplification of roles, to send your requirements to Chicago, your coding to Bangalore, and your testing to Lima.  I think this wastes talent and makes your life harder.  Why not hire people in all of your locations that can handle the complete process?

Use synchronous collaboration (phone, video, screen sharing) to manage fast-moving situations

It's the job of a good manager to avoid fire drills, emergencies, and any type of fast-moving situation.  People should have enough time to do good work.



11 Comments Click here to read comments

Creative Contact - How we build and release a Web product

Posted by Andy Singleton on Wed, Nov 26, 2008

Bob Hubert of Creative Contact writes: "It sort of amazes me that just 5 months ago we started to put this site together and we have completed a credible, professional and altogether good looking product.  My hat is off to you and your whole team."

Creative  Contact is a site where designers, photographers, designers,filmmakers, and other artists can post galleries, find gigs, and collaborate on projects.

Bob Hubert, the founder, is an experienced entrepreneur who runs a company called Spec that builds biotech factories, and in his spare time takes photographs.  In this case, Bob hooked up with Fresh Tilled Soil, a design firm that we often collaborate with.

You might be interested in the stages that we went through to deliver a web product, because it demonstrates some of the ways that we minimize delays at each step.

Proposal: This was a short phase, a few days, because we already had a mockup - HTML representing the site features.  I looked at it, determined we could get something out in 8 weeks, and quoted a fixed weekly rate for a specific team structure.  In our methodology, we give you a team, a number of weeks, and a weekly rate.   Then, we deliver a release in the time available, and we cut features to fit the time.  We never negotiate a fixed deliverable, because this takes a long time to specify, and the start of the job is delayed.  So, from the beginning, we are working to eliminate delays in getting to a release.

Roadmapping:  Usually, we do a roadmapping session, in which we make a list of features, sort them by priority, and try to find a minimum useful beta release.  In this case, all of the features were represented in the mockup.  FTS likes to make an HTML mockup that represents the complete product vision.  I selected a subset of the items for implementation, and got Bob's agreement on that.

Setup: The first week we deploy a reduced-size team.  The technical lead has to make some architecture decisions, set up the code skeleton, and build a staging server.  Usually, a designer also works during this time.  We build the team around the technical lead.    At the beginning of this project, we assigned some new guys on trial jobs, so there were more team members than planned, and we used the project to qualify some new developers.

Incremental releases: We put the development team to work on tickets with weekly releases.  The Creative Contact team was involved in testing the weekly releases, and they learned to write tickets to get what they wanted.  This is the bulk of the work, but it flowed smoothly.

Stop!  Bob called us up and said "I need you to completely stop development for a few weeks while I show this to some people and do some marketing".  This happens on almost 100% of the short-cycle development projects.  Nobody actually expects to have a product in eight weeks.  We get into week 6, and we start ramping up the analytics, the blog, the user forums, and the other operating apparatus, and it becomes clear that there will have to be a launch process.  Our customers usually want a break to organize that.

Commercialization: We did testing and small changes with a small group of users during the summer.  Bob arranged to launch the product with special deals for a set of art schools, so the first big batch of users came in at the end of the summer.  We ramped up up development team at about half the original size (2.5 instead of 5 people) to handle changes required by these users, to tune the marketing on the site, and to finish the for-pay "Professional" features.  This second round of development also lasted about 8 weeks.

We don't often post testimonials for the consulting side of the house because we don't want to steal attention from the other great consulting firms using  Also, we are often in one of two situations that keep us quite.  The first situation is rescuing a project that has lagged for a long time without a release.  The second situation is where we are building a product for a company that will need further financing.  In that case, we have to work on building an in-house team that will be an asset of the company, and we need to let the new team assume leadership.  So, thanks to Bob for giving us this opportunity to explain how an Assembla development engagement can work.

1 Comments Click here to read comments

The customer is always right, but he can't design your product

Posted by Andy Singleton on Mon, Nov 10, 2008

We recently added a customer request page -  - from the folks at Uservoice.  Although we have so far only received votes from a tiny fraction of our user base, we have already learned a lot.  The top two requests - a customer login with special permissions, and the ability to tune permissions inside a space - are really two views of the same request.  "Customer login" is a clear statement of the request.  The requester wants to invite his customers as users, but show them a special customer view.  "Custom permission for tools" is a suggested implementation. Our blog comments contain a third closely related request - lower charges for customer roles.

So, we have learned what users want.  Users are experts in what they want - the ultimate authority.  However, they are far less expert in figuring out how to get what they want.  They are perfectly happy to suggest an implementation, but if we follow that suggestion directly, we are likely to get a bad result.  That makes sense.  Designing our product is not their area of expertise.  It should be ours.

Customer implementation suggestions, so readily offered, will typically pose two problems.  First, they may be impossible, because the customer doesn't know all of the constraints.  Second, they are almost always purely incremental, rather than innovative, because the customer hasn't studied all of the options.

For example, a customer might come to you and say "I want to travel from New York to Los Angeles in less than seven hours."  Great idea.

But, if you ask the customer how to design the product, he will probably say something like: "I use my car to travel to other cities.  I want you to boost the car to 2000 horsepower, streamline it, and build a very, very straight road.  Then I will drive to Los Angeles quickly."

This customer is making a series of logical and incremental extrapolations from the current product.

The engineer assigned to build this product quickly sees that the customer's design won't work.  He comes back and says "We can build a jet airplane that will fly through the air at 600 miles per hour, and we can build an airport in New York, and an airport in Los Angeles."  That would work.  But, it's a non-incremental solution, a completely different approach.  It requires expertise about the available options and constraints that the customer does not have.

So, now we have the following request, which I will paraphrase as "I want to be able to invite customers and give them a special and controlled view of tickets, documentation, and status."

The suggested implementation - a special set of permissions for someone with a customer role - poses a few problems.  If a customer has permission to see one tool, but not a linked tool, he will get "Permission denied" from some links.  We will need to assign a new user role for customers, and the team owner will have to manage those roles, without getting confused.  If it's not completely simple and clear what is included in the customer permissions, there might be security leaks where the owner inadvertently reveals more than he wanted to reveal.  The product is already complicated. We want to make it look simple for the user.

Time to put our thinking caps on and get to work.


2 Comments Click here to read comments

All Posts | Next Page

Follow Assembla

twitter facebook youtube linkedin googleplus

Get Started

blog CTA button

Subscribe by Email

Your email: