The state of shared vision
I’m reading “Dynamics of software development” by Jim McCarthy, kind of a mandatory when you work at Class-A. It’s an ‘old’ book, considering how young IT actually is, but last year McCarthy published an updated version. The book contains 57 rules for delivering great software on time. The first rule was, is and stays the most important one: “Create a shared vision” In my experience this is so important for a number of reasons.
- **We want to be heading for the same goal.
**This seems very trivial, but it isn’t. People in your project might think they know where we’re heading and what they need to build, document or test, but they might not know *why we are heading there and what route to take!!!
- For example, on a project I was recently on, some on the project were creating their design and thinking and drawing every tiny bit if detail they could think of. On the other hand, management wanted a product out on the market a.s.a.p. for various reasons that don’t concern this article.
Without interference, the product would’ve taken much longer to build, despite the wishes of management. And this because of a lack of shared vision.
- **Sharing a passion
**While we’re heading for the same goal, we’re sharing a passion. I see programming as an art, not work. Everyone can create cool drawings, but not everyone can truly paint. The same goes for software development. And when we’re all heading for the same goal, we’re sharing a passion. And when we share a passion, we truly become a team and we can achieve the greatest things!
“When people say ‘hard work,’ what they really mean is using individual heroics to compensate for the inefficiencies of the system,” says McCarthy. “It sucks. But that’s how most of us make software.”
Share a passion and be a team!
- *It might be easier to accept seemingly weird decisions.
**There are these times when management executes some decision that developers, testers or others on the team cannot agree with. I’m one of those people taking my thoughts to management and telling them what I actually think of their utterly stupid decision. Until they tell me why they took this decision and I actually start thinking “Hey, they actually thought this out. And while it’s technically not the best solution, for the project and/or the product this might actually be* the best solution.”
In other words, people in your project might actually accept decisions when they know the reasoning behind it. And again, you’ll get a shared vision on what’s the right path to the best solution.
The solution that Microsoft Solutions Framework suggests is creating a “Vision & Scope” document. In it should be some project background, why we’re actually going to develop some product. Also the driving factors are very important and wether it’s driven by date or functionality. The key value is also important. Is the key value to make the world a better place, to make money very quickly, to see what the product will do on the market, to create the best looking product in the world, etc, etc. The simple ‘key values’ require a completely different approach on how to create this product. And identifying users could be important. Are the users 50+ years old or some kids? Are they highly experienced users, new, or both?!
Also a Vision Statement should be nice. One vision statement that’s well known by most is “Get a pc on every desktop in every home” from the greatest visionary in the world, Bill Gates. 🙂 Another one from the SQL-Server team, very simple : “Beat Oracle”. Last year for Class-A we had “One step ahead” and this year it’s “Happy to communicate, live or later” as we’re currently trying to implement “The new world of work” (Dutch) inside Class-A and with our customers.