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?

  • So you suggested simply talking about it... and the team said no? Any specific reasons for that? If they want broader visibility, for example, could you put the information into the story tickets? – jonrsharpe Oct 12 '17 at 21:40

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.


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
  • I don't think this is a good idea; a few reasons I can think of: (1) this encourages long tickets which have progress in them, while a task should be small and be done or not done; (2) it's difficult to maintain, and most members won't do the effort; (3) it's too internal: if I need to know whether I can test the spinner, I don't care if you've found relevant code and I don't even have to know what a pull request is; (4) this requires to click on the specific task (which is technically two clicks in Jira)... – Arseni Mourzenko Oct 16 '17 at 19:23
  • (1) This allows independence from scrum masters who insist on long tickets. (2) How hard is it to type square brackets? (3) It's only internal because external has been rejected. You do care if I've found relevant code when I've gone on vacation and you're picking up my tickets. Pull requests are a git thing. (4) Yes, you do have to look at it to see it. Remember we're trying to make do with what we're allowed here. – candied_orange Oct 16 '17 at 20:29

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.

  • I agree with @Arseni Mourzenko. One thing I didn't see in the answer is use of a Kanban board as a way to achieve it. A state you might include on such a Kanban board is Awaiting Integration. It would become clear by looking at the state of the board what items are ready to integrate. I mention this so you have a good internet search term to learn more. – neontapir Oct 18 '17 at 22:45

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

Your Answer

