Intro
Being responsible for software development management in a software house, gave me an excellent opportunity to meet clients from various industries, from all over the world. I could observe completely different approaches to project management. Every so often our clients run the entire process by themselves, but usually, they rely on the support of our Product Owner (PO) or engage them as a Shadow Product Owner.
From my experience, entrusting the software development process to an experienced person focused on the entire project often has some significant advantages.
The precious time of our clients is limited – no matter how experienced they are in the software development process cycle and how comprehensive their knowledge about the IT industry is. This lack of time often directly affects the development pace, quality, and costs. Hiring a PO to keep an eye on the development team allows clients to reduce spending and maximize development quality. Additionally, the client gains more time for critical aspects of their business.
In the chapters below, we explain, how those positive effects are reached, step by step.
It all starts with well-defined tasks and a solid backlog
Whenever I start a new project I focus on a well-defined backlog and a good refinement process first. From my experience, a complete understanding of business needs and collective planning the best approach, using joined experience of key team members, are critical for reaching your business goals efficiently. They’re also crucial for a good developer experience.
For this to happen, the business goals require a thorough analysis. I always try first to understand the benefits of addressing those business goals, and to find the deeper “why.” I go through various scenarios the end-user will go through. I perform analysis and sometimes challenge the customer's idea to make sure the solution produces the required results.
Is it worth spending so much time creating and discussing user stories? On a recent project, a client provided me only with a high-level specification. It was my duty to define tasks and investigate them with developers. The client showed up once a week to answer our questions, check the progress and investigate outcomes.
We made sure that refinement meetings gave the team a thorough understanding of the project, and how it was going to solve the needs of its users. We had detailed discussions about possible implementation paths. Only afterward did we go on to prepare the estimation. The effect was the minimal number of bugs in the application and a satisfied client who got the software that solved his problem, below the planned budget.
Without detailed discussions, and a good process, I'm guessing we'd reach a worse result, in a longer amount of time.
The critical aspects, which helped us obtain good results, were:
- Full clarification of the business context for the team
- Discussions, which helped us avoid redesigning the system
- Good software development process, and it's iterative improvements
- The client was available and happy to answer our questions
- Full transparency and constant monitoring of the budget, done in advance
What are the benefits of a well-prepared backlog of tasks?
It allows validating the feasibility of the planned solution
Have you ever decided to cancel a task whose implementation has already been started?
Providing a concise and comprehensive description of business needs for particular tasks, forces the team to reflect on it deeper. Sometimes it turns out that not every exciting idea is really needed. Its implementation can be unprofitable or simply unnecessary. Our goal is not to create the software. It is to meet real business needs. If we can do this without writing extra code, that’s great!
On one of my projects, a client didn’t have a complete picture of the business case he tried to address. He didn'thave time to identify all the dependencies. Regardless, he kept on providing developers with tasks. Then, during the implementation, he was often stopping the work on features, as their cost turned out to be too high, or they required extensive modifications.
What can the Product Owner do in such a situation? It's impossible to know all the details and dependencies of the task right away. However, in this project, a careful analysis of the solution helped me identify the dependencies. It allowed us to notice the increased complexity before costs were incurred. We were able to either try to limit the complexity or to eliminate the task before it consumed time and budget.
It makes prioritization easier
Having the tasks described, it is easier to sort out priorities. It is simple to distinguish between items essential to meet a genuine business need and those that aren’t critical at a given moment. This not only potentially lowers development costs. It sometimes makes a difference between being the first, and the leader on the given market, versus being a follower.
Identification of all use cases speeds up implementation and prevents mishaps
Verifying all use cases and edge cases together with describing them before the implementation saves development time and thus money. Of course, there are some cases that we don’t want to handle in the application by design (e.g., those that happen extremely rarely). Still, they are worth identifying and defining – even if our plan for implementation is “do nothing.” Otherwise, if we don’t define them, the developer will come back with questions. This extends the work time as well as the total time of delivery and, in consequence, increases the costs.
It reduces the likelihood of failures
If a developer knows the business need well and can use the task description as a guideline, they will be able to figure out complex corner cases that should be handled in the code, including situations that are very hard to predict by a non-programmer.
Dividing tasks into smaller jobs reduces the delivery time
It allows to receive feedback and test the end result faster and helps organize the development process.A complete description of tasks also includes their appropriate division. Introducing small, gradual changes to the application allows for:
- Quick verification of business assumptions
- Possible change of the assumptions at a low cost
- Delivering value faster to the client, which builds trust between the project's main stakeholders
At the same time, if you implement too many code changes at once:
- Errors are more likely to occur.
- The code review process and testing process become more complicated.
- The more extensive the task is, the longer you wait for the results; moreover, you need more time for market validation, and the development costs increase.
- You risk ending up with a system, which is more complex, and thus harder to maintain in the future.
Maximize the benefits from testing
An adequate task description is also critical for an effective testing process. Having a detailed description, a tester knows what to test and does it more efficiently, minimizing the risk of errors and reducing costs. If the tester finds a bug before the implementation goes live, the price of their work is incomparably lower than if the bug were found later by application users or during the review done by the client.
Is having a PO the only good solution?
Are clients capable of describing tasks in a way that is useful for developers? In many cases yes, as it doesn’t require technical knowledge. What is needed is practice, a good understanding of the business need, and a detailed analysis of how the application should be addressing this need.
I perceive that although most clients want to describe tasks for programmers, they often can’t find enough time to do this right. Assuming that for the good of the project, it’s worth having a ready backlog of tasks and work planned ahead, I can’t recall any client who actually could do it by themselves efficiently.
Developers can wait for your response, but it usually increases the development costs. Business partners are less patient. They won’t wait for your call or email; instead, they will find a new contractor, or choose a different tool.
You may be able to handle the development process well. The question is, whether it's worth it.
A structured development process
Business owners are necessary to answer questions, discuss plans and explain the business context. Their participation in the process and their feedback are essential. Busy clients often try to bend their communication with the development team to their tight schedules. While it's entirely understandable, it can also be difficult to ensure.
- Sometimes it's hard to move forward without a quick response.
- On the other hand, ad hoc meetings distract developers from work, increasing the costs and significantly reducing efficiency.
A planned development process is the solution to this conundrum. Planning meetings, setting their goals, and ensuring that every session runs effectively improve productivity.
A common antipattern is a project during which developers never know when they will be invited to a meeting. They don’t understand what is exactly expected from them during these unplanned meetings. They can’t plan their work for more than two days ahead, as everything depends on the client. The client also takes quite a commitment – without them, work couldn’t continue even in the short term. A situation like this can be easily addressed with a good process. If ignored, it results in increased costs, frustration, and what’s worse, it can often lead to a failure in meeting business goals.
What are the positive effects of working in a specific methodology?
- More effective work planning, thanks to maintaining constant time windows for communication, and clearly defined goals for every meeting
- Constant reality checks, which verify whether the solution being implemented indeed meets the business goals
- Increased developer productivity thanks to the possibility to plan own work — a developer knows, at least in general terms, what is expected from the team in the near future
- Predictability of costs and budget thanks to the constant iterative reviews
The project may be run on Scrum or Kanban. Scrumban is a popular and quite good solution as well. Sometimes, the best choice is yet another system that meets the setup requirements. In every case, the goal of the software development process is to ensure we efficiently meet business goals, maximize the team’s effectiveness, and thus optimize development costs. It also assures the predictability of workloads and deadlines. In our experience, a good process always pays back the time it consumes.
How many CEOs can afford to devote a few hours a week to planning and communication?
I have had the opportunity to collaborate with people who simply love caring for the development process, and backlog. In addition to being the business owner, head of finance, and technical expert, those people often had an exceptional knowledge of development methodologies.
In case you can’t combine these (or many other) roles, it is worth learning how the PO can help you.
Product Owner:
- Is a bridge between IT and business – they make communication entirely understandable to both parties. They translate goals and needs into specific actions
- Facilitates meetings and maximizes their effectiveness, takes care of reaching the goals of each meeting
- Minimizes the risk of micromanagement
- Organizes the process for the entire team:
- establishes a workflow for tasks, considering differences in the approach to epics, tasks, bugs, and hotfixes
- works out with the client the Definition-of-Ready and Definition-of-Done
- cares about the structure of task descriptions
- explains the meaning and purpose of individual elements of the process to all participants
- Enables the client to take a break from collaboration with the team when they need it and at the same time gives them confidence that they have their representative in the team who takes care of their business needs
- Makes sure that critical meetings take place and achieve their goals
- Contacts the client when their decision is crucial
- Reports on the progress, monitors achieving goals, and ensures specific milestones are met on time
A good Product Owner knows what conditions need to be met for the team to be efficient at their work. He or she has extensive knowledge of the methodologies used in the software development process, and sees which of them should be used to well address the needs of your project.
Ok, but what if your business grows?
More customers, more orders, larger traffic, and better revenue. Is that the perfect situation? Only if you have enough time and resources to make use of it and if you can ensure that you and your team don’t lose the big picture while keeping the competitive edge.
If you use micromanagement to control the development process, it will be hardly scalable when your business starts to grow. You will most likely need to learn how to delegate. Otherwise, you won’t be able to extend the development team, which is often needed.
A Product Owner, together with a Tech Lead, can take over the organization of the development process, secure the effective use of the team's time, address administrative issues, and ensure that every developer works on the right task. Finally, if the PO is well briefed about the business context of the product, they can also answer developers' questions during your absence.
Summary
It might sound trivial, however, the implementation of the three following principles is, in general, the key to success:
- Well-defined backlog and work planning
- A process that is defined and used in practice
- Avoiding micromanagement
If you have an eye on a Product Owner who understands your industry and you can share your responsibilities with them – it's worth a try. We use their help also in our internal projects, as we know it works.
And when hiring PO won’t pay off?
- You already have a fully committed PO on your side who is covering all the needed roles.
- Process guidelines for the project are clear and there is a suitable person on your side to take care of their facilitation (not necessarily a fully involved PO). In such a case, it may be worth using a Shadow PO to perform only these roles that are not performed by the Facilitator.
category
