10 Ways to Improve Innovation at Your Company

During a seven year period, I am not sure exactly how many ideas I had, but 20 of them were good enough to be filed as patents. I'm not going to list them all, but to give you an idea, the patents covered things like:

• Automatically change the parental controls when a kid gets close to a TV
• Change the details of a show based on what has already been exposed to you
• Tuning a TV with your brain
• and more...

Throughout those experiences, there were many things I learned to be helpful and want to pass those forward to you. I hope these ideas help you improve the innovation at your company.

In no particular order...

1. Increase awareness. Through training and presentations, let your team need to know that innovation happens all the time. If they are solving a problem in what appears to be a novel way, you could be on to something.
2. Understand the value. This is what makes you different from the competition. This is how Google established a great way to rank search results, or how Apple has changed the purchasing experience with ApplePay, or how WikiSpeed can make a car that gets 100 miles per gallon. Nothing exciting is going to happen when you do the same thing the same way.
3. Work with patent attorneys. Yes, it will cost you some money, but patent attorneys are necessary to having a successful patent program. They will help transform your brief 3 sentence idea into a thorough, 80-page patent application with 20 supporting diagrams.
4. Be transparent how the patents will be used. Does your company want to protect itself and their products or go after others who violate the patents? It is a litigious world, so if your company is doing something interesting, you should consider getting a patent to protect yourself. You can be like Tesla and keep the patents open.
5. Include everyone. There is no monopoly on innovation. Engineers, accountants, HR assistants, interns, architects, CEOs, and customer service representatives all have the ability to innovate and contribute.
6. Celebrate. When your team comes up with ideas, recognize their accomplishments. Reinforce the value they are creating for themselves and the company. Draw a direct correlation to how their invention supports the company goals. Now they get to add "inventor" to their resume.
7. Reward. Careful here, but yes, reward your inventors. Hopefully, people don't go after inventions for the money, but give them some money anyways. It should be enough to be noticed, but not too much where it diminishes the quality of inventions.
8. Dream. Let your mind roam free and disable that sanity filter. Blurt out crazy ideas, as sometimes, those are the best ones.
9. Combine things and people. Put two things together and see what happens. Bells are cool. Bikes are cool. Why not put a bell on a bike to let people know you're coming? Easy-peasy. You can also see what happens when you let Sales talk to Engineering :D
10. Make it official. Carve out official time to innovate. While some ideas will naturally be recognized in your everyday work, you can also generate lots of ideas when official time is carved out. 

While this is not by any means an exhaustive list, you can get quite a lot of mileage from these points to boost innovation at your company. 

If you are having a problem, chances are someone else is too. Time to find an elegant solution to help everyone out.

Put iOS 9 Into Your Product Backlog Now

Awesome. You have a mobile app built on iOS 8.3. The problem is, when Apple releases iOS 9, your app might break and you will lose customers.

I am going to share some techniques with you on how to manage this risk and potentially avoid all problems, while keeping the rest of your business well aware of the activities of your engineering team. While this is not the only way, this is an approach I used in the past which has resulted in a positive outcome.

Beta-time!

Apple provides beta releases of iOS. Because they make it available, you have the ability to explore new features, but also, see what still works and what breaks in your existing app. This is the key to the framework I am going to share.

The framework for managing this kind of work is as follows:

• Test Through Stories
• Fix stuff
• Repeat

Test Through Stories

Since the backlog is the source of work the team works from, you can create a user story in your backlog to test your app. Here is a sample user story:
As a product owner, I want to know what issues my app has with iOS 9, Beta 1, so that I can prioritize fixes.

Note how the story is specific. iOS 9, Beta 1. There is no ambiguity what needs to be tested. The purpose is clear. You want to know what the issues are. The team knows this story isn't to make sure the app works with iOS9, Beta1, but rather to find what doesn't work.

The acceptance criteria might look like:
The application is tested on an iPhone 6 running iOS 9, Beta 1
All defects are entered into our bug tracking system

You may want to have different stories for different target hardware devices such as iPhone 5S, iPhone 6, iPhone 6 Plus, iPad Air 2, etc.

When the team completes the story, during the Sprint Demo or Sprint Review, the team can demonstrate the app running in the new iOS build, summarize the defects found, and highlight some of the of the key defects that were discovered.

Future Stories

Although Apple hasn't released additional beta versions of iOS 9, it is safe to assume more will come out and you can put those into your backlog now. Doing so will provide more visibility to the team and business of all the work the team needs to do, as well as any impact to schedules or other features. I will touch on this topic more in the Repeat section towards the end of this post.

Additional Considerations

Some behavior might be perceived as a defect, but could be a flaw of the beta release of iOS. The team will have to be very careful in evaluating each defect and making a determination or best guess as to what the cause of the defect might be. To play it safe, document everything so that you can retest it in a future release of iOS.

See What You Did There

In brilliant fashion, you leveraged the process and tools at your disposal to protect the product and incorporate technology updates into the backlog and roadmap. The business now has greater visibility and awareness of changes in the technical landscape. The team also appreciates your forethought to anticipate this kind of inevitable change. Well done.

Fix Stuff

Now that you have a list of things that are broken, you can prioritize those items in the product backlog, just like you do with everything else. Some defects you will be able to fix, and some you won't (perhaps due to schedule pressure or other constraints). Hopefully, you will be able to get all the necessary fixes in place before iOS 9 goes live.

As mentioned before, some defects might be related to unfinished features of iOS 9 and some might be proper compatibility issues such as consuming an obsolete API. Refer to the iOS documentation to help making this assessment and ensuring the proper fix is put in place.

Repeat

You will also have to decide if you want to test every beta version that is released. This will be a function of budget. When you have a lot of automation, or if testing is cheap, then you can play it safe and test every version that is released. If testing is very expensive and time consuming, you might not have the luxury to test each version, and will have to decide what versions will be skipped.

Looking at iOS 8, there were 5 beta releases with the first on June 2, 2014, a gold master release on September 9, 2014, and public release on September 17, 2014. This means you had 14 weeks to test, fix, and release you app while maintaining new feature development. That is 7 two-week sprints. Depending on the release schedule and frequency of iOS, you could have been testing 6 out of the 7 sprints.

On a past project, we made the deliberate choice to skip some beta releases due to other feature priorities. We skipped the first, third, and fourth release of iOS 8, but tested with the others.

Retrospect and Celebrate

After that last minute crunch to fix those final pesky bugs before the iOS 9 GA and you get submit your app to the App Store, take a breather. The team worked hard and discovered many new things. There might have been some realizations about the application architecture that could have made the compatibility with iOS 9 a little easier. Work these observations and architectural improvements into the backlog to better position your product for iOS 10!

Also, celebrate with the team. Buy them food, silly shirts and nerdy gadgets. This might have been a major or minor release of your product. Show your appreciation and gratitude to the team who made your product success possible.

Best of luck and happy coding.

Scrum Potato: Orchestrating a Daily Stand-up

While it is ideal to have team members co-located in a single office, floor, or room. If you happen to have team members in different locations throughout the country or world, you might find a challenge when running a daily stand-up. Sometimes the meeting becomes a bit silly with people talking over each other, dead air where people aren't sure who should go next, or someone orchestrates the sequence of the speakers.

Being a ScrumMaster, one way to help facilitate this meeting is to play ScrumPotato. Based on the game Hot Potato, the method is simple:

1. ScrumMaster starts it off by asking someone to start.
2. That person shares the necessary information for the Daily Stand-Up. When complete, that person chooses who to pass to next.
3. Repeat until all team members have taken a turn.

Some benefits to this include:

1. Its different. Sometimes, it is good to change things up to keep things interesting. Of course, if this is too distracting and the meeting is actually worse, please revisit what you're doing.
2. Encourages better listening. Since the order is unknown, through observation, team members tend to listen better using this model. Being in different locations and not always having visual contact with everyone, listening is a huge factor.
3. Encourages better preparation. Just like in the game version of Hot Potato, ScrumPotato tends to have people more prepared and keeps them on point.

Please give this a shot and share any feedback on how this benefits your team or how you modified this to better fit your needs.

If your team is all standing in one room, it might be fun to actually have a small object or chainsaw to pass around. This helps with the eye contact.

Enjoy.

It's All In Your Head, Get It Out: Tuning a TV With Your Brain

I was fortunate to work on a project at Rovi last year called Brainwaves, which enabled someone to tune a television using their brain waves. We demonstrated this to visitors during CES 2014 in Las Vegas.

Please watch the video on YouTube.
and read the article written by the Entertainment Technology Center: http://www.etcentric.org/rovi-team-experiments-with-brainwaves-project-to-control-tv/

Book Review: Managing Software Debt

Recommendation: Must Have

I have recently read the book "Managing Software Debt" by Chris Sterling and must say I am quite impressed.  The author does a fantastic job explaining the subject and provides a lot of guidance on how to deal with the issue.  If you want to talk about ROI, this book is so packed with ideas and inspiration, it should cost thousands.  The author maintains an open mind throughout the book, and by reading this, you do too.

The author addresses software debt at many levels, more than I knew existed.  This book is part of the Agile Software Development Series, but I think this is a core book everyone involved in a software project should read (chickens and pigs).  I am surprised to see so few books on the topic, but this book is so well put together, I don't know if other books are needed.

Buy it, read it, follow it.

Cross Functional Teams vs Cross Functional Team Members

There is no doubt that having a cross functional team will increase your chances for success.  When the team is able to resolve their own issues and complete the work needed independent of external dependencies, the fault of delays fall onto that team.  Being cross functional empowers the team to better control their fate.  But that is where most organizations fall short.  Not only do you want to have cross functional teams, but you want to have cross functional team members.  Let me explain.

What does a Cross Functional Team look like?

A cross functional team has the necessary skills to deliver product features end-to-end.  In the example of a web application, it will involve people who have database, middle tier, and presentation tier skills.  If the application is graphic intensive, a graphic designer might be part of the team.  If the team as a whole, can cover the skills needed to deliver end-to-end features for 90% of the project, then the team is cross functional.

What about Subject Matter Experts (SMEs)?

The SME is someone who is an expert at a particular field or subject, where that skill is needed for the project, but does not quite need continuous involvement with the team on a daily basis.  Typically, these skills are around architecture, legal, marketing, and operations.  Depending on the app, you may want to staff your team to have one of these SMEs as part of the team.  Something to help you decide this is this question, “How often will the team go to this SME to complete a feature end-to-end?”  If you find yourself needing to go to this SME regularly and frequently, then consider making them part of the delivery team.

Okay, but what is the big deal about cross functional team members?

We have described cross functional teams, but cross functional team members is a different concept.  A cross functional team may be composed of a DBA, two developers, two testers, and a graphic designer.  For most end-to-end situations, the team would be able to implement potentially shippable features.  In practice, not all features will require such an even distribution of skills.  That is to say not all features will be 17% database work, 33% development, 33% testing, and 17% ui.

A cross functional team composed of cross functional team members may consist of 5 engineers.  Each engineer has skills in databases, development, testing, and ui design.  The strength of each discipline will vary among team members, but as a collective whole, they have the skills to get things done.  More importantly, everyone can contribute to each discipline.

This helps mitigate risk when in one iteration, you have unbalanced work.  At the beginning of a project, there may be more database work needed than ui.  In the middle of a project, you might need significant database work because a design flaw was discovered and some refactoring needs to be done.  If you only have a cross functional team, then your DBA will be overloaded.  If you have cross functional team members, those members can help contribute to the database workload.  This approach also supports Kanban development methodology.

Divide, Conquer, Swarm

In action, this is how cross functional team members would operate.

Divide.  The team would strategically divide up the work that needs to be done for a feature such that it would play off their strengths.  Having people do areas of work where they are strong will produce faster results.  You also want to make sure you create opportunity for cross training (paired development).  Pairing with the strong-skilled team members will help elevate the skill on the team.

Conquer.  With the work divided, the team would attack the pieces with full force.  But it is not just all about getting your piece of work done.  Along the way, talk a lot with others and integrate as much as possible.  Get those data access calls hitting the database.  Wire up the UI with the presentation and business logic.  At a minimum set up the interfaces so the feature is making calls all the way through the call stack, even if the logic in the middle isn’t there yet.

Swarm.  As one group (pair) completes their work, they will move on to help their other team members get their work done.  If the database work is done, help out the data access group.  Maybe they need help with unit tests, or implementation.  Perhaps coordinating with the tester on the use cases that need to be supported.  The goal is to swarm the other team members with overwhelming support and assistance.  This will also foster a strong team motto of “We’re all in this together”.  You will have bottle necks, but this swarm technique will help eliminate the bottleneck.  This is only possible if you encourage cross functional team members on an already existing cross functional team.

If you staff your teams as 3 developers and 3 testers, where the testers are not allowed to write application code, you’re setting yourself up to have bottlenecks.  If developers can’t help write tests…bottleneck.  If your DBA goes on vacation…BOTTLENECK.

Requirements Are Dangerous

Here are some problems with requirements:

• Requirements are incomplete
• Requirements are wrong
• Requirements include features that don't make sense or will likely not be used

The problem with giving the requirements to engineers are:

• Engineers think the requirements are complete
• Engineers think the requirements are correct
• Engineers think this feature is worth implementing
• Engineers take the requirements too literally

This gets very expensive very fast.  Some recommendations to fix this problem:

• Talk to the person who provided the requirements.
• Review the requirements in person and in real time (not via email or by passing a doc back and forth)
• Question the value of the feature
• Demo the product as it is being developed to make sure you are on the right path.

For those of you who will take this article literally and argue the definition of "requirements", you probably take the requirements too literally too and have been falling into the same problem for years.