Development as a team or development as stars?
A good friend and colleague of mine Johan Andersson read somewhere that you can see the communication patterns of a company in the architecture. I can see how that makes sense, but I think its much clearer than that. I think you can see the communication patterns of a company in the interface of its products. Both API’s and UI.
Every bump in the flow of a product, every view that is different from the main theme, every glitch in the feel of the application. They all show where a Star has solved a problem. They all show where communication failed and brute force problem solving stepped in to save the day.
An example could be an integration that uses a mostly unused field to store some information that it was not meant to store. Such as dates being printed in a text-field. Or having to leave the application to complete parts of the workflow on a webpage (or on a different site).
If we consider an application and its features as an onion. At the heart of every application there is a core functionality, the minimum viable product. On this other features evolve, or are developed. In essence making it a bigger onion for every aspect covered.
It could look something like this:
| [](http://www.morkeleb.com/img/Development-as-a-team-or-development-as-_11EE1/image.png) | [](http://www.morkeleb.com/img/Development-as-a-team-or-development-as-_11EE1/image_3.png) |
| Teamwork feature circle | Star work feature circle |
Naturally these describe the wholeness of the experience, and is not tied to the implementation in any other way other than the feeling one gets when using the product. A product developed with good teamwork feels whole and complete around each feature. A product developed with individual stars will still solve the task at hand, but the experience of using it is scattered and lacks flow.
Is this bad?
Pros
- The problem was solved
- Functionality is implemented as the customers wish
- A sale was hopefully made, money was gained
- It might have gone faster due to reduced communication costs
Cons
- There is a glitch in the workflow of the application
- Something looks astray if you consider the whole
- There is a severe risk of bugs being introduced at a later stage, due to things not working as expected
- It might cause rework to repair the flow, or fix the later introduced errors
These lists are probably longer, but they show the pattern
Let’s look at this from a sales perspective. If your method of selling is by listing features and selling a complete system, the stars approach is desirable, it will give you a list of features quickly. At the risk of the development going slower further down the road, especially if you build on “previous” features.
If you, however, sell by demos or free trials, showing the experience of the product and how convenient it is while solving the problem. Working with previous customers who testify to the product’s stability and trustworthiness. The teamwork approach will most likely give you the best experience, and reduced amount of bugs. Thus it might go faster in the long run.
From a buyers perspective, I’d rather use a product with complete flows.
Now ask yourself, are you a star or are you a team member?
How does your organization sell its products? Does selling like that benefit Star development or Team development?
What benefits your organization most? Teamwork or stars?