Tuesday, March 26, 2013
No, your ScrumMaster will not just “whip up a backlog” for you
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.