Years ago, I discovered the power of process. Through the work of David Allen and his GTD Process by following a simple process I no longer dropped balls in my work.
When I started managing people and projects, I figured if there is a process for managing my life, surely, there must be one for managing teams. As it turns out, there was, scrum is an incredibly powerful technique for enabling teams to self-organize and deliver value.
On this path, I have come to realize the process is not enough. In fact, it seems the question “What is our process” is not as valuable as asking “How are we managing our risk”.
It seems no matter how much you stick to the process, the universe has an unlimited number of curve balls all lined up for you.
In this entry, we will be looking at some of the more common sources of uncertainty in software projects.
System requirements
Time and material model of software development is still dominant. I don’t even blame the industry, after all, once you get high enough in the organization, features against a budget is a first good approximation of the ROI of your dev teams.
The only problem with this view is it ignores the aspect of time.
You see, the more the time, the more the events which imply the business has evolved at a rate dictated by its market and innovation pace. It follows previously valid and useful requirements are no longer aligned with what the business needs.
I have come to find, in real businesses, there are no well-poised problems. What you will have to learn to deal with messes.
How will you cast these problematic situations to problems your dev team can solve?
Available engineers
The advent of coding schools has really helped alleviate the general problem of lack of developers. Unfortunately, they have not done much for the population of senior developers.
It’s very different to build a toy problem that calculates tax to be paid vs building a full-on accounting module taking into account all the nuances of the Kenyan tax code.
Even if you are able to solve the problem of getting experienced engineers in, you now face the secondary problem of ensuring they understand your business.
I have been in two-hour brainstorming sessions to understand how to map common directions parlance to how our business thinks about locations. How do you onboard this knowledge to a new engineer?
What would you do if your longest serving engineer receives an offer from Google?
Organizational politics
Your first true brush with power will be in an organizational setting.
As long as you had sane parents and teachers, probably the worst that could happen to you would be a good spanking, nothing to fret about.
Your boss, on the other hand, has the ability to infringe some major pain in your life.
In this kind of setting power can be used to trump reality with disastrous effects.
HiPPO (highest paid person’s opinion) means the organization may never achieve alignment. How can you build a software product when different stakeholders in the same organization demand mutually exclusive features?
How do you handle uncertainty in your own organization? Talk to me in the comment section below or on my twitter @jchex
