I documented my personal manifesto originally in this link. It was useful to get it down on paper rather than a tacit understanding. I think I should sharpen it up a bit. It’s the same mostly – some wording has been modified. I’m asking people to call me out when I err.
G(enuine) – Be honest, forthright and fair rather than vague, fake and invulnerable
R(espect) – Actively listen and respect (not necessarily agree with) the views of others rather than jump to hasty conclusions
I(ntegrity) – Uphold good human values and principles and avoid situations that are opposite to these
T(ransparency) – Be open about why, what and how rather than obfuscate, obscure or opaque
S(incere) – Mean what we say via actions rather than being glib, hollow and lack of follow through.
Whilst we try and be all things on the left we sometimes recognize we fall into the poor behaviours on the right and seek to correct that.
I used to say for over 15 years, put the Analyst back into Analyst/Programmer. This was when many jobs where advertised as Analyst/Programmer, but the Programmer never really did any meaningful analysis. It was mainly confined to the act of writing code not so much about the understanding of requirements.
The reason it fell into disuse is probably correct when you look at the traditional ways software was produced. Another reason could be the cognitive load required between swapping out of coding and understanding requirements. This a more like an excuse rather than looking for causes.
I’ve now come to say put the Analyst into Analyst/Programmer. It was never really there in the first place. A programmer can and should have valued input from the beginning of the software production process. That does also mean being a nice person and maybe strengthening into areas not so familiar like talking to customers – it’s a communication process as much as a technical process 😉
Inspired by this talk from Martin Fowler this year that I feel aligns with this ideal, I’ve included the following call to arms that I now start my Agile Programming course with, which is to be released soon. I hope to sharpen it up a bit more. You can have input into it if you like. Here’s a start:
As programmers we are more than just code monkeys. We are motivated to create value for our customer, so we should be on board with everything including:
- Being able to speak to our customers to learn the domain we are working in
- Being able to seek clarification from anyone be it Business Analysts, Customers, Product Owners, Testers or anyone else
- To question anything that we have concerns about
- Expect to have a meaningful input into understanding requirements
- Expect to inject innovation and have it considered
Over to you. Admittedly there is some work to do to unravel decades of silo based work practices.
Lead by Creating Leadership
L. David Marquet has interesting ideas that help create and foster better outcomes for all. He has come up with a Leadership Manifesto and is seeking input into this.
Take a look at the link. Even if you feel you’d like to challenge this do so. Ideas should be challenged.
For me after years of trying to lead and not to ‘brown-nose’ my way through work life this resonates with me. When I’m giving instruction in Agile and Lean practices and mindset I include similar ideas.