How can I inform my team when components are ready for integration?

Question

My team is developing a system with embedded and Windows components. Currently we have seperate repositories for the Windows and embedded platforms.

The rest of the team have concerns that there is not enough visibility of the current branch status to make assesments about user story completeness. The goal is to perform final integration for test as soon as we can.

It has been proposed that the solution to this problem is to roll the Windows code into the embedded repository and just have a single repo for the whole software deliverable. I don't think this is necessarily evil but I also don't think we are going to get the value we need for the work it will take to port things across and fiddle with the build plans.

We attempt to be a scrum team and run JIRA alongside Bamboo and Bitbucket. I believe the agile philopsophy, scrum method and the existing tooling present all the information needed to monitor progress on pull requests, branches and workflow across the project.

To solve team problems I always prefer behavioural solutions - it tends to cost less than yet more software over the long term. I quickly broached the idea of using the morning stand up and subsequent moments to actually talk to each other but that was not well received...

What stratagies can my team use to communicate the integration readiness of user story deliverables?

Answer 1

If you don't want to add a new tool then use what you have. I like that task descriptions are editable in most ticketing tools.

Task: 54328 - Make "Number of Dependents" spinner stop allowing negatives.

Description

Spinner fails to prevent negative input. Disallow this before user can click OK.

[x] Find relevant source code: TaxGUI.asp
[x] Correct behavior: added guard code to onclick method
[x] Tested and Peer reviewed: by CO2
[x] Pull request: issued against v1.1 bugfix branch
[ ] Integration: pending

Answer 2

A board filled with sticky notes (or a Jira board) is as simple as you can get. A glimpse on the board should give enough information about the progress of the team, and if it doesn't, it means that the board is wrong and should be corrected.

A real, physical board is usually better, because:

• It is more visual than any software ticketing tool I've seen so far. Don't get me wrong: I use Jira on daily basis and I enjoy using it, but I still find that in terms of progress visualization, the real board is more capable.

• Any person can see your progress just by physically passing through your office space. One doesn't need to start a PC, go find the link to Jira's board (one of the links everyone outside your team always loses), authenticate, etc. Moreover, being physically where the team is, the person may even ask questions if the physical board is not clear. “Hey, you told me yesterday that you finished changing the interfaces used by the ETL; so why is the task in progress?”

Nevertheless, would it be a real board or a virtual one, it should allow someone outside the team to understand:

• The current progress, that is:

  1. What you have done during this sprint,

  2. What are you working on right now,

  3. What you still have to do for this sprint,

• The priorities,

• The blocking points (bonus points if the reason of blocking is visible on the board).

Not only should it be able to communicate those points, but it should also be able to show it precisely. What often happens, especially when using virtual boards, is that tickets grow, and grow, and grow, and someone can easily spend five days working on a single ticket. This, by definition, makes it impossible to visualize progress. You could, of course, ask the developer what is his progress on a given task, but the answer would be irrelevant (see, for instance, the ninety-ninety rule).

So keep every task small enough. If a task takes two hours, that's great. If it takes one day, it's a very, very large task. If it takes several days, you have to split it into smaller tasks, in order for the board to reflect the progress of your team.

Once you do have tasks which are granular enough, “communicat[ing] the integration readiness” of a task becomes easy: either the task is done, or it's not. There is no 42% done or 85% done.

A few additional pieces of advice:

1. If integration is painful, it usually means that the interfaces weren't designed carefully enough. Sloppy work at this level results in hours, days or months of wasted time for both teams; do spend enough time designing the interfaces between your team and the outside world.

2. When it's difficult to design an interface or when it should be changed while both teams already started working on their respective parts of the code, do work together with other teams. Don't just do phone calls. Go see them, or invite them to come and work with you, side by side. I stopped counting the number of hours, days and months wasted by teams where members are just too lazy to walk to the other side of the office building, and decide to communicate by e-mail.

Answer 3

I think you have all the tools necessary to deal with this. No need to add or remove anything. If your team didn't perceive your proposal on communicating their progress, probably the approach taken could not be properly perceived by them. Moreover, collocating both tools in the same repository will not help more if the team already has issue integrating.

Your team is composed of multiple human beings. Human beings cannot survive in a group without communication. The same goes for a vision shared among that group.

The vision here is embodied in user stories, or, for the sake of completeness a sprint. Each little piece of artifact being produced that is part of a bigger system, MUST, provide a contract (or interfaces) to communicate with the system.

Taking the human being in a group example again, one MUST know the common language among the group in order to interact, negotiate or be aware of treats.

From that aspect, I believe that focussing on the contracts between these 2 systems can help your team find peace in integrating. Here are my suggestions:

• Reformulate your proposal in a different way and ask them question about it
• Have an integration server where both embedded system and the Windows components are constantly deployed after a change. From this system, you would monitor/verify with or without them the readiness of their user story
• Make integration testing part of the DoD (definition of done) of a user story. Either automatic or manual, a proof that it worked from another team member must be provided. With this, you could integrate a point system where well integrated pieces are rewarded