Wednesday, September 19, 2012

Enterprise Team Spike

When faced with new technology or other not well understood programming problems we like to implement a spike. What is a spike? I like the definition from  

Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only address the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate.

Well, this spike is of technical nature and does an excellent job to mitigate technical risk. However, I am suggestion another type of spike:

Enterprise Team Spike

What do I mean with Enterprise Team Spike? Before answering this, let’s look at why a spike is a good thing. In my opinion it sheds light on dependencies, weak spots and all other kind of problems. During this discovery process it creates a possible path and provides alternatives. It mostly generates knowledge of how to solve the problem in the given context. So, it is all about generating information and to extract knowledge. How could information and knowledge help us in an enterprise team spike? In Scrum we favor cross-functional teams featuring all skills needed to deliver a done, high quality product increment at the end of the Sprint. Sounds good and works even better when we really do have a cross-functional team. The reality is that too often we have external dependencies to other systems. In large enterprises this could be an ERP, CMS or any other back end system. Typically, those departments we are depending on aren’t working in iterations and increments but with one or two releases a year in a strict serial defined process. In short we cannot be really be done at the end of the Sprint unless it coincides with a release of such a department (and their deliverable actually works out of the  box).
An enterprise team spike is not of technical nature but addresses the team's skill composition. In an enterprise team spike we identify all the skills we need from the very top to the very bottom and aggregate these into our development team. I am sure that once you start to pull this thread all the way out you will discover far more dependencies and skills than you actually thought possible. Once you have this knowledge we can start the HR game in order to get the right people into our team. In my experience this is the biggest problem as we fight existing company structures and believe systems, and worse, attack long established empires within the corporate empire.
It will be a long battle, but once you have the enterprise team spike in place you have a proof of concept that shows how to generate value quickly and reliably. 

In contrast to the technical spike, this spike is absolutely of production quality and must not be thrown away! 


mazupvideos said...

Thanks Ralph,
this sounds interesting, but do you even have a definition / example for such an enterprise team spike? How long may it take?

Ralph Jocham said...

Hi Mazupvideos,
thanks for this great question and the answer is the usual: it depends.

To identify the skills needed is usually around two Sprints. Then getting the people actually taken out of an existing department and put into the Development Team is the lengthy bit which really does depend on the enterprise. Could be weeks up to month ...


Unknown said...

A spike solution is a very simple program to explore potential solutions.Free Business Cards

Anonymous said...

The minute you think of giving up, think of the reason why you held on so long eq2 platinum, when the words "I love you" were said by you for the first time, my world blossoms eq2 plat, Look into my eyes, you will see what you mean to me eq2 gold.