Let’s say that I ask you to calculate all the happy prime numbers between Planck’s constant and the speed of light expressed in meters per minute.
Did you immediately start reciting numbers to me? Odds are that you did not.
How accurately can you estimate the time it will take you to find those numbers?
There are a number of problems encountered that slow progress and prevent estimation:
- Do you really understand what I have asked you to do?
- Do you know the two constants I mentioned?
- Do you know how to find prime numbers in that range?
- Do you understand what a happy number is v. a non-happy number?
- More importantly, what problem are we trying to solve here? What are the happy primes for?
I like to refer to the need for background information as “grist for the mill.” It is the raw material of knowledge work.
The brain needs a certain fact base, a set of operations and transformations, and some worthy target so that it can grind away productively.
So we can categorize the above-listed problems as being problems with goals, problems with facts, and problems with operations.
We are given goals (possibly as stories or features) and we are expected to use the facts and operations we have at hand to achieve those goals.
When we have the facts and operations handy, this becomes a more-or-less trivial event. More trivial if the risk of breaking things is low, or less trivial if the the risk of unwanted side-effects is high.
The Goal Hole
When we don’t clearly understand what we should build then neither teamwork, nor focus, nor all the best data repositories and training videos in the world can help us.
Without a clear, singular, immediate goal in mind, we will see teams thrash and muddle and there will be little “real work” getting done.
This is why domain expertise is so highly valued among software professionals (especially analysts and testing experts). A domain expert can grasp the intention and ramification of a new software feature in ways that in inexperienced team member cannot.
Having access to the minds, experience, and knowledge base of our colleagues helps us understand goals and learn skills more quickly.
Ultimately, though, such goal-setting relies on understanding of the customers we serve and the environment in which they do their daily work. This is why XP teams invite actual customers into the team and they work with them every day. Scrum teams tend to proxy the customers with a Product Owner who is empowered to make choices and prioritize work on the behalf of true customers.
Clear goals give us focus to
accelerate our learning.
The Skill Hole
Even if we understand the goal, we often find ourselves missing background information (facts) or skills (operations) that are applicable to meeting our goal.
If we are lucky we find our team members have the know-how we need and are available to work with us so that we can simultaneously learn and complete the job.
Sometimes knowledge is not available in our team, and so we dive into Google, StackOverflow, MSDN, or whatever fact-and-operation repositories we have open to us.
One way or another we can usually acquire the skills we need – but it takes a bit longer, or involvement of more people to achieve it.
The learning time is generally not included in estimates, because we don’t know how many skills we need to acquire or how long it will take to be “good enough” to get the job done.
Some people work in a system of individual work assignments, pressure, and tight (sometimes artificial) deadlines. Such a system prevents learning from each other and also discourages taking the time for learning.
Sometimes, lacking facts and operations and also lacking the time to acquire them, developers intentionally or accidentally revise the goal to one that is within reach of their current knowledge set.
After all, if we’re right, we will save a lot of time (the “good intention” which paves many diabolical paths).
If we’re wrong, then it turns into a requirements interpretation argument between development and testing, or between the development org and its customers.
We can either learn what we need to learn, or we can muddle through with what we have.
Learning is Essential
Development team members are often asked do work that they don’t fully understand using skills that they do not yet possess.
Projects often slip their dates and code quality often declines when policies and reward structures allow for neither pooling nor or solo acquisition of knowledge.
Everyone is left “muddling through” the best they can.
We find this radically sub-optimal for knowledge work.
If we want our teams to do great work consistently, we need to get past the idea that “you should already know everything” and “learning is what you do before you get hired” and move to an atmosphere of continuous learning.
A team that learns is inevitably going to outperform teams that do not. It’s a matter of time.
Teams learn faster when they work together instead of working solo on different parts of the same job.
The Smallness of Me, the Enormity of Us
The circumference of a human skull is only about 22 inches and contains knowledge acquired during a single human life time (so far).
Outside that same human skull, there are many billion humans all gathering and inventing new ideas, facts, procedures, and goals.
They’re working at all times of day and night, and they’ve been at it for millennia.
Millions of them are now building software. We are constantly finding articles touting “the 15 languages you should learn this year” and “the crucial 45 Java libraries every developer should know.”
“Knowing everything you might need to know” has become a human impossibility.
While we value knowledge and experience in new hires, companies tend to place them in structures where their experience cannot be shared to benefit our organization. We are not building the broad and deep pools of competence and insight that we need.
It’s hard for large and storied organizations to give up the idea of “getting maximum output for hour worked”, but perhaps keeping individual noses to individual grindstones has been preventing the evolution of better working models in our industry.
We take huge risks by doing all of our learning and thinking in solo "silos."
Pair programming and mob programming make sense because they pool knowledge and understanding. Everyone contributes information, reasoning, skill, and perspective. The job gets done, and the team grows capability for similar jobs.
This leads us to the desirable future where we don’t work harder and longer, but instead accomplish our goals more quickly and easily.
Pooling abilities is so crucial in our field that the Agile Manifesto included it as a key principle:
“The best architectures, requirements, and designs
emerge from self-organizing teams.”
Understanding and supporting the ways that people think and learn together may be the competitive advantage that our industry has been (mostly) lacking for decades, as well as the reason that so many agile transitions fail.
That is a little grist for your mill.
Some Questions
- When your team seems slow, do you consider what it is that you need to learn in order to complete work more quickly?
- Is your team struggling with a lack of information, a shortage of safe software techniques, or unclear goals and prioritization?
- Are you ever so busy working around knowledge gaps that you don’t have time “left over” for learning?
- What can you do to encourage necessary learning and sharing?
- What skill did the team lack that caused you to use work-arounds last month? Are you pursuing that skill?
- What would happen if you were caught experimenting with a new technique, instead of working directly in production code?
- When your team seems to be questioning goals, do you sometimes assume they’re stalling?
- Have you noticed a difference in your cognitive function when you have a a clear and immediate goal?
- Have you ever reduced the time to deliver a feature because you acquired some new information, tool, or library?
- How could your team be more “easily accomplished” instead of being “harder working?”
