Project management is a complex task that requires the team to adopt the key tenet of agility and adaptability. Irrespective of the size of the project, whether big or small, it is important to keep the element of risk in mind: Positive and negative risks that need to be continuously taken into account and the uncertainty involved in the process only serves to complicate erstwhile impeccable project plans.
Coordinating projects is undoubtedly a complex process for all involved in a successful delivery. Since the project’s inception, everything has to be meticulously reviewed, updated, planned, monitored, and coordinated by the team to ensure a robust implementation with zero room for errors that would impact desired value. Positive and negative risks that need to be continuously taken into account and the uncertainty involved in the process only serves to complicate erstwhile impeccable project plans.
Things seem to get more interesting when, per client requirements, the team enters the post-delivery maintenance phase for a fixed period of time, or an indefinite period where services need to be provided on a continuous basis to ensure overall system stability, addressing end-user problems, accommodating small new feature requests from stakeholders, etc. This is when the unforeseen and unexpected suddenly emerge. Strong Agile development teams, however, boldly accept challenges and adapt to changes when and wherever necessary.
This is exactly one of the core tenets of adopting Agility, which is about working together to incrementally and iteratively build a product with a team attitude that allows for maximizing customer's business value by adapting to change, in whatever form it manifests. And once there is a consensus on what constitutes a functioning minimum deliverable baseline, the challenge of incorporating additional requests of varying magnitude, along with addressing emerging issues, tests the team's ability to balance feature based work with product maintenance.
A multitude of factors can contribute to putting post-delivery maintenance and second phase implementations at risk, such as departing or absent employees, critical requirements, system breakdown or outages, etc., each causing their own degree of frustration for all stakeholders. Consequently, the team also builds up its knowledge of the product’s innards, but a part of the knowledge the team builds remains tacit and at risk of becoming difficult to access, and worst, completely lost. There is also the problem of maintaining a sustainable development pace post-delivery. With emerging requirements and problems, establishing a team structure that allows for reasonably balancing feature development and total product maintenance is crucial.
For larger projects having different fronts that would require attention, a common strategy would be to separate the feature development team and the maintenance team, with the latter structured in a way that it has a reasonable combination of 'T' shaped and 'I' shaped members. A 'product expert' is 'T' shaped, i.e., having specialized knowledge in one area and a broad, cohesive knowledge of other areas of the product. This expert can serve as a guide and help transfer knowledge to those in the maintenance team who do not constitute the core team. On the other hand, the feature team can also have a similar structure, with 'T' shaped team members possessing core knowledge, and working in pairs to ensure new functionality builds upon existing implementation without creating technical debt.
Smaller projects or those with an assessed lower post-delivery maintenance/service requirement can have teams structured that will work on both new implementations and on-going services. This not only ensures that the team minimizes the communication gaps and lack of cohesiveness in newer additions and modifications due to separate teams, but also provides all team members to work on both new feature development and maintenance, thus eliminating the risk of monotony associated with the latter. Incorporating DevOps practices for faster deployment/delivery and minimizing possibilities of downtime can give a considerable boost of confidence to all stakeholders involved.
Choosing and adapting to frameworks in the maintenance phase would largely depend on the nature of the project and the team, with an emphasis on using Scrum for the implementation of new features. However, adopting flow based methodologies like Kanban can significantly boost productivity and provide the team the flexibility to manage and mold the process as they progress in more unpredictable scenarios. Though discussion on these topics can span several articles, it is important at this stage to understand the value of being flexible, adaptable, and creatively supplementing tools and methods to maximize business value for the customer.
With the teams now structured in an optimal way, they would need to ensure that the artifacts are equally optimized for the free flow of information without over-complication. The choice of having separate Kanban boards promotes clarity but can induce a slight operational complexity. Both the feature and maintenance teams need to agree upon the process to ensure this happens seamlessly by either working on assigning responsibilities and even having a rotation mechanism. Common backlogs allow for better understanding of bottlenecks and impediments, thus allowing the entire team to collectively work on removing the problem by doing a deeper technical evaluation and working with the product owner to help adjust priorities and delivery time-frames where required
While critical items need to positively be addressed in a timely manner, it is important to define the value of requests in connection with on-going feature work. Those in the business function should be asked to use an appropriate prioritization scheme and assign value to requests that would make the most sense based on the release timeline. Using standard ‘story mapping’ and timeline based techniques, teams can visually lay out priorities grouped into releases by working with the product owner.
The tools, processes and the systems the team employs should always be minimal, manageable, flexible, and scalable. In the end, the entire purpose is faster delivery of value to the customer. If any process or system that inhibits the prompt delivery of value to the customer is found by the team during regular reviews and retrospectives, it should be removed entirely, replaced, or altered to allow for optimal, high-quality delivery.
Finally, demonstrating excellence in execution is always a team effort. Cohesive, self-organizing and productive teams are not a myth, but the result of empowering and motivating the teams to put their best effort into crafting robust products and providing excellent services. The principles around being: adaptable, open to change, frequent communication with stakeholders, and continuously striving for excellence in implementation. These should govern your entire development and service delivery process, irrespective of your organizational structure and nature of the project.