Inscrit(e) le :
31 Janvier 2012
Blogues : 33
Jeudi, 17 Décembre 2015
0/5 (0 votes)
Macroscope and Scrum - Part One

Scrum Smaller

We are still learning. Every now and then, somebody publishes a new set of theories or a new set of techniques which attract us. Sometimes these new things become wildly popular. But the problem is that some people take a “silver bullet” attitude – and believe the latest thing to be a prescription for all our challenges and dismiss everything else we’ve ever learned.

So our challenge is to take the best of what’s new, but keep our brains engaged with the big picture.

Let me elaborate in talking about Scrum. (I’m presuming the reader has some familiarity. But a quick search of Wikipedia and review of the Scrum Guide from Scrumguides.org will give enough background to continue reading if need be.)

The collection of techniques under the Scrum label has been with us for over 20 years, as a specialized outgrowth of the Agile schools of thought. And it has become very popular indeed in some quarters. We even find some who take the position that the Scrum approach should be followed with absolutely every ICT initiative.

Highlights of Scrum for Me - Roles

There are many aspects of Scrum that I admire very much. Some Scrum ideas are not really new, but the packaging is attractive. I’ll elaborate on some key features, with comments about Macroscope along the way.

The Product Owner

It is highly efficient to appoint one person who is completely empowered to translate the needs of the business to the development team and directly manage development priorities. There is close direction from the “voice of the customer”. Decisions can be made rapidly and the working solution – or useful part thereof - can be shipped sooner.

The Product Owner (“PO”) can be regarded as a specialization of the Macroscope Business System Manager (“BSM”). There are many aspects they should have in common. The key diffference is that the PO can be independent of the business. The PO is assumed to be empowered to and capable of determining what key capabilities are needed by the business, using whatever inverview/ analysis/ synthesis techniques as necessary to be the voice of the customer. (This approach is especially suitable to the world of “shrink-wrapped” software product development.)

Macroscope encourages the client to appoint the BSM from within the business. See this post for more: Also the BSM role has wider responsibilities than the PO for a longer period of time. In particular the BSM is not only concerned with the development of the solution, but also for making sure that the solution truly does contribute toward business outcomes to the level that was expected, and taking corrective actions when it does not.

Scrum Master as “Coach”

The Scrum Master role is highly focused on developing self-sufficient capabilities in the team members. This is an approach taken by successful leaders in any environment. But the fact that it is a core principle in Scrum gives a powerful boost.

Scrum has no designated PM role. The aspects of the PM role we see in other frameworks are spread among the Scrum Master, the Product Owner, and self-organized team members as they see fit.

The very first line describing the role of a Project Manager in Macroscope includes: … to mobilize and use wisely the organization's resources that are at his/her disposal to attain a specific objective: the successful completion of the project”. Macroscope goes on “…the project manager relies to a great extent on his intuition, impressions, feelings and personal judgment of people, much less on the tangibles—work plans, report logs—of the other management techniques. Leadership leaves no documentation. It consists of actions”. So while Macroscope does not have an explicit Scrum Master role, there is absolutely nothing to discourage a team that uses Macroscope as its knowledge base from declaring a Scrum Master in its team structure.

Multi-Disciplinary Team Members

My very first job title in IT some decades ago was “Programmer Analyst”. I had zero knowledge of the business to begin with but we were all encouraged to develop a rounded view of business and systems concerns. So when I see the Scrum teams having only “Developers”, I just like it. I see this as an excellent technique to help everybody focus on the big picture, and to encourage ideas from everybody to help improve the product and the process.

Macroscope offers a wide variety of role names. These may look too granular for some situations, but these role names are there tohelp one see the skills and experience required in order to do various things, so one person can readily play more than one role. So while multi-disciplinary team members are not presented as a requirement, there is certainly nothing in Macroscope to discourage that approach.

Self-Organized Teams

Much has been written over the past few decades about “self managed teams”. When it works, it works! The teams are more productive, they create better quality work, and they find it highly satisfying. This is an approach taken by successful leaders in any environment. But the fact that it is a core principle in Scrum promotes this leadership style.

Macroscope does not explicitly recommend self-organized teams, but it gives explicit guidance to give team members authority and latitude to participate in decision making. Macroscope also advises the PM to adapt the leadership style to each person’s level of maturity. So one would expect to see a healthy level of self-organization in a well led team (using Macroscope or other frameworks).

812 vue(s)