Skills Pyramid
This post is just really to get feedback about an idea I have had floating around in my head. As a coach/consultant I often come into groups that are already doing software development. In order to best serve them, I have to meet them where they are. Sometimes figuring out exactly where they are can be a bit of a challenge. I’ve been trying to figure out a way to describe the way LabVIEW teams grow. I came up with this idea of a Skills Pyramid. I know there are some smart people who read this blog, so I am hoping they’ll be able to give me some feedback on this.
Building Blocks
I put these skills as a progression because I felt like each skill builds upon those below it. Any organization is not necessarily at 1 particular level at a given time. They may be doing some things from all the levels. I kind of use it not so much to classify an organization as “at the Iterative Development Level”, but rather to look at the lower supporting levels and then start asking questions.
As an example, suppose a customer wants to implement Continuous Integration. CI happens to fall in the automation level. Are the lower levels solid enough to support adding CI? Do they have a good branching/merging strategy? Have they standardized to the point where their projects are fairly similar and have similar needs so we can use 1 CI script across multiple projects? How well defined is their Software Development LifeCycle? How does CI fit in with that? Do they have Unit Tests that we can incorporate so we can avoid building code that is broken?
Just because a customer wants to implement a particular process doesn’t always mean it is appropriate or the best use of their resources. Asking these types of questions can help me get to what they really need rather than what they say they want. Often the pain point they are trying to address is the symptom, and not the underlying cause. My goal is to help teams change in a way that is sustainable and that involves identifying and solving the underlying cause.
Source Code Control
The most basic Software Engineering tool most teams start out with is Source Code Control. I put it at the bottom because I believe it is the most foundational. Not everyone starts out here, but those that don’t very quickly realize it’s importance. At it’s most basic state, SCC gives us the freedom to experiment and make changes to our code with the confidence that we can always get back to a previous working state.
Standardization
Once teams have sourcecode control in place, the next progression is usually standardization. Picking an SCC solution is in a way a form of standardization. That opens the dialog, but SCC also drives the standardization process. Pretty quickly teams realize that without adopting some sort of modularity in their code and enabling clear communication, team members end up stepping on each other’s toes. The pain of merging quickly leads teams to move towards standardizing on some sort of modular framework.
Iterative Development
Once some standardization is in place, the increased communication from the previous stage leads teams to re-examine their development practices. Usually at this point teams tend to migrate towards a more iterative development process, due to the many pains associated with the older waterfall-style process.
Unit Testing
I put Unit Testing up high on the pyramid. It is something I consider a basic skill. I feel like it should be lower in terms of importance, however, it seems in my experience that most teams adopt it rather late. I think what happens is that teams tend to “discover” it when they are in the iterative development phase. They start researching agile and see a bunch of references to it there. I kind of lump Testing and TDD together in this model, even though they are really 2 separate things. Obviously if I were to split them up TDD would sit on top of Unit Testing.
Automation
The last thing most organizations get to is automation. People often get excited about automation, but forget that you need a process before you can automate it. In order to effectively leverage automation, you often have to have a lot of other processes and systems in place, so it makes sense to put this at the top. This category includes things like scripting tools and CI/CD
Growing Up And Out
Teams not only grow up the pyramid by adding new layers, but they also grow out. This is necessary because when adding a new layer, the base must expand to hold the new weight. It’s not like once a layer is built, it is static and doesn’t change. Even something as basic as SCC usage can evolve. Most teams do not start out using Gitflow. However once you start adding in CI, then Gitflow becomes a lot more attractive. This is a case of the base expanding to hold the weight of higher layers.
Another example might occur as teams start to standardize. Standardization often results in shared code across projects. This drives more sophistication in the way we use SCC. Now we end up managing separate repositories for our reuse code. Then we end up either incorporating them into our new projects using git submodules. Or perhaps we use VIPM to package them and develop some sort of iterative development workflow around releasing our reuse packages. As you can see changes, in one layer can ripple both up and down the pyramid.
What do you think?
I’m curious to hear everyone’s comments. Is this an accurate model? Is it useful? Am I missing something? How do you visualize and or categorize a team’s skill level?
