Feeding the cat

Sitting here in a hotel, contemplating on some of the software projects and products I helped to develop over the past years, my eye falls on a cat, waiting patiently outside the door of the hotel.

It just sits there waiting and hoping for some nice person to give her some food.

While it sits there being all furry and round, it does strike me as an animal with a clear objective and moreover, it seems to be meeting its project milestones with 3 (but probably more) square meals a day.

It oddly reminds me of sprint goals in software development, like mice sprinting away from this not so athletic cat. Having goals is very important but as the cat cannot survive without a healthy supply of fat mice, we as developers cannot survive without a healthy amount of quality backlog.

While for some projects or products the vision, goals, and the pipeline of work may be well established, in many cases this is a challenge because of the day to day reality of running a business. Especially in situations where software development is not the core business.

I might not do a software development team justice by calling them a factory process, but the reality is that we need a certain type of consistent quality input to deliver a quality output. Without a good stream of input our output will struggle, and our inner cat will complain about the lack of mice.  Being the cats that we are we will always try and find solutions, beg or scrape by but we'll not be all that we can be.

"Feeding the factory" is what I call vital for our existence as teams that produce solutions for our business. While it does not always need to be big chunky pieces of work, we do like our input to be consumable and we need a consistent stream of it on a day to day basis.

As any business analyst or Product Owner will tell you, building a backlog is difficult and requires skill. By nature, a skill that not everyone has or might aspire.

Would we as developers need to take a proactive attitude and get the input we need to deliver the quality output that we desire? I see this a lot where development teams sometimes by choice but mostly by sheer necessity go out, put on their business analyst hat and engage with the business to extract the information they need. And I'm not talking here about getting some clarifications but actually going through the requirements engineering process as a developer.

I would love to hear your thoughts on this balancing act that developers sometimes face. How do we best engage with our businesses and still delivery the high quality technical output?