Ship it! Stop coding and get the site (or application) out the door!

I was interviewing with a company last week (let’s call them Company X) that was over three years old, but they had only launched their beta site 6 months before. What did Company X do for two and a half years (30 months!)? That seems kinda crazy to me.

I was interviewing with a company last week (let’s call them Company X) that was over three years old, but they had only launched their beta site 6 months before.  What did Company X do for two and a half years (30 months!)? That seems kinda crazy to me.

Ship it! Get the basic functionality built and start sharing it with your target customers!  How did Company X know what they were building was what their customers actually wanted?  How did they know what features were important and what were nice to have (or even a “yeah, we’ll never use that” kind of feature)?  How did they know if they built flexibility in the right places to fit the customers business processes (without over complicating the solution)?

What was their competition doing during those two and a half years? I am sure they weren’t standing still.  Company X is trying to enter a very crowded space with very successful, well entrench, well funded players already in place. How often did the bar of basic functionality expected get raised on Company X by the competition during those two and a half years? Company X had to have spent huge cycles just trying to catch up every time a competitor released an update.

And how much did the market change in those two and a half years? There has been big pressure on pricing the last two years.  I know their business model had to have been way off.

I believe you should release as soon as you solve a business problem or fill a true need – customers will use it.  And they will give you feedback.  Look at the most famous beta in the world – how long was gmail in “beta?”  Or look at Basecamp by 37Signals – not the most features, not the most flexible, but it does what it does really well and simply.

If Company X had spent six to nine months (even a year) building the beta and then had released who knows where they would be today?  How do they know if during the last year or two their customers couldn’t have helped them find a space no one else is competing in. Or functionality that separated them from everyone else? Most start up companies go through massive changes during the first few years.  Normally for the better! As they have sales and market pressures adding features and changing their focus most start ups become better and better.  It’s like a diamond, you don’t get something beautiful without a lot of heat and pressure!


Taking Care Of Number One

Are you meeting your own expectations? If not, why not? What are YOU going to do about it?

No one else is responsible for your career.  The company isn’t responsible (look at the rampant layoffs that have been going on for years)…  HR isn’t responsible (nice people, but they only enforce the corporate policies in place)…  Your manager isn’t responsible (but good managers try to help you)…  YOU are! You are the only one responsible for your career and your success.

You need to manage yourself. You need to know what you are good at and play on your strengths. You need to make sure to set yourself up for success. Look at the work you are doing and your productivity. Are you proud of what you are contributing?

Are you meeting your own expectations?  If not, why not?  What are YOU going to do about it?

Are you a chicken or a pig?

In one of my last postings I compared the different SDLC methodologies, but Scrum has been successful for me lately so I want to use this post to expand on it a little bit.  First, the Scrum methodology is true to the principles of the Agile Manifesto written back in 2001.  Second, it can be implemented at the beginning of an effort or in the middle of an effort that is in trouble. And third, it just works!  So what is Scrum?
There is a great graphic here.
During a “sprint”, normally a one to four week period, the team creates a potentially shippable product (working and tested software). But a sprint does not always have to equal a release – a release could entail the work (features) done in two or three sprints. The features or functionality that goes into a sprint comes from the “product backlog,” which is a prioritized set of user stories of work that needs to be done. What backlog items (user stories) go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that she wants completed. The team then determines how much of this they can commit to during the next sprint. During a sprint, no one is allowed to change the “sprint backlog” – the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software.
A key principle of Scrum is that customers can, and will, change their minds about what they want and need, and that changes cannot be easily addressed in a planned manner. Scrum accepts that customer change cannot be controlled and focuses instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
Some important point to remember are:
  • All user stories need to be broken down to take between 1 to 16 hours (fewer hours is better – I find the the most you really want a task to take is a day)
  • Don’t put a user story in the product backlog unless it has an estimate.  All user stories have to have an estimated LOE!
  • Testing has to be included in the sprint
  • Work in progress (WIP) is BAD!  In general it is better to have multiple developers knocking out a task than to have them all working on separate tasks for multiple days.  You don’t want to have a bunch of tasks 85% done! A user story is either done 100% or it is not done, ie 0%.  Nothing in between!
  • Burn down should be posted and visible to everyone.  You may need to track a sprint burn down and a release burn down.
  • If a user story is too unknown you need to create a spike item (a time boxed task to do the R&D to better understand the task).  That spike item will become a task assigned in a sprint.
  • Daily Scrum meetings and the Scrum of Scrums meetings should not take more than 15 minutes after a team is working well
  • No meeting should take more than 4 hours (from my personal experience I’d say 2 hours honestly).  Even the demo should be able to be done in less than 4 hours.
There are no meetings for meeting sake in Scrum.  Such a nice change!
Before the Sprint starts there is a Sprint Planning meeting to determine what features from the product backlog will be addressed in the sprint (these features move to the Sprint backlog).
During the Sprint there are two daily meetings; the Daily Scrum and the Scrum of Scrums.  TheDaily Scrum happens everyday at the same time and same place.  The Daily Scrum is used to allow the team to answer three questions:
  • What did you do yesterday
  • What are you planning to do today
  • And do you have any issues in your way
The goal is to have this meeting in 15 minutes or less, so any real issues should be discussed with the Scrum Master before the meeting.
The Scrum of Scrums allows all the Scrum teams to come together and is normally after the daily Scrum.  A representative from each Scrum team comes to this meeting and answers four questions:
  • What did your team do yesterday
  • What does your team plan to do today
  • Do you have an issues
  • Do you foresee your team creating any issues for another team
And finally, at the end of the sprint, there is the Sprint Review meeting where the team demo’s to everyone the working software.  And the team also covers what was planned, but not completed in the sprint.
More advanced companies may have a weekly MetaScrum meeting where the Product Owner meets with the stakeholders and answers the same three questions:
  • What did the teams do last week
  • What the teams are planning to do next week
  • And the issues standing in the way
This allows even more communication between the entire organization.  Remember the burn down is published and visible.
There are two types of roles, based on the commitment involved, pig roles and chicken roles.  The names are derived from a joke about a chicken and a pig opening a restaurant.  The chicken only has to provide eggs and may continue their normal activities other than that. While the pig has to be fully committed to the effort i.e. provide the bacon.  I personally believe both types of roles are equally important to the success of the release, and the same level of commitment is needed from both pig and chicken roles, but it is a funny joke (if you can take a joke) and it was a great title!
 The Pig Roles
There are only three roles on the Scrum team – the Product Owner, the Scrum Master, and the Team.
The Product Owner represents the business.  She should be the voice of the customer. This role writes the user stories (use cases), prioritizes them, and puts them in the back log. The Product Owner is responsible for the ROI of the product.
The Scrum Master is not the manager of the team (there are no managers), but their job is to make sure the Scrum process is followed and address issues that would keep the team from delivering the sprint.
The Team is everyone else; normally comprised of less than 10 people this group is responsible for doing the actual work (design, develop, and test).  A team will have Architects, Developers, Analysts, QA Testers, etc.
 The Chicken Roles
This is everyone else; all the Stakeholders. The Stakeholders are the customers and other people that benefit from the final release.  They justify the expense of doing the project.  They are only involved during the sprint reviews. They may come to the daily Scrum meeting but only Pigs can speak.
Final points
Industry standards show most businesses can obtain a 20% cost savings by out sourcing to India.  Jeff Sutherland has stated that implementing Scrum can show an improved efficiency of between 100% to 400%.  In his presentation at Google he quoted an improved efficiency of 240% at his last company. And he has shown benefits to distributed teams and teams of up to 600 developers – so you can’t tell me Scrum doesn’t scale!

Anyway, whether you are a chicken or a pig, we all have a role to fill for a successful product launch!  To learn more about Scrum a great resource is the book, by Ken SchwaberAgile Project Management with Scrum (Microsoft Professional).

%d bloggers like this: