Cross-team Product Development & Delivery Process: Development Phase (Part 5)

Table of Contents

• Intro & Definition
• Pipeline Success Metrics
• Context Initiation Phase
• Discovery Phase
• Development Phase
• Go-to-Market & Release Phase

Now we are finally getting to the most exciting part of the process. Having all the requirements (product, design, and technical) defined, you should be ready to move forward into the development phase:

Development

The first thing during the initiation phase to think about is an approach to managing the development phase. The project manager along with the development lead should agree upon the most efficient way to tackle the implementation: either using Waterfall, any of the Agile methodology, or Extreme Programming — whatever fits best to certain circumstances.

NOTE: To avoid misunderstanding, I would like to mention that either of the mentioned methodologies can be applied to a process as a whole. I’m not trying to limit the usage of those only for development purposes. The iterative development process requires constant involvement of the product manager and designer along with the development team to keep the backlog well-defined and to react to any changes that appear during the development phase. But here we are outlining the intercommunication and cross-functional work within and between departments, which requires sequential phasing in one way or another.

Secondly, you have to understand that the software engineering teams did not participate in the context initiation and discovery phases; hence they require introduction and answers to well-known questions: “what”, “why” and “how”. This means that the development phase should always start with a series of introductory meetups, where product managers, designers, and development leads present the upcoming scope of work and provide answers to questions from development teams (and there are always a lot of them, believe me).

Third, you have to establish bidirectional information flow channels. Many things that were not included in initial planning will arise during the development, that’s the nature of software engineering, just deal with it.

With all that done, the project manager kicks off the development according to a software development management process chosen. If it is Agile — then backlog grooming, spring plannings, and daily standups are scheduled and conducted.

Quality of the Development Phase

Tons of ways exist to measure the quality of the development routine. We won’t dig into details, rather we should take a look at some fundamental indicators that will lead to the constant improvement of the phase as a whole.

• Transparency. The clearer the goal and motivation are, the better people can relate themselves to the mission. Again, everybody should know the answers to “what”, “why”, and “how”. It will improve the overall estimate accuracy and make change management less painful.
• Ease of communication. Monitoring of the current state of the development and the ability to react accordingly to any issues solely depends on the efficient communication between the teams. Make sure you have all the necessary meetups scheduled and help people to remove any obstacles at the cross-team level.
• Bidirectional information flow. To mitigate any of the possible drawbacks, complications, and issues effectively in any of the departments, you have to establish the flow of information (reports, changes, statuses, updates) in the way that everybody has access to it.
• Single source of truth. Development teams will often refer to the requirements definition and implement those based on the information they operate on. So, it is absolutely crucial to have approved and agreed sources of truth (product requirements, tech specs, design wireframes) to make the development smooth.
• Exit criteria. Development teams have to know how their work will be evaluated and accepted. Let them know exactly what is the expectation of the feature completion to avoid any confusion and unnecessary rework.
• Separation of responsibility. This is especially important in the case of multiple teams working on the same product. Divide and spread the work in a way that each team has a strict and isolated field of responsibility, so then the leads do not step upon each one’s feet and mess up with other’s codebases.

Make sure you have crafted all the above requirements to perfection, and you will increase your chances to produce a valuable product drastically. And let the people do their craftsmanship magic.

What’s next?

In the next chapter, we’ll take a look at how the release should be properly managed after the development was completed.

Part 6