ekeepo

The two ekeepo™ core service offerings are

1.       Enable software teams to increase organizational maturity using Visual Studio Team System.

2.       Enable software teams to package their assets for reuse using Microsoft Blueprints.

I’ve spent a pretty significant amount of time over the last 6-8 weeks boiling down the ekeepo™ positioning statements.  Apologies to those people who stopped by the web site and wondered, “what can these people do for me?”  That is exactly the motivation for this post.

Enable software teams to increase organizational maturity using Visual Studio Team System

Around mid 2004 (after I left Microsoft), I had the privilege of starting to work with Visual Studio Team System (VSTS).  It was still in pre-Beta and was very difficult to work with, but VSTS was positioned to solve some of the problems I was very passionate about and had been living through in software teams my entire career.  Even though I wasn’t at Microsoft I had to figure out a way to contribute.  Shortly after I left Microsoft I worked on MSF (Microsoft Solutions Framework) 4 (as an outside vendor) with Sam Guckenheimer, David Anderson, and Randy Miller, among some other very smart and talented people.  I learned an incredible amount about how teams work together, the variance between teams, and the opportunity to improve the situation.  I had worked in about 10 teams before that point, but hadn’t really realized how my sample of teams related to (in similarities and differences) to the rest of the software teams in the world.

The opportunity of being co-author on Sam Guckenheimer’s book (Software Engineering with Microsoft Visual Studio Team System http://www.amazon.com/Software-Engineering-Microsoft-Visual-Development/dp/0321278720) not only was an incredible honor, but gave me a chance to show off all the different aspects of VSTS in context of Sam’s text and experience.

At the same time, I was leading a team at Personify Design which was building TeamLook and TeamSpec.  With these two products, our goal was to bridge the gap between the software team and the business by providing interfaces inside Microsoft Outlook and Microsoft Word to Team Foundation Server (TFS).  While we built these products, I had the opportunity to work with high-tens to low-hundreds of teams who were using VSTS (and our products) to increase organizational maturity.   With a number of teams, I was able to dive deeper and help them via ALM consulting and coaching.  It was quite a bit of fun and validated my understanding of the opportunity around helping teams to build better software, with improved quality, on time, and with higher team morale.

As the number of teams adopting VSTS (2005 and 2008) increases and Microsoft continues to add more value to their VSTS 2010 release (as shown in their CTPs), my objective is to help teams use (all flavors of) Visual Studio Team System and Team Foundation Server to increase software engineering maturity.

Enable software teams to package their assets for reuse using Microsoft Blueprints

The idea of packaging a software asset (or code) for reuse is certainly not new.  In fact, by most it’s considered the holy grail of programming and software platforms.  The ability to reuse code libraries promises to create efficiencies desired by programmers and CTO/CIOs alike.  It turns out that it’s easier said than done.   

Over the last 20 years, the industry has come a long way through a number of technologies which have enabled reuse of different forms (i.e. OBJ files, DLLs, OOP, COM, .NET/CLR/IL, SOA).  The challenge with all of these technologies/models is that consuming technologies can often be difficult given the abstractions defined by their corresponding libraries/services.  With Microsoft Blueprints (http://msdn.microsoft.com/en-us/architecture/blueprints.aspx), these libraries/services can be packaged along with the developer workflow (guidance) which drives the developer through the process of using the technology directly inside Visual Studio in the context of their Visual Studio solution and project.   Since early 2008, I’ve had the pleasure of working on parts (Windows Workflow based guidance and extensions) of the Microsoft Blueprints platform (with Michael Lehman from Microsoft) as well as creating Blueprints using the tools.  Given this experience, I am currently working and plan to work with both Enterprises/SIs and ISVs/Component Vendors to build Blueprints which will package their technologies with corresponding guidance and automation.  Depending on what type of company you’re at, here’s how I can help you package your software assets for reuse:

For Enterprises and Consulting/SIs: I can help create your own Blueprints which speed up the process of building the applications your customers/stakeholders need.  These Blueprints can also help distributed development by reducing the ambiguity in how technology is used in your solutions.  For example, if you build web applications for the healthcare industry, what IP can you package in a Blueprint which developers in your company can reuse when building the next component/feature of a web application?  Wouldn’t it be nice if you packaged in all the requirements for implementing your security model and membership/login components into a Blueprint so that you could feel confident that your project is not missing a key requirement?

For ISVs/Component Vendors: I can help create your own Blueprints which help developers consume your technology for a specific application.  For example, if you are the builder of an advanced calendar control which has three special views, you could create 3 different Blueprints which help developers configure/consume your component in each specific view.  This would provide a competitive advantage by increasing the chance that developers get more value out of your component.

If you have any questions or comments, please post questions and comments to the comments below and they’ll get to me.

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.