ekeepo

I follow Jason Calacanis on Twitter and was inspired for this blog post by his (one of many) interesting entry titled ‘The 120% Solution.’   (http://calacanis.com/2008/12/04/the-120-solution/)  I think he makes some fantastic points, but as I started thinking about it I disagree with one of his points.  Here goes:

I agree that we need to cut the waste and start new companies (doing my part J), but I don’t agree that a 6 day work week is the answer.  I think it’s about productivity, making the right decisions, and in the spirit of being Lean, eliminating 20% of things that are not as important as the other 80%. 

How many productive hours does the average American worker experience in a week?  10, 15 maybe?  I’m sure there are people in the 30-35 hour range, but I think that is more the exception that the rule.  Think of this, how many interruptions did you have this week in your office environment?  How much time did that take out of your week?  One more hour of productivity to 30% of our population would result in a huge benefit to our economy.

In the internet connected and device world which we live today couldn’t we get the productivity increase from a larger number of people knowing how to use tools to save time?  I’m a software guy so I don’t think of hammers and pulleys (although recognize their importance), but imagine if people know a little more about spreadsheets, databases, email, and online services.  Imagine if the user interfaces got more intuitive and these tools became more accessible.  The good news is that we’re making this happen. 

One of the simplest tools on the internet today is a search engine.  You type in words and the result is a bunch of pages.  Most people who are reading this know how to use a search engine, but I bet the number of people in America that still don’t know how to use a search engine to answer a specific question (i.e. How do I register my vehicle in the state of Washington?) is staggering.  This might be a result of users never considering that they can use it for this task.

Becoming more productive in an area is not about working harder, it’s about asking the right question and caring to find the right answer.  I help and work in software teams for a living, so applying this to the software teams, if you’re not going to hit your deadline you shouldn’t say, “the Standish Group says that some 60% of projects don’t meet their delivery date” and therefore it’s fine to be part of that 60%.  If you care, which I hope you do as your job is on the line, you should be asking questions such as: Why did we miss the date?  Was it a lack of quality at a specific point or area in the project that caused us not to be ready?  Was it the fact that the scope increased in the middle of the project?  Was it that we lost code during the construction?  Was it that we couldn’t integrate a component into the larger project?  Did we not define the project well enough and not change quick enough when we realized that we were solving the wrong problem?  Yes, it’s hard to know what question to ask to improve, but the first step is caring.  Whatever the problem was/is, the next question should be: How do we fix it?  Continuous Improvement is much about asking that question over and over and following through.

Lights, camera, action!  Welcome to the ekeepo, LLC blog and the first official post.

First, you might be wondering, “What is ekeepo?”  Well, first things first.  It’s pronounced ‘eh-kee-poh’.  If you’ve already pronounced it out loud and you speak either Spanish or French then you may already realized that it’s phonetically similar to the Spanish word ‘equipo’ or the French word ‘équipe’ which translate to ‘team’ in English. 

I founded ekeepo, LLC to reach a new level of excellence with ‘Team Decisions and Patterns.’  I’ve been working in software teams for 15 years and in that time have experienced some incredible events (on both sides of the good to bad spectrum).  Some were missed business opportunities where we built great technology, others were great business situations where we missed a technical opportunity, and sometimes we reached flow where both the business and the technology delivered for the customer need.  One thing is for certain: the people on the team make the magic happen.  The challenge is that similar to the greatest artists or composers in history, methods and tools need to be mastered to reach true creativity and innovation.  Whether the advancement you seek with the software you build is elegance, efficiency, or meaning, two core components of reaching a new level of excellence in your team are:

1.      Understanding and enabling decisions throughout the software team

2.      Observing and reusing patterns in the software team where appropriate

Depending on the size of your software team, the people on the team are constantly making tens, hundreds, or perhaps even thousands of decisions at all layers of abstraction and disciplines (ie. Developers, Testers, Business Analysts, Project Managers, etc…).   For example, “Is what I just observed a defect?” “How should I implement this requirement?” “Are we going to make our deadline given the defect rate we’re seeing in the project?”  “Should I write test cases for this new feature I just implemented?”  “Did we prioritize the customer needs correctly?”  There are so many questions similar to these that influence decisions which we’re constantly making in the software team.  For the last 5 years, I have been working with hundreds of teams worldwide at different levels of involvement and building on top Microsoft’s ALM (Application Lifecycle Management) platform Microsoft Visual Studio Team System (VSTS).  Through ekeepo, I plan to continue to help teams reach new levels of excellence by using ALM tools such as VSTS and TFS.  I plan on doing a bit of blogging around ALM and TFS, but don’t take my word on it.  Subscribe to my feed and watch the blog entries flow J.

The other very important side of ekeepo, is the ‘patterns’ component of building value in your team.  You might argue that there is not a part in software which is not patterns.  You’re right!  Patterns are everywhere.  Patterns are in code, in frameworks and code libraries, methods, documentation, requirements documents, use cases, models, data models and databases, operating systems, etc…  The patterns I’m referring to are the ones in how people interact and how they pass deep knowledge between each other.  One core principle of ekeepo is to help teams ‘observe process instead of predicting process.’  It’s very similar to the idea of refactoring code into a library which is useful instead of building a code library which you think might be useful.  Often we find that the former is the better approach.

One great implementation of team patterns is being driven by Michael Lehman at Microsoft titled Microsoft Blueprints.  I’ve had the pleasure of working for Michael on a small part of this effort and I believe Blueprints will improve the way we package software best practices and guidance.  I plan on building Blueprints and hope to blog about Blueprints, how to build them, and how they’re helping teams around the world.

If you have any questions or comments, I’d love to hear from you!  Find me on LinkedIn or Facebook and drop me a line.  Stay tuned for more!