#Ingeniously #Innovate and #Selflessly #Share – Robertson Screwdriver

Innovation is one of the most overused words out there. I think it can fall into the same bucket as quality. Everybody says we must be more innovative, we must innovate. But what is innovation?

Innovation (from Dictionary.com)

1. something new or different introduced: numerous innovations in the high-school curriculum.

2. the act of innovating; introduction of new things or methods.

So at the end of the day an innovation is anything new. That sounds less positive now.  The one aspect that bothers me with innovation is the lack of the reason for the innovation. Innovation itself does not imply that anything is made better by innovating. Just that something new has been tried. Although this lack of reason for the change does allow for more ideas to be generated without fear of rejection, ultimately the innovation must make things better or we are changing just for the sake of change.

I think if you ask people their definition of Innovation, they would communicate that they believe innovation does imply a benefit or improvement from the current state.

 A key point here is what is creating the innovation? I believe it is the knowledge, skill and creativity of the person recommending the change. They believe that the change or innovation will result in a better product, process, or service.

Is this really then Ingenuity in addition to Innovation?

Ingenuity (from Dictionary.com)

1. the quality of being cleverly inventive or resourceful; inventiveness: a designer of great ingenuity.

2. cleverness or skillfulness of conception or design: a device of great ingenuity.

3. an ingenious contrivance or device.

 

Summary

We need to have Ingenious Innovations and not just innovations by themselves. Hopefully we are taking our experience and skills and using them to continue to evolve the design of our processes and products.

 

Case in Point – Robertson Screws

 

 

This was illustrated for me as I was watching a documentary on the Hurricane Katrina recovery. A Canadian company was going down to the 9th ward in New Orleans to help them rebuild and they brought along their own supplies as they were not sure what would be available locally. Being from Canada, they brought along Robertson screws. The work crews in New Orleans had never seen them before and wondered how they would use them. It turns out that Robertson screws are somewhat of a Canadian-thing. I wasn’t aware they were not widely used outside of Canada. Here is the link to the Wikipedia link on Robertson Screws for my non-Canadian friends.

 

Once the works crews used them, they wondered how they could go back to the standard screws they had been using. The Robertson screws could be put in quicker, with one hand, and were usually straighter. It is also mentioned that the screws are self-correcting due to their shape.

 

The Robertson screw is a great example of an Ingenious Innovation made by someone due to their experience and skill. They created a unique design that would improve the process and ultimately the product being produced. But the lesson on Ingenious Innovation did not end there. Unfortunately P.L. Robertson was so adamant to not license the screw that this prevented Henry Ford from widely using the Robertson screw in his cars. (they were only used in cars made in Canada) This limited the market for the Robertson Screw and greatly limited their use in the United States.

 

A not so subtle reminder that we all benefit when we Ingenious Innovate and then Selflessly Share. 

 

How do I encourage #innovation on my projects?

I actually think about this topic quite a bit. There is mention of innovation in almost every job ad and project charter I see. But really what is innovation? How do we innovate? How do we encourage innovation?

I think we frequently believe that innovations are large changes rather than small incremental improvements. When we think about how to innovate we get stuck on trying to find that next big idea. Or else we try to find the software tool or process no one has heard of so we can present a significant change from the current status. So we try to come up with the new idea and then revert back to the current status when the next big thing can’t be found.

Then we hear from management and others that we need to be innovative. Like we aren’t trying.

I have found that two concepts help out greatly in helping to make projects more innovative.

1) Encourage the small innovations

If you encourage the small innovations in people, process, and technology, I have found that the large innovations will follow. If you analyze what is perceived as large innovations, you will actually find that they were made up of a lot of small innovations along the way. How do we encourage the small innovations? Recently I’ve reviewed incremental improvement statements with my teams to get them thinking about small improvements. The small improvement statements I reviewed on my last project were:

1. I will strive to be a better team member tomorrow than I am today
2. I will strive to be a better [BA/PM/DBA/Developer] tomorrow than I am today
3. I will strive to help to make the solution better tomorrow than it was today
4. I will strive to help to make problems, issues, and risks less tomorrow than they were today
5. I will strive to help to provide more value to the client tomorrow than they had today
6. I will strive to help to create better processes tomorrow than we have today

These statements have helped the team focus on continuous improvement and innovation.

2) Build a team culture of safety and confidence

If you can build a culture where people feel safe in making suggestions or recommendations and where people are confident their ideas will be heard and truly considered, I firmly believe you will get more ideas and ultimately more innovation. I think frequently people limit the innovations they bring forward because they feel they might be blamed if the innovation has unintended consequences. (or they may be criticized for an incomplete idea) In addition, people want to be sure that the idea will be seriously considered if they are going to put the time in to develop the idea or innovation.

To accomplish this, I try to do two distinct things:

I) Abide by the Agile Prime Directive

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

–Norm Kerth, Project Retrospectives: A Handbook for Team Reviews

I absolutely love the Agile Prime Directive as it removes blame and us versus them thinking from the project. It sets the stage for people to feel comfortable in raising ideas and suggestions without the fear of initial criticism and blame somewhere down the road. It also places the onus on the individuals to hear their team mate’s ideas without being critical off the bat. It places the emphasis on “seek to understand” rather than “seek to find fault”.

II) Let the team innovate

This sounds like obvious common sense not worth mentioning. Let me explain. Many teams that have a perceived lack of innovation share the same structure. There are a few leaders that ‘approve’ the innovations that will be implemented and they expect their team members to submit their innovations for approval. This very structure stifles the innovative process. How can the few leaders at the top have the same wealth of ideas and domain knowledge as all the members of the team to evaluate what is a good innovation? Anytime there is an approval process, you can be sure there is not going to be much innovation.

“As a leader, you don’t need to be convinced or believe in every innovation, you just need to believe in your team.”

Many times, you may believe that the innovation may not work. But you again need to trust your team. Otherwise, the team will get a sense of what ideas you are likely to approve and only raise those ideas to your attention. And before you know it you are only getting one person’s idea of innovation from a team of many. And then in the Project Retrospective we will bemoan the lack of innovation.

The team doesn’t submit ideas or innovations for approval, they just inform as to what innovations or ideas they are currently implementing.

But won’t you have constant change? Yes and No. Yes, you will have a lot of change and change that you could not have foreseen. But isn’t that the point of innovation? But if you set expectation and the entire team has a shared vision of success and the ultimate solution, the team itself will determine when it can innovate and when it should not.

The team understands that the project still needs to live up to the client expectations, but how the team meets the expectations should be up to the team to decide. We need to manage by destination rather than by route. The team will determine the best route to take.

Summary

I have combined the small improvement statements and Agile Prime Directive into something I have termed the Team Member Manifesto on my recent team. So far the amount of ideas and innovations have been very high.

#Innovation Debt and the Four Fences of Software Development

I was looking for a new picture for the Blog and I thought about an interesting Blog post. As you can see now, I chose the image of a gate after much searching on various image search engines. (let me tell you there are some very interesting people out there with cameras.)

Gates and Fences

I chose a gate as I think it is a very interesting analogy that can be used in the Software Development industry. In the Agile community we are so focused on tearing down fences that we have to be careful we don’t use the remnants of the Waterfall Fence to build the Agile Methodology fence. I loved the analogy of a gate in conjunction with the fences. We need to ensure that every fence we build also has at least one gate. The fences exist for the purpose of providing structure and restrictions for predictability, but there always needs to at least one way to break free when the situation calls for it.  (hopefully multiple gates)

I thought of 4 separate fences that are quite common in the Software Development industry. They are:

1. Process Fence : Gate leads to greater value

I’ve alluded to this fence already. As I have mentioned, we in the Agile space need to be extremely careful that we don’t construct an Agile fence out of the broken boards of the Waterfall fence. If we start being equally as stringent and demanding, we are equally doomed to failure. Don’t get me wrong, I think the Agile practices are a great fit for the vast majority of projects and an improved over the Waterfall methodology. But we need to be careful that we don’t start to be overly prescriptive and cookie-cutter. It would be incorrect to say all Software Development projects require pair-programming, two-week iterations, and daily stand ups. Just like it was incorrect to say all Software Development Projects required Functional Specifications, Work Breakdown Structures, and Use Cases. Do these Agile practices fit better than Waterfall practices? Usually. But the team still needs to determine what practices best apply and to what extent.

Sometimes you have to open the gate and incorporate all the different practices that deliver the most value to your client. It is likely that these practices will be from many different methodologies. Can an Agile project benefit from a Work Breakdown Structure? It is possible.

2. Technology/Vendor Fence : Gate leads to better solutions

A second fence we can find ourselves in is this Technology or Vendor fence. This is the fence that we typically build around the technology we use and the vendor for that technology. We typically built these fences for very good reasons. Simply put we are more familiar with the technology we use the most and we there just isn’t enough time to learn all of the technologies that are out there. There are just simply too many. So what can we do?

I think similar to the Agile principle about trying one new thing every iteration, Software Development technical professionals should try one new technology every project. (preferably from different vendors) If the project doesn’t allow for this, then we should as Software Development professionals commit to reading one new book and playing with one new technology in our own time for every new project.

If we don’t do this continuous learning and strive to open the gate in the technology fence, how do we know we are providing the client the best solution? Of course we can’t know all technologies, but isn’t it our professional responsibility to know more than one group of them?

3. People/Employer : Gate leads to enhanced knowledge and competencies

The third fence is the people or employer fence. This fence is very similar to the last fence except that it deals with people instead of technology. It is very natural to again build a natural affinity to the people we primarily work with. But it is also important to realize that one company can’t be perfect in everything. (just like one person can’t be the best at everything) We all have our strengths and weaknesses both individually and corporate-wide.

Some of the most valuable lessons learned I have had over the years has been when I have worked with people from other companies and they have shared with me their practices and methods. Now those of us who have worked for a company for a longer duration obviously believe our company has more strengths than weaknesses. (I know this is something I believe 100% about Protegra.)

That said, I look forward to being able to work with new Protegrans and with new partners and clients because I know I am going to learn new things and be the better for it. Opening the gate in the People and Employee fence is one of the most rewarding.

4. Experience/Safety : Gate leads to innovation

The fourth fence is one we build ourselves and it is something I’ve noticed more in myself as I’ve gained experience. I think sometimes when we have gathered more experience, it is easier to just do what we have done before. Developing using a known process, technology or team is the safe route and something we feel more comfortable with. The decision between introducing new items and doing what has been done before is a fine line as we can’t take on too many new things and risk the project, but if we don’t take on any new items we are building what I like to term Innovation Debt.

Like Technical Debt, it is sitting there and charging interest. Innovation Debt will also needs to be paid sooner or later and it is better to pay it off bit by bit on projects rather that having a large payment at the end. The real problem is that too much Innovation Debt can result in a compromised company that is passed by their competitors. Too much innovation on projects can result in compromised projects. It is a very fine line to walk.

But not opening the Experience gate is actually more damaging that opening it. It is just a little unnerving at first and requires an atmosphere at work that encourages innovation and rewards fast failure.

Summary

Those are the four fences and gates that I try to keep in mind as I go about my projects. Does anyone know of any more?