Why Employees Won’t Innovate

Companies talk about wanting to innovate, but most don't make it easy, or in some cases, even socially acceptable for employees to suggest new ideas. Even today most employees are afraid to suggest new ideas. In many cases they don't want to be accused of having a dumb idea (looking stupid). Or they are worried about "image risk." In a study done by the University of Kansas and Texas A&M they found employees worried coworkers will think negatively of the if they came up with better ways of doing things. They found that in some cases employees were afraid they'll "provoke anger among others who are comfortable with the status quo."  Who wants to make their co-workers upset with them?

So what can be done?  Are you stuck with never getting those great ideas from your employees?  Well, the good news from the KU / Texas A&M study is no, companies can create an environment where employees are comfortable in sharing their ideas. The study found the key was creating a sense of safety. Provide an environment where differences are tolerated and employees are encouraged in trying new things and even being wrong.  I know that was one of the hardest "lessons" I had to encourage at my last start-up – suggest a new and different idea.  Don't worry about it being dumb (ok, to a point). I tried to show them by example also.  Personally, I mainly did it by asking why.  Why do we do it this way?  Is it because we always have and we haven't looked at the alternatives in a while?  Once the leadership shows it is ok to have new ideas and even encourages them (truly encourages, not just saying empty words) employees will start sharing their ideas and suggestions.

Some of my other posts on innovation:

Embrace Constraints or “…shank somebody…”

I just finished reading Rework by 37Signals and read the best quote ever in a business related book (maybe in any book) "Now we're not saying you should go out and shank somebody…" 

Their point was don't let constraints limit you.  What can you do with what you have?  Just like prisoners who make weapons out of soap or a spoon. They make do with what they have at hand.  It's not an excuse that you don't have enough time or money or resources.  No one does!  Sometimes you have to think creatively to come up with a way to get the job done.  Can you keep your day job and work on "your work" at night? Most network TV is crap now anyway. Is that hour of American Idol worth it?

A second point was limited resources could be a good thing. It makes you focus on what is important, really important. What do you have to have versus what would be nice to have?  And is it worth supporting if you do build it? Every feature adds complexity, testing time, and maintenance. And don't forget the time required for training and support on that new feature.

So, like Rework states, embrace your constraints! It's not always the worse thing and could be a benefit if used properly.

What one thing can you do today that will make the biggest impact?

What one thing can you do today that will make the biggest impact?

The craziness of Monday is over; today is a productive day.  And you are fresh, it's early in the week and early in the day still.  What one thing could you do today that would make your week?

What do you need to do? Not fire fighting. Not wasting time on email or meetings. What would make you the most productive? What is the most important, not the most urgent? Set aside today and do it!

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).