In the previous post, we talked about some major challenges we experienced in an integration project. In this post, I will share some suggestions on how to solve these problems. I also bring the discussion about using “Agile” or “Check Point Control” in integration project plan.
Based on the previous post, it becomes natural that below items are important for managing an integration project in control:
1. Remove dependency on single integration environment
2. Manage cross team dependencies
3. Avoid vague integration design
4. Adapt to changes
5. Plan properly
Let’s discuss them one by one.
1. Remove dependency on single integration environment
– We established another integration environment offshore (duplicate from the original one). We also build mock up environments for end systems, so that we can run end-end integration testing without depending on any other parties.
– Another reason for doing this is that offshore continuous integration also requires for a dedicated integration environment.
2. Manage cross team dependencies
Define project coordinator and cross team meetings
To solve the problem that each team has their own schedule, it is important to define a formal project coordinator role to coordinate between teams.
The coordinator needs to make sure all teams reach a consensus on the integration plan. Keep tracking each team’s status, make sure their schedule meets integration plan and keep the integration plan in good shape.
This could be achieved through periodical meetings which involve the coordinator and all the team leads.
Increase visibility of dependencies and issues
– Use wiki pages for publishing cross team artifacts (requirements, designs, interface definitions, etc).
– Use issue tracking tool for tracking cross team issues. – Jira is a good choice.
Each team should follow a high quality standard
This is to ensure high quality of each component (through unit test normally). In result, it will smooth the cross team integration work. – Cross team integration testing will not start when component’s unit test still fail.
3. Avoid vague integration design
In my opinion, a “detailed” integration design brings below benefits:
– Expose potential integration issues on the table early. This allows teams to have enough time to go through communications and solve issues.
– Smooth the work of implementation and integration. Things underneath get clear. This makes the most uncertain part ( implementation and integration ) estimable.
– Have the senior resource deal with the most challenging work.
A good quality integration design could include:
– A flow diagram and descriptions.
– Interface definitions and mappings.
– A list of technical difficulties and solutions.
– End-end test data if applies.
– A solution prototype if necessary.
The “detailed” design doesn’t need to be complex though.
Ensure integration design quality
– Design quality can be verified through cross team design review meetings.
4. Adapt to changes
Track changes on Wiki.
– Keep cross team artifacts up to date on the wiki page.
– Configure auto Email notifications to related parties when changes on Wiki.
– Once a change is handled, add a note on the page to indicate you have taken care of the change.
Write reusable tests and set up continuous integration.
– Reusable tests include: reusable unit tests, reusable integration tests, reusable functional tests. The GDC has tremendous experiences in applying continuous integration and test driven development. We have good experiences regarding setting up automatic testing framework and continuous integration for integration projects as well.
5. Plan properly – using check points
– We can define several “check points” representing states in an integration work bundle’s life cycle. Such as: Requirement review -> design review -> implementation (unit test pass) -> integration test pass-> functional test pass
– Having the check points defined will help us control quality of each step, know the exact status or bottleneck of the project clearly.
– It also helps plan and track the project. We can plan an integration work bundle across multiple iterations. Each iteration should achieve one or multiple check points completion, depending on complexity of the work bundle.
– We’d better plan enough time for integration designs. Consider separating design and implementation into multiple iterations to ensure quality.
Discussion: Agile vs. Check Point Control
Somebody can’t help asking: you are not doing agile here! Well, yes, this is a little different as our traditional agile.
As in traditional agile, we tend to focus on a small piece of work per iteration. We do simple design, and then quickly start building functional deliverable. This allows us to adapt to frequent changes and always deliver high value features to client. The reason we don’t do that in integration projects is because of integration projects’ nature. Cross team dependencies and the invisibility to other teams’ work could cause significant cross team communications, and is often a long process. That’s why it is hard to do simple designs and then start implementation right away in an integration project.
As far as using control points here, I would suggest that normally, we should plan work on check points one by one. Means the next check point work should not start before the previous check point achieved (Exception – test team can start integration test cases development when development team is still working on implementation, because they both depend on the design). This is to ensure quality of each step and avoid insufficient input for the next step. However, in some cases, if the integration is quite simple, this rule may not need to apply, the steps can still overlap. Then it becomes more “agile”.
In my opinion, choosing “agile” or “check point control” is all about balancing. If more “agile” – means simplified design, no strict check point control, work steps overlap. In result, we have light process to go through, and are more adaptable to frequent changes. But we have less control on the project and are very dependent on people. If we don’t have right people, the project could easily be in risk. On the other case, if we do less agile, and more check point control, then we’ll have a heavier process to go through, and we are not able to adapt to changes quickly, yet we’ll always have the control of the project.
In my opinion, “check point control” should be more suitable for integration projects which have longer schedule, not straightforward, and involve multiple teams. Just because pure “agile” is hard to apply in this case. We still embrace agile as much as we can. Examples like that we make sure high value integrations always get delivered first, and we stick to the test driven development approach.
