Joined :
31 January 2012
Blogs :33
Thursday, 17 December 2015
0/5 (0 votes)
Macroscope and Scrum - Part Two

Highlights of Scrum for Me - Techniques

User Stories

To me, one of the most powerful contributions of Agile and Scrum to our profession is the focus on the User Story (along with the Use Case). The simple statement, “As a ___ I want to ___ so that ___” gives us an intuitive yet fairly precise view of the business capability that is needed and its justification. It’s easy and it’s natural.

In the 1990s, the Macroscope team adjusted its approach to the Unit Task to harmonize with and provide a “home” for the Use Case. This is a nice illustration of how Macroscope evolves to incorporate thought leadership from the public domain as well as that from inside Fujitsu.

Macroscope encourages us to think first about the use case of the Unit Task, then about the variants. A User Story might correspond to one of several Macroscope constructs – a work process, a unit task, a task step or (most often) an alternate flow within a unit task. But anybody can use the concept of a user story in any framework.

Time-boxed Sprints/Iterations

I use these terms interchangeably, though there are some special aspects of a Scrum sprint outlined below.

The techniques of continuous integration of small increments became popular in the early 1990s, and everywhere I go in my travels, these are now considered mainstream approaches. And the technique of planning and budgeting by a time-box has also been used for quite some time – when conditions permit.

But with Scrum, there is the added focus of a potentially shippable product increment with each and every sprint.

Also, sprints are typically all of the same duration for a given team. At the start of each sprint, the team decides how many product backlog items it will include in the upcoming sprint. Since it is much easier to estimate the work directly in front of us, sprint teams quickly become good at predicting what will be “done” in the upcoming short period. So I like this aspect – the Scrum approach enables an accurate view of progress against the prioritized list of backlog items.

This approach is highly suitable when it is more crucial to “get something useful out the door quickly” than to deliver a more complete solution in the first release. But I don’t actually see this situation very often! So I confess I really struggle to find value in the notion of a potentiallly shippable product increment with every sprint/iteration – when so often the business has absolutely no appetite for a small subset of a workable solution.

The Agile solution delivery process in Macroscope differs from Scrum in this respect. Macroscope suggests planning by release, and then setting up a planned series of iterations toward that release. So we have an iteration zero to set things up, any number of highly agile functional iterations (not necessarily of equal length), and then a pre-release iteration. (Macroscope then has a distinct Release Implementation phase, something not included in Scrum.)

Continuous Improvement

The mindset of continuous improvement originated many decades ago, long preceding all system delivery frameworks. And it is explicitly incorporated into Macroscope and many other frameworks. But I like the way that Scrum features the review and retrospective meetings as important and explicit parts of the Scrum framework.

675 view(s)