Case study: TLI Session 2

Introduction

This is a case study of a project under a time and materials contract with legacy systems inherited from other vendors. The case revolves around the different challenges that a relatively new company might face while trying to provide a solution to a client while working best with other vendors.

Initial Challenges

Synopsis

In the initial stages of the project, the team faced the following challenges:

1. The requirements were changing and evolving frequently
2. The deliverables from one of the other vendors were incomplete
3. There was a lack of visibility beyond the current sprint
4. There was no controlled cadence for the project
5. There was a disconnect between the technical architecture, user experience and development units within the team
6. The team was newly assembled for this project in a new environment/location
7. A new project management tool was used with little experience in the team

Impressions

From the outset, it appeared that the project had a lot of volatility not just because of the ever changing requirements but also because of the different vendors involved in the project. I think that it should become imperative to involve the client teams in getting the requirements well documented. Agility in a project will not help if the participants are not disciplined enough. The project team should have a vision about what the project aims to achieve. Having a new team and new tools are always overwhelming and it is very challenging to get the whole team to adapt to change.

Mitigation

Synopsis

In order to overcome the challenges, the team followed the following approaches

1. Set strict contraints for the process and coach the team on sprint rituals
2. Built a deeper product backlog and synchronized the UX and Architecture teams with the backlog
3. Followed a rigorous development, QA and release build cadence
4. Tracked the velocity of each sprint and factored in non-development activities. There was capacity set aside for support, DevOps etc.
5. Reorganized the team based on the architecture. There were separate scrum teams and a scrum of scrums
6. Decompozed stories to a more atomic level to enable independent contributions with low inter-dependency

Impressions

The steps taken by the team are pretty impressive considering the whole team had come together from different locations in the country. However, this points to a common observation about the advantages of having a colocated team over a distributed one. This may have helped in getting a stricter adherence to the cadence. Organizing the team based on the different systems helps in some large projects in cutting the time spent in meetings down as well as improving productivity. However, personally, I feel that this also reduces visibility across teams and may cause unnecessary antagonism between members of these separate "teams". It will be a balancing act for the technical manager to handle this effectively.

In Hindsight

Synopsis

These are a few things that the team wishes they had in the beginning of the project

1. Regulations requirements
2. Robust unit testing and code coverage mechanisms
3. Had a software architect since the beginning
4. User stories with defined acceptance criteria
5. More focus on the design and documentation

Impressions

These are good lessons to be learned from a process perspective and must be applied to future projects. It is important to understand from a business perspective what regulations apply to the product and must be stated explicitly since the beginning. Having an experienced systems architect from the beginning will always benefit this. It is always important to set all expectations straight with everyone in the team as well as the client to get everyone on a common mission.

Takeaways

Synopsis

These are the takeaways as noted by the team for tech management

1. Understand the control and constraints of the project and adapt accordingly
2. Stay as agile as possible, focus on moving ahead and get everyone on board
3. Define the user stories and acceptance criteria
4. Collaborate with the project management and the rest of the team
5. Delegate as needed and develop trusting relationships
6. Be cognizant of political undercurrents while working with other vendors

Impressions

Each software development or maintenance project is different from other projects in some way. However, there are similarities between them too. This enables a technical manager to form a framework akin to software product line development. Adapt to each project's control and constraints while keeping the core agile methods common. 

Having a collaborative environment where every participant shares in the vision and becomes a stakeholder in the success of the project will feed into the success of the project itself. A technical manager must delegate responsibilities to the right team members and empower the team members to perform independently while still disciplined and aligned to the processes.

Politics exist in most professional environments. This may include the team itself, the client teams or the vendor teams. A technical manager must be able to sense these dynamics in the relationships and must perform a tight-rope walk to get the job done while keeping most of the parties fairly satisfied.