Processes differ actoss organisations

As we all know, depending on a company, software teams have a different structure, a lot of the time it will be a combination of the following roles:

1. Product Manager, Product/UX Designer, Engineers, Data Analyst/Scientist
2. Product Manager (strong in design), Engineers, Data Analyst/Scientist
3. Product Manager (strong in data), Product/UX Designer, Engineers
4. Project Manager, Product Owner, Business Analyst, Engineers

Of course, this is a simplified view; you also have many other roles, like QAs, SMEs, Support Engineers, Release Engineers, Research managers, Product Growth Managers and so on, but this is a whole different discussion and we would be here all day!

All of those setups function under the banner of Agile, following different interpretations. I don’t believe any of them are wrong, but what is often wrong is the company’s understanding of each individual role and even Agile itself. When I first became a developer, our Project manager believed Agile is all about accurate estimation (ha! the paradox) and the burndown chart - yes, we were trying to follow Scrum.

I am not saying following those rules is bad, it can be beneficial in some circumstances (I will not get into examples as again this is a big topic). However, I do know for sure, not understanding why we have certain processes leads to long term inefficiencies and big unforeseen costs. One example of this is, when we focus on estimation, and we do all ceremonies of Scrum really well, but we don’t let the entire team contribute to the initial ‘shaping’ process, then chances are we will build a mediocre product that is not so useful.

Yes, Product Managers or Product Owners have the responsibility to make sure the best products get built, but they don’t have all needed information in their head at all times, that’s why frequent collaboration is one of the most important factors of successful software in my view.

Increased understanding

As Jeff Patton said in his book User Story Mapping:

’Scope creep is nothing more than an increased understanding’

This is probably one of my favourite quotes. This understanding comes from all members of the software team. I believe this is key to building the right products.

I am not promoting Waterfall processes here, I am promoting shared understanding and constant collaboration while iterating.

Bootstrapping each project depends on many factors. In a newly formed tech startup you are more adventurous as you have less to risk (in terms of cost of your build). It’s great to follow the Lean startup model where you Build, Measure and Learn very quickly from light touch MVPs. However, if you are in a large company with a lot of legacy code, where high risk activities rely on complex systems, you will naturally want to be more careful. In this situation, you really want to understand what is required and why, even before you start building anything, also how it will interact with all the existing systems.. I am not just talking about the importance of automated testing, but the business understanding.

Start with defining outcomes

There are so many ways of building something but often we communicate with solutions in mind already. It is important for the entire team to take a step back and understand the ‘Why’ and the Outcomes this product is expected to produce, and there can be many alternative solutions you can come up with together, which are not just healthy for your codebase but also for the entire business. I think the majority of developers have been burnt out by building the wrong things at various points of their career.. A lot of large organisations function this way and you can observe their hiring needs increase rapidly for the wrong reasons, and soon nobody understands what is going on..

Always remember killing features and dead code or even products is extremely beneficial! If you don’t, the complexity grows - it’s like doing a spring clean in your house.

So what about planning?

Definition of planning from Oxford dictionary states:

1. decide on and make arrangements for in advance
2. design or make a plan of (something to be made or built)

As long as planning is focusing on increasing the shared understanding, and not one person producing endless reports for a long period of time and passing them onto someone else for implementation, then it is crucial. The question isn’t ‘is planning important?’ but ‘how do we increase our shared understanding and organise it in a useful way?’.