Saturday, March 17, 2012

Do Scrum or be Scrum – remembering Scrum Values and other aspects in Scrum


When you discuss with people in an organization which claims they do Scrum, what do you observe? Typically, I see a lot of Scrum “process” mindset. Yes, there is sprint planning, sprint review and daily scrum. And yet, once I look closer, it appears to me rather “hollow”, superficial.

The other/softer areas such as a scrum team is cross-functional, self-organization and scrum values are often ignored, yet essential in order to achieve the desired business goals. And it is those business goals which you try to achieve by means of doing and being scrum.

A scrum team is supposed to be cross-functional i.e. the people in the team have competence in architecture, design, coding and testing – do you see all of those in a single team? The worst case I have seen is a dedicated “scrum” team for architects, developers and tester. This is not scrum.

Self-organization is often another area of confusion. What does it mean to be self-organized? How to get there? Those are big questions, they deal with how much responsibility one is willing to take and how much managers are willing to let go. Nevertheless of the difficulties, self-organization is key for a team to become a high-performing team.


Did you remember that Scrum contains also values? Those Scrum values are:
FOCUS
COURAGE
OPENESS
COMMITMENT
RESPECT


Often, people are not aware of them. And if, then the interpretations on what they mean differ from person to person. Similar to a previous post on Agile manifesto and principles, I suggest that you discuss those values in your organization and figure out what they mean for you – better even if you can invite an Agile Coach from the outside, to get a out-of-the-box view compared to your own.

When looking at various Scrum training materials I have been missing those values – they are simply ignored. And then, I just tried to check them from scrumalliance.org and … nada – nothing there either (ok, maybe I might have not spend enough time for searching, however it seems that all the certificates are more important then the scrum values).

What can I do to help this? In future scrum courses, I will put more focus on those other/soft aspects.



p.s. I just saw a job add for a “Scrum of Scrums Master” - OMG!



Monday, March 12, 2012

Area Product Owner – more negotiator and less entrepreneur?


I've been giving a fair amount of Product Owner trainings and mostly to people in organizations which are BIG. BIG here means 10+ ... 30+ Scrum teams or even 80+ Scrum teams.
Ok, they are not always “real” Scrum teams, based on the definition. Sometimes they are more component team and sometimes, those teams can do a piece of end-to-end functionality.


The typically audience in those trainings consists of all-sorts-of-architects, assigned Area Product Owners, project managers (not THE project manager – more kind of sub-project manager) and others who have a word in saying what others should or should not do. Occasionally, I see THE Product Owner.

In those trainings (more or less following the ideas of the Certified Product Owner trainings from e.g. the Scrum Alliance), the people often feel that what I talk about is too theoretical (nice to know and irrelevant). This is due to the fact that the participants don't e.g.,
  • create the product vision
  • define business models
  • cooperate with customers
  • estimate value of backlog items
  • decide about scope/schedule priorities
  • decide issues related to the product life cycle

What do they do then?
I differentiate two main cases: (A) The Area PO (APO) serves a single PO and (B) the Area PO serves several stakeholders e.g. several PO's, PO and Program Manager, PO and LMs (e.g. acting as fault coordinator). I will focus on case (B) as this was the setup which I faced in my experiment (and in many trainings). Case (A) is a subset of case (B) and the reader is free to pick what fits and ignore the rest.

Reality check: The higher level dependencies as well as higher level flow (e.g. to System Verification) are “managed” by somebody else then APO. The APO typically is not discussing with customers – only with development internal stakeholders. The requirements are broken down by somebody (often an architect at a higher level) before they reach the APO (and this reduces the importance of discussing User Stories in my trainings).

In the end , the APO is responsible for the “area backlog” (often a separated backlog instead of having ONE product backlog with sections for the different product areas) which might still contain end-to-end product features and functionalities as well as requirements with dependencies to other areas. The remaining real work with the backlog is to make the different stakeholders understand that the sum of all their needs (wishes, demands) is far too much compared to what the teams can handle.

Thus the key role of the APO is to bring the facts on the table and to facilitate the negotiation between the various stakeholders. The APO does not prioritize the items, the stakeholders need to do that part. Those facts – made visible by APO - are based on real velocity/throughput data, team estimates, identified risks, dependencies within the product area, new functionality vs. improvement actions etc.

How to train people to become a professional APO in such an environment?

Sunday, March 11, 2012

My experiment ended and this blog will go on


My experiment of being a Scrum Master ended last Friday with the Sprint review and retro. I still have plenty of “undigested” observations and findings which I want to share here, so the blog will still continue for a couple of weeks from now.

The last two weeks have been rather busy with all sorts of workshops, trainings and individual discussions. Maybe because the people around me realized that my experiment comes to its end or simply others realized that I might provide meaningful comments, feedback and suggestions.


Stay tuned for more …