An ode to product mindset and developers who know how to ride a bike
Companies mostly work “in projects” these days. It’s basically a shortcut for a team of people focused on a shared goal for some specific time. We are used to terms like “project success” or “project management”. No wonder people care about their projects and everything that comes with it - success or failure, deadlines and tasks. This is what the days consist of - projects. Ideally, from time to time, we take a deep breath and go through the whole system, thinking how our current task fits in the context. Thinking about the product. Sometimes though, we might lose ourselves in the day to day work, focusing on delivering a project and forgetting why exactly we have this whole thing going on. And it would be just such a shame - developers are much more than just highly skilled workers, they are creators. We just sometimes forget about it.
I already expressed my (complicated) love for Jira before. Using issue tracking tools can make your everyday life easier and more manageable. I would never advocate not using one. But… Jira is exactly this - a task focused tool. It enables breaking the big requirements down into epics, then user stories, then tasks or even subtasks. In essence, this is a trusted method of decomposing a bigger problem into smaller ones. More atomic issues are easier to control and deliver. Seems like a reasonable thing to do. As long as you keep in mind that the small issue is a part of a bigger whole and this wholeness is what you are all after. That’s when Jira’s ability to decompose comes as a double edged sword. As much as it supports a top-down planning, it’s not just as easy to build the bigger picture bottom-up again. How often do you actually read an epic? Or even use one? Maybe no one was reading it anyway and you all decided to skip them? Because the road from a task concerning a change in an endpoint - to the epic about making reservations in a system sometimes seems so long, that many people might not feel like walking it more than once. But agile revision of the backlog does not only concern the development tasks - even more importantly, it requires reflection on epics and user stories as well.
The focus on small steps is totally fine at the beginning of your career. It’s the same as learning how to ride a bike. You focus on small elements first, which pedal to push now or how to turn with the handlebar. Then you concentrate on the fact of riding itself and not falling down (too often). But after a while, you are able to choose a road and destination, focus on where you are getting to and maybe also enjoy the views. That’s what happens when you lift your head from the code and try to see what’s around you, what is the reason behind writing this specific piece of code. If you do that, you might actually have a say about where you are going to and which road to choose. Agile approach expects you to do it more often, one time analysis at the beginning of the project will not be enough. Check the road you’re on frequently and adjust it if necessary. Without a perspective and context, it’s hard to have a sense of direction. If you try making agile-like changes with a waterfall mindset you can end up in a state of child-like confusion. It’s a trap both for developers and managing figures - a whirlwind of acceptance criteria, statuses and looming deadlines can suck in everyone equally.
By definition, understanding a user’s needs is a domain of someone in the project who identifies the requirements and manages the product backlog. It’s great to have someone dedicated just for getting these right. But it’s not enough. It’s one of the reasons behind the agile manifesto - the necessity to understand the user’s needs by the whole team. The simple fact is that it is not possible to make a good product without understanding what it’s for. But funnily enough, it is possible to write good code without such understanding. A beautiful, clean code. Just… with no real purpose. As much as the code quality is very important, it will be just a buried piece of gold if no one wants to use it. No matter how tasty the wedding cake if you decide to deliver it at the funeral.
It’s important to aim at being a good developer and to improve the quality of your code. But choosing the right solutions based on the product’s and user’s needs is where being great begins.
When a client approaches us, she or him rarely asks us to deliver a project. What a client is interested in is the product and its value. The artifacts of a project - a task board, burndown charts, meeting notes are there to support us on the road to the actual product. If a Sprint review meeting ends up being a presentation of the issue progress on the board accompanied by some charts, it only shows a project progress. What is really of value is the system itself - what features are done in this particular version? How do they work? No matter how many tasks have been moved to Done, in the end the increment should bring the expected value and the client should be able to verify it somehow. A system that’s just a pile of unconnected screens and functionalities, even prettiest and cleanest ones, presents very little or no value at all.
Last but not least, let me bring up one thing. The actual pleasure and excitement that comes from creating something. Not just a button or an endpoint, but a whole solution, as a team. You don’t need to carve in wood or stone to be considered a creator - you create systems. I think it’s easy to forget between one git push and another that writing software is really an art of creation. There was nothing, emptiness of dev/null and then, line by line, something appears and works, is used by actual people who potentially find it helpful or fun. Moving tasks to Done, ticking them one by one is as satisfying as any To Do list but seeing the bigger picture and how the button you added actually works for people - that can be really fulfilling. You just need to lift your eyes from the handlebar, as soon as you’re ready. Look mum, no hands!