Monthly Archives: March 2018

Scrum hoax #1: The black box syndrome

Better transparency is one of the key value proposition of Scrum and one of its pillar. Several parts of the framework are designed to help it and make sure to keep stakeholders aware of the progress. More often than not, this does not work as expected and Scrum is blamed for that. It is a … Continue reading Scrum hoax #1: The black box syndrome

Fighting lack of transparency in your Scum implementation

Better transparency is one of the key value proposition of Scrum and one of its pillar. Several parts of the framework are designed to help it and make sure to keep stakeholders aware of the progress. More often than not, this does not work as expected and Scrum is blamed for that. It is a perfect opportunity to open this series of articles around the Scrum hoaxes. In today’s article we will discuss the black box syndrome some organizations encounter while implementing Scrum, and cover the possible causes and solutions.

Some times ago, I had a discussion with a senior product analyst about how Scrum impacted its organization. Like some people complaining here and there, he was not happy at all with the methodology. Bottom line, the issue was that since the implementation of Scrum, the teams around him were completely black boxes. A common issue indeed, that may come at very different stages of Scrum adoption. It is very sad because it is usually due to a bad way to Scrum. This situation, like all the others of this series of article, is not due to Scrum but to how it is implemented.

So how a team, after implementing Scrum, can be perceived as less transparent than what it was before?

Obviously, it comes from the fact that some aspects of Scrum are missed, but it is not so trivial to see what is wrong.

I will share below the most common category of mistakes I have encountered.

Case 1: No (or ghost) Product Owner

Yes, I have met teams where the role of PO was simply not filled. The Product Owner being in charge of the product backlog, the issue is obvious and immediate.

A very similar flavor is the Product Owner is appointed but too busy to take care of the backlog, or not trained to or convinced by Scrum. At best there are a bunch of badly written stories, at worst nothing at all and the Product Owner sends an email to the Scrum master here and there to ask for things.

Without a proper and up-to-date backlog, no visibility on the product, either inside or outside of the team.

To get out of this situation, the organization needs just to take the subject seriously: the role of PO is critical to a working Scrum team. He should be knowledgeable, accountable, available and invested in the product. You could be interested in reading about the technical skills of the PO.

I would love to say that this is the least frequent case, but sadly it is much more common than you think.

Case 2: No (public) demo

The sprint review meeting is the opportunity for the Scrum team to demo the proposed product increment to itself and potentially key stakeholders. It is as well the opportunity for the PO to decide to release this increment or not.

The first possibility is for this meeting not to be held or to be badly run. Relating to the previous case, if the Procut Owner does not attend this meeting it will be extremely hard to discuss with stakeholders what has arrived and what should come next.

In the situation where the PO is there, but if no stakeholders attend to this demo meeting and if there is no other way for them to see the increment and provide feedback, it naturally results in poor transparency on the Scrum team output.

Our advice here would be to invite key stakeholders to the review meetings to provide them the best visibility.

In addition, especially if the point above is not doable in your particular setup, you should put in place the means for the feedback loop to be available. It depends heavily on what comes next to “Product Increment is shippable”, i.e. the path to users after the sprint.

A solution can be a webinar (for very large audience), a platform to demo your new version, a recorded demo sent to stakeholders or even some canary testing on your production environment. We will cover more on these possibilities with articles on release management but in any case you need to put in place a feedback loop.

Case 3: Private backlog

If with the situation of secret project put aside (military or equivalent), this is astonishingly frequent: the team has a backlog that no one can see outside of the team.

You cannot expect the stakeholders to participate if they cannot see what the product owner has in mind and how their feedback is taken into account.

The solution is obviously to make sure the backlog is available to your stakeholders. The clearer the backlog is the best, so the tool selected should have a good navigability and it should be obvious how to find your backlog.

Case 4: No roadmap

With case 1, 2 and 3 covered, you have a reasonably well written backlog and a two-way communication is established between the stakeholders and the team about newly built product increments. The next source of issue is trickier: what comes beyond the current sprint.

Most organizations and actors in the field of software edition (and engineering in general) are expecting a form of roadmap. Yes, it is usually not reliable and not adaptable. It is not meant to be a commitment on the few next months, but it is valuable to give some visibility on what you hope to accomplish.  

Looking at a way to get Scrum roadmap easily? Check out Stenusys Scrumboard that provides an automatic planning on your product backlog.

Case 5: No readability on what the stakeholders want

A backlog gets denser and denser as long as you are getting closer to the next sprint items, as you will detail more and more the content of the stories. From an external point of view, it may be very hard to find out how a suggestion or request has turned into a list of stories.

A good way to do it is to differentiate the stakeholders’ requests from the stories themselves. You can use epics, but it can get complicated for different requests fulfilled by the same stories.

The best option is to distinguish the requests from the stories of the backlog and make sure each request is updated based on the status of the stories implementing it.

Find out how this works in request management of Stenusys Scrumboard.

Case 6: Private Sprint Board

When some critical stories are under implementation, stakeholders may be interested to see if everything goes ok. It is not that they can do a lot about it in most cases but that sure means they may not appreciate to wait until the sprint demo to get news from you.

To make sure the information is available at any time, without a need to compute manually reports, it is a good idea to have a sprint board fully open and easily accessible. The best option is to have your backlog browsable in your Scrum tool.

Conclusion

Closing up, transparency is one the key value in a business relationship. It is required to setup the viable working environment you need to work efficiently, based on trust between the team and its stakeholders. 

If well applied, Scrum is a great enabler of transparency. By following the suggestions proposed in this article you should get one brick to put in place a healthy product engineering team. More to come...

You can get help to implement Scrum !

 Visit our website for more information on our offers

A branching strategy for Scrum using Git

Scrum is a great framework. If you do not know it, you should check it out and then come back here ! Defining a branching strategy suitable for Scrum is not so simple, here is a proposal. Scrum is designed to develop product among iterations (called sprints). The sprint backlog contains stories which represents the … Continue reading A branching strategy for Scrum using Git

A branching strategy in adequacy with the Scrum model.

Scrum is a great framework. If you do not know it, you should check it out and then come back here ! Defining a branching strategy suitable for Scrum is not so simple, here is a proposal.

Scrum is designed to develop product among iterations (called sprints). The sprint backlog contains stories which represents the work to do in the scope of the sprint. At the end of the sprint the Product Owner will decide if the proposed product increment is accepted or not.

It is common for Scrum teams to have strong difficulties with the branching strategy to apply to the product they are building. As a matter of fact, the expected level of collaboration on each story, the need to propose a shippable product increment, the different stories that may or not be sent in the end, all these specificities of Scrum make it challenging to find the proper way to stay clean and consistent with the code repository. That’s the reason why the branching strategy must be in adequacy with the Scrum model.

In this article we will present a branching model for Scrum using Git, oriented towards team collaboration and continuous integration. If you doubt this is worth investing some time, you may be interested in why software engineering matters.

The master branch

The development will start from your reference branch. You call it the master branch, the develop branch or by any other name. It is the one that reflects the level of code approved by the Product Owner as being ready for the production. In the scope of this article we will call it master branch. 

The sprint branch

The sprint branch aims at containing commits of completed stories, the ones that will be presented to the Product Owner during the sprint review. This branch can be seen as the “ready for demo” branch.

At the beginning of each new sprint, its sprint branch is created from the master branch (i.e.: sprint/S01). This operation can be managed by the Scrum Master for instance. It is also helpful to tag the branch at this point (you will understand why in ‘failed stories’).

The story branch (and the relevant-atomic-clean approach)

As soon as the sprint starts, a dedicated branch for each story will be created from the sprint, following a naming convention that has to be decided. It can be of the form story/S01S01, story/S01S02… Which would be read sprint 01/story 01, sprint 01/story 02, …

The important point here is that the story branch is fully part of the model. It can be seen as a  reference branch for the development of a specific feature. Even if it is a short-lived branch (like described in the popular Trunk Based Development model), it should not be considered as a "garbage" branch. More precisely, commits that will be pushed to the remote story branch should be relevant, atomic and clean. For instance, the remote story branch should likely not contain commits description like ‘working on story 2, WIP’, or even ‘fixed typo in MyClass.java’.

The cleaner the commits are in the story branch, the better the code history will be.

Branching strategy for Scrum, the big picture

Commits and interactive rebase

Of course, in the day-to-day work, the developer working on a story wants to commit his ongoing work, like a checkpoint so he knows he can restart from this point if anything goes wrong after. While implementing the story, this can end up with several commits.

Before pushing the commit(s) to the remote story branch, he should ensure that these commits are atomic and relevant. Performing an interactive rebase ("rebase -i") will allow to squash relevant commits between them and write a meaningful commit message if needed. The dev team can agree on the commit message format, like : “Story 654 – Switching from log4j to logback”, where 654 would be the story id in the product backlog, followed by a meaningful description. Only when this operation is done, the commit(s) can be pushed.

In a story branch, a pushed commit is a commit ready for code-review.

Working together, and merge-request for code review

Once a commit has been pushed, the dev team member should create a pull-request (also called merge-request) to the sprint branch in order to ease with the code review. There is no need to wait for the story to be completed to perform the merge-request: the code-review may start before the other parts of the story are implemented. But of course the story will not be merged in the sprint branch before the implementation is complete (i.e. the story is put in the column DONE in the sprint backlog).

TIP: GitLab (for instance) will prevent the branch from being merged as long as the merge-request’s title starts with “WIP:”

The code-review phase can generate one or more additional commits that cannot be squashed to the code being reviewed. That’s an acceptable state.

If several developers are working on the very same topic that requires sharing portion of code being developed, it might not be a good idea to work directly on the story branch because it would break the relevant-atomic-clean approach. Instead, they can consider branching from the original story branch or even forking the project. That way others can contribute to this temporary branch which can be interactively rebased at the end, creating new nice and beautiful squashed commits. 🙂

Story done

When the story finally meets the done criteria and the code-review is completed, it can then be merged in the sprint branch. That means the story is “ready to be shipped” from the development team point of view. All tests (unit tests and integration tests) should be rerun at this stage.

The code level in the sprint branch is the one that will be presented to the product owner during the sprint review ceremony. Uncompleted stories should not be merged into the sprint branch.

It is important to keep in mind that stories in a sprint branch (i.e. in the “done” status) has the purpose of being accepted by the Product Owner. To maximize chances, it is essential to work as closely as possible with the Product Owner. The situation of a story seen as done by the dev team and finally failed at review time should be extremely rare.

The review during the demo

During the sprint review ceremony, the product owner will review all stories of the sprint backlog. He will decide whether each story passes or fails. If you are running Scrum in a strict mode, one failed story will fail the sprint! The consequence is that none of the stories will reach the master branch at this point. The reason is that the product owner acknowledges the stories being ready for production on the very code level being presented during the review. If a failed story is removed from the sprint branch afterwards, the resulting level of code has never been reviewed and thus should not be accepted.

If all stories have passed, the sprint can be merged back to the master branch. This operation is called the delivery.

The Git tree representation of the branching model for Scrum (general case)

Failed stories

If the Product Owner has rejected at least one story, the whole sprint is failed. The way to deal with failed stories may vary a lot depending of the failure type and the Product Owner’s point of view on this. There is actually no unique answer, but here is some global leads:

1st case: the failed stories can be fixed easily.

If the failed story can be fixed easily and quickly, the Product Owner can agree on keeping the story for the delivery. The dev team will fix the sprint branch and will rerun all tests. The Product Owner should accept the fix based on the evidence usually required (test results) or a short informal demo.

2nd case: the failed story has to be removed from the delivery.

That’s the touchy case that should be handled carefuly. Here are three different kinds of approaches:

1/ Commit(s) of failed stories are reverted in the sprint branch.
This is an easy operation if story’s commits are atomic. But if this kind of operation is often done, this will lead to a dirty code base.

2/ A new sprint branch is created from the original one (like ‘sprint/01-take2’), identified by the tag created at the beginning of the sprint. All story branches of approved stories are merged into this new branch.

This is a tedious operation but the code history will be cleaner. This is a safe operation as long as the sprint branch does not contains special commits (last minute fixes for instance). That’s easy to forget those commits, be careful!

3/ A new branch is created locally from the actual sprint branch (like ‘sprint/01-rebase1’) and interactively rebased upon the original sprint branch (identified by the tag created at the beginning of the sprint). That way, only accepted stories are picked and there is no chance to forget any relevant commit.

This is the safer method, but this will generate new commits due to the rebase nature, losing the merge information of the story branch.

In all cases, the strategy should be proposed to and accepted by the Product Owner. He can decide that this is too risky and reject the product increment as a whole. The stories will then be integrated into a new sprint.

Continuous integration: some keypoints

This branching strategy works well for continuous integration.

On story branches

- Every single commit pushed to the story branches triggers at least the run of the unit tests. That’s one of the reason behind the idea of not pushing partial/work-in-progress code to the story branch. If it can technically trigger more tests, it should. The earlier the tests are run, the better

- When the story development is complete, the integration tests should run. The trigger to this operation can be defined in several ways (a tag on the commit can be an option for instance).

On sprint branch

- Once the story is merged in the sprint branch, the whole pipeline should be run (including the integration tests). This will ensure that no story broke another one.

Conclusion

I have implemented this Scrum branching strategy successfully in several companies. Of course this is not the only possible solution, but from my point of view it takes a good compromise between respecting Scrum interactions and maintaining a clean code base. It can cope correctly with the different scenarios a Scrum team can encounter. 

That is however not the end of the story: not all code changes are necessarily done in the context of Scrum. Maintenance operations and urgent fixes may follow an alternative (and complementary) process. More on this in a future article.

You can get help to leverage your software engineering !

 Visit our website for more information on our offers