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

Limitations of Scrum

The Scrum Guide makes it very clear that Scrum is a process framework to manage product development, but it is not a process or technique for building products. The comments below elaborate on some outside-of-Scrum aspects that can be necessary for a successful system delivery and implementation, with some references to where these are addressed in Macroscope.

Architecture and Integration

Scrum itself makes no reference to the question of architecture. It kind of assumes that some level of overall architecture exists. It doesn’t speak to the need for necessary and sufficient system architecture and the need to integrate into the architecture of the enterprise.

So somehow, in a Scrum approach the Developers must be knowledgeable and aware enough to sketch the architectures as necessary during Sprint Planning and to update these as the product evolves. Otherwise there is a risk that the product will become unmaintainable and have a very short lifetime – which is just fine if obsolescence is part of the game plan but …. There is also the risk of creating components that are duplications of other elements in the enterprise environment, leading to flawed and unstable systems.

A related issue is the Scrum presumption that the only “product” is software. The Macroscope mindset is to think in terms of business systems, with some components that could be manual. This gives a more complete view of all the services the system must provide to its stakeholders. This in turn can lead to innovation in work process design. It also facilitates true end-to-end testing.

So a team using Scrum techniques to manage product development might do well to use other elements of Macroscope to build maintainable and long-lived systems. Macroscope explicitly draws our attention to integrate with whatever might exist of the enterprise architecture, and encourages us to manage the system architectures in iterations and concurrent engineering of all components.


Now this may be due to my limitations of working in a consulting environment, but I believe it is very rare for a client to engage a system delivery team with only a rough idea of what they will get for their money. So in my world, even though the client will ask us to be highly agile, there is always some need for a plan-driven approach, which means we need to figure out the architecture in enough detail for a reasonable estimate. These necessary realities of my world are alien concepts in the Scrum world.

Testing your own work?

It is a cliché among experienced systems developers that it is impossible to truly test one’s own work because of our blind spots. So again, experienced members of a Scrum team will know this and organize their work to ensure another set of eyes is always involved in QA and testing.

But it still might be helpful to have some rigor and formality in the management of product quality – as we find in Macroscope and many other frameworks.

Management of Organizational Change

My biggest reservation about Scrum is that it can seriously impair organizational change management (“OCM”). If the product is a stand-alone piece of software that will be shipped to the outside customer base, this is less of an issue. But if we are looking at a major innovation in the way an organization will work with a new system, lack of OCM can seriously reduce the value the organization achieves with the system. In a worst case, the entire systems effort can be wasted.

The very features of Scrum that provide speed and agility can put up a barrier against the business stakeholder community until late in the game. Business stakeholders can provide input and feedback, but they do not participate in decision making.

With a more complete framework such as Macroscope, the business stakeholders are engaged at every opportunity – to ensure business alignment and to provide opportunities for influence. For example, teams of subject matter experts can participate in work process redesign. Key users can directly influence the evolving prototypes of user interfaces and the capture of business rules, etc. And testing by business stakeholders overlaps development whenever practical.

Macroscope recommends specific activities for OCM from beginning to end – with business participants taking the lead.

470 view(s)