Strictly left footed right wing striker

Background: The Pune vodQA 2012, where I was involved, but not entirely committed(A frivolous reference to Scrum lore, about commitment, chicken and pigs) in more ways than one, was interesting instructive and illuminating! Read about it here.

Mr Chaitanya Nadkarny, a senior member of Thoughtworks consulting gave an opening talk, covering among other things which factors are going to affect the lives and careers of testers. One point he made was with regard to how testers can be generalizing specialists, or specialising generalists. It took some time for the audience (at least I did take time) to get it’s collective head around this.  Mr Nadkarny’s point here was that

One could be a performance tester (specialist), but also interested in expanding capabilities (therefore generalising) to do general functional testing, manual etc.

OR

A tester (generalist) now wants to be more skilled and focus on an area of testing, for example usability (specializing).

MAIN POST:

Since I see the world through Scrum tinted glasses, I’ve been struck by how Nadkarny has put in a nutshell the possibilities of how people develop, become more valuable and competent. Many years ago a programmer was doing most if not all activities in relation to developing systems/applications, including testing. As the field developed people became more and more specialized. Eventually in the noughties, we have extremes of specialisation. Even being a tester isn’t enough of specialisation, one is now a manual tester or an automation tester, or a performance tester. The side effect of the industry moving in this direction is that people are squeezed into ever narrower roles, even though this isn’t required and actually creates inefficiencies. Finally we have the equivalent of a striker who can only play on the right wing,  kick with his left foot, but will not head the ball into the net, even if the ball is at eye level, straight ahead and the keeper is out of position!

This attitude is so entrenched  and pervasive in some places that even managers have often fallen into the trap. People are type-cast and given no opportunity to learn new things. The Scrum team, essentially being cross-functional, would struggle to succeed if a group of super-specialists have to work together, even if they are initially willing to collaborate. Why so?

Firstly: There is little understanding of what the other person does and needs.

Secondly: Load balancing at different points in a sprint is a nightmare, as work of a given type isn’t evenly loaded throughout the duration of the sprint.

Thirdly:  Majority of work in any organisation is done by generalists, because much of the work doesn’t need a too much of specialization. How often have you visited a general practitioner vs a specialist?

Lastly and very importantly: it encourages the continuation of waterfall habits.

Time to generalize. A cross functional team would need generalizing specialists.

On the other hand, once they get there, they might then need to be specialising generalists, as well… and so it goes.

Advertisement

Developers are people too!

I happened to come across this absorbing article: Whales are people too! and in then the word speciesism (a one word tongue twister, say it out loud, quickly, twice in a row!)

Now, I’ve lost of count the number of managers/executives who proudly say that their organisations are doing Agile (whatever that means ) and refer to people as ‘resources’. In light of Mr D. Adams’ observation (that humans are the third most intelligent species on earth) it is possible that these enlightened managers are right after all. We are all resources.

However, on a serious note, it is worth considering, since dolphins have a strong claim to rights, if our developers also need some rights.  Also more pragmatically, always keeping  this in mind makes management effective, and true; Not a wished based glossing over the real people development and attitude issues and avoiding necessary but difficult conversations until it’s too late. A team of people, are not simply a summation of individuals, and their interactions can easily be unpredictable, someone leaving the team, could result in a productivity increase, or even velocity increase. If only developers were people.

N.B: Prima facie this is tangential, but on second glance quite central to Scrum. In this article I’m not being sarcastic, but tongue-in-cheek. (Note on N.B to some readers: These things have to be explained to most ‘resource managers’  in the ICT industry)

What can be done when the PO isn’t empowered?

A fairly common situation in organizations is the presence of a PO without authority. It is common for a BA to play this role, and mainly due to the mistaken belief that functional knowledge is  the only criteria for a PO. Also the term ScrumMaster suggesting an all important person in a move to Scrum, contributes to this thinking. As in many things the best course of action is to preempt this situation by educating the rest of the organization (before) the start of Sprint about the roles of SM and PO. Once the realization set in, that the SM is not responsible for the delivery on a sprint to sprint basis, and in terms of delivering the product to the customers, people outside will turn to the PO. The PO will then slowly take on a stronger and more meaningful role, suffused with responsibility.  In my experience, coaching project teams and organizations, this take some time. The first level of understanding come about in 3 to 4 sprints, but deeper understanding typically takes a release or two (maybe 3 to 6  months). What one can do to make this more visible:

1. Re-iterate that Scrum is a radically different system of running software projects.

2. Encourage interaction between team and PO, as well as PO and external customers/client.

3. Explain to all concerned that while the team is largely responsible for “building the system right” every sprint, the PO is reponsible for making available “The right system”. While the team is collectively responsible every sprint, the release to the customers is the responsibility of the PO.

4. In addition for a release the PO is ultimately responsible for delivery of the “right system right”, in other words the appropriate system which is shippable (i.e of high quality)