As Agile practices have
been communicated to all segments of industry, you see well meaning but
completely clueless recruiters and HR groups post the most interesting
requests. “SM/BA desperately needed”, “SM required, must have 10 years
Development experience”, “Looking for Agile PM, SM certification a must”. It is
almost as if the organizations want to tell you how mature they are, and how
much they understand the Agile “fad! But really, it is almost an aspect of
human nature – we all want to get more for less, we all are looking for a deal.
This is just an attempt to get two roles for one person. And while you can
combine some roles, others just don’t work out so well. Today, let’s talk about
one of these toxic mixes – the SM and PO, speaking to the SM/BA combination.
Scrum is actually
relatively simple. It has 3 roles, and 4 ceremonies. If you follow these
tightly, you will only need a little help to make things go well. But it does
require some pretty tough things to get – namely Trust, Transparency, and
Communication. These are so hard to get, most organizations struggle to keep
whatever they accidentally have in place! Given this, and the market for Agile
roles (coupled with the expense for those who know how to do it well) it seems
very simple to try to get a person that knows how to “do” agile to take care of
the somewhat simple sounding process. In the industry, we call these “coaches”.
But in the market, companies are willing to take anyone that will take the risk
and that has a little bit of a proven time record.
In some cases, I have seen
some role combinations work. Usually, when I do see this is when you have a
small company do Scrum well out of necessity. If it is survival or death, and
you have intelligent, willing people, you can almost make anything work out!
But when the company grows, or the person shouldering the multiple hats trips
up, it can result in chaos. So just to bring us back to focus, the three roles
are the ScrumMaster, the Product Owner and the Team. Each of these roles
performs critical tasks to enable one thing – the team to produce working
software for the user. The Product Owner is the representative for the User,
and the ScrumMaster enables and allows the team to do it’s job to the best
possible manner. In addition to this, there is a critical part of the PO’s job
that simply cannot be replaced by anyone else. It is the reason most IT
“Product Owners” tend to be dismal failures. And it has to do with pure and simple
ROI.
The thing that a Product
Owner must provide for project and team success is VISION. And that vision must
be more than “code is cool” or “look at the new toys/gadgets I built in”. That
vision has to do with how the User will interact with the product, and whether
anyone will or will not pay for the potentially shippable, uber-cool code that
the team produces. Because if no one pays for that cool code, there really is
no reason for the team to do it’s work.
I know, I know – many fine
PO’s from the IT side of the house have yielded great and successful projects,
and I should not generalize in such broad and hurtful statement. But based on
my limited vision and experience, most of the time an IT PO results in unneeded
pain, loss of focus and team frustration. Because people in IT are too much “in
love” with pure coding and technology. And when critical business decisions
need to be made, most IT people are simply unequipped to make them. I have seen
business PO’s not be able to provide a vision, and the performance patterns of
these teams mirror the IT lead teams in a bit of an eerie manner. And as an
ex-ScrumMaster, although anyone can technically fulfill the roles in Scrum, I
can tell you that understanding users belongs to a defined discipline (UX) and
getting the best ROI, and making the best decisions, and getting the product to
market belongs to the business side of the house.
No comments:
Post a Comment