Does your software team:
- fight a lot of fires?
- release a lot of ‘hot fixes’
- constantly push back releases?
- release half-baked features only to never return to them again?
Do your senior leaders blame any of the above on “the market” or “market forces” or “business dynamics” or even “the team”?
The answer in reality is a bit closer to home (than even blaming the development team!)
The problem is you. Specifically, That thing that surrounds your entire company that would be called a ‘system’ in systems thinking. It surrounds your company, every action you take, how your customers respond to that action, other ‘market forces’, and just about anything you can (and can’t!) see, smell, touch, and experience as an executive.
It’s like the Force, except it’s real.
The book definition is that a system is ” system is any group of interacting, interrelated, or interdependent parts that form a complex and unified whole that has a specific purpose. ” (Kim, Daniel H. (1999) Introduction to Systems Thinking. Pegasus Communications, (Pg. 21))
Yea, you have a system, even if you don’t know it. — and I don’t mean agile — that’s not a system for developing software. It can be a part of a piece of a system, but it’s not the whole system itself. In this case, a system is both the parts, their dependencies, and inputs and outputs that result in software being delivered and loved (or hated) by the folks that use it.
Things like:
- Culture
– Management Culture
– HR Culture
– Company Culture
– Developer team culture - Past Events and how your senior leadership handled them
- Policy
– PTO policy
– reimbursement policy
– training policy
– BYOC (Bring your own Computer) policy
– Requiring specific brand/model computers purchased by IT
– Financial policies meant to save the company money
– Travel policy
– WFH Policy
– RTO Policy - Training
– Management Training
– Developer Training
– Financial Training - Layers of Management
- What gets rewarded
- What gets punished
- How the team receives feedback
- How the team receives information
- Your budgeting process
And right at the very bottom, after all those things that actually matter, are the systems we think of when we talk about developing software:
- The methodology the team uses to develop software
But, that’s just one tiny bit of the picture, and on its own its almost meaningless to how your software actually gets developed and used and whether your business is successful or not. Don’t believe me? Here’s one simple way to find out: If you’re an agile team, look around at your agile process and ask yourself, is the business’s success with software totally in our hands? Or are we dependent on someone external to the development team for success?
A final thought before we go: If the agile methodology de jour isn’tthe whole of the system your business uses to develop software, then why do you give it the importance of being responsible for the whole of the system? It’s a tool, and a tool for a tiny piece of your business’s overall success or failure.
This post originally appeared on my mailing list. From time to time I put posts from my mailing list onto here, but not always. If you want to read what I’m writing, your best bet is to sign up for my email list, below.