I think the only way to develop good teams is to develop a number of teams, then see what they can do. There's no currently popular methodology that will guarantee developing good ones. Y-Combinator seems to come close, but really, they are trying to encourage favorable preconditions, then letting groups succeed.
In all honesty, the best factor to succeed is to have good people in the team. If you don't have that, you are never really going to get past that factor.
Provided you have that, I believe the greatest success factors are outside of the scum team and that the effort to improve working conditions should be concentrated there.
Though I'd love the idea of a methodology race, where the fittest win. Wonder if there ever is an organization open minded enough to try this...
> Though I'd love the idea of a methodology race, where the fittest win. Wonder if there ever is an organization open minded enough to try this...
Every organization does that, to a degree, unknowingly. I know a (secret, undisclosed) organization where we (er, they!) do Scrum but if you analyzed what the teams actually do you probably wouldn't guess they follow anything resembling a single recipe :)
Curiously it seems to support the thesis of the article. I believe that all of the teams have some sort of a backlog and focus on making it good. The difference is that while the author strikes "prioritized" we, the devs, are more focused on "well specified".
I've experienced this in my own 7-year practice as CTO of an agile rails consulting shop, growing from 2 to 20 people while working with dozens of clients ranging from government agencies to VC-funded startups and self-funded single founders. Some of these projects have been extremely successful, while others have resulted in high-quality software which never saw the light of day or met real user needs. I would estimate the ratio of success to failure has been 1:5. It's deeply disheartening for me, and for the outstanding development teams I've built, to see work we have put months or years of effort into collapse due to lack of focus and clear, cohesive product management and vision.
The successful clients all had someone inhouse they could dedicate full-time to defining a well-structured backlog, grooming stories, balancing feedback from stakeholders, acceptance testing work, communicating with design and development, and generally acting as the unary executive voice of the product.
SomeONE. And the problem is that the role here calls for both executive, rather than committee, function and requires a broad generalist skillset. A good product owner needs to think analytically, write clearly, communicate firmly and negotiate competing needs and priorities. They need to be comfortable discussing technical details, even if they are not themselves technical. They need taste and understanding for user experience, even if they are not themselves a designer. They need delegation skills and a keen editorial instinct.
There are many more people with money to build software than with someone in-house with a matching set of aptitudes and is available to own a project.
Instead we get a group of department heads, with overfull schedules and competing needs. We get people who come to us with ideas for apps they are sure will make them wealthy. We create beautiful software for them, they "launch" in the App Store, and we never hear from them again. We get VPs of Product who spend more time in endless fundraising meetings than talking to their customers and development team.
The real surprise is that the success ratio has been this high.
I believe the problem lies in the difficulty of fully grokking the project owner role. It's nontraditional and not very glamorous.
Department heads are not product owners. In fact, I am a firm believer that being in any way responsible for staff is generally incompatible with the product owner role.
Yep, which just adds to the implausibility of this person existing on-hand in an organization. But if we can't find product owners in the wild reliably, how do we as consultants help nurture them in the projects we are engaged in, and help our projects and clients succeed?
That is quite a problem, especially since the product owner should ideally be someone with a vested interest in the product, which sort of implies that you cannot use a consultant as a ersatz product owner. Unless you intend to keep the consultant on for basically forever.
I has the luxury of working with a good product owner once. We recruited him for the task at hand, so he had no background in the organization doing nothing other than his PO duties. This turned out to be a great boon, and managed to avoid the usual pitfalls of developer-turned-PO or boss-also-doing-PO.
I'm not sure if we can find them reliably but we can reliably identify them: you need an engineer (better: a system architect) tinted with things like "usability", "UX design" and similar. He or she will be technical enough to drive the development team as a PO and have enough social skills to extract information from the client. A consultant will be fine -- maybe even better than a person from within the client's org.
I've experienced the same problem, and I attribute it to the culture of "no accountability" in so many organizations, both large and small.
When I first learned scrum, the product owner was described to me as the "single, ringable, neck."
The problem is that no one wants to put their neck out there. Decisions can't be made without committee, and individuals are literally afraid to own anything for fear of being held accountable if things go wrong.
LOL thanks for the correction and the useful mnemonic trick!
I was fairly certain 'ringable' was not a word so I fudged the quote. Unfortunately, even 'wringable' isn't a word. I guess it has to be 'wring-able', which just doesn't look right.
While I appreciate the insight I cannot fully agree with your conlusions. I've been a PO for the last 16 months (not my first scrum project) in a research project where it is simply impossible to have a long backlog. I bearly manage to keep one iteration ahead of the team. But it works. I think it does because I'm the person actively driving the development, I know the direction we should go and I do want the results
And that latter part is where, in my opinion, lies the difference. Not in the artifact but in the person.
In my opinion, anything on a product backlog which exceeds a 2-3 iteration horizon should be spun into a product roadmap document instead - as a general rule of thumb, if you don't have enough information about a story to sit down and write a clear set of acceptance criteria for it right now, it probably doesn't belong in your product backlog.
2-3 iterations is doable - trying to maintain a backlog of stories 2-3 releases ahead usually results in a big sloppy mess of a backlog.
Unfortunately, I've worked with many clients where thinking about priorities in the future far enough to have 2-3 days worth of stories in place beyond the current iteration is a struggle. This is where things usually go really off the tracks, because you build the thing it's easiest to describe right now to keep everyone working, or run from externally-directed fire to fire, instead of setting a cadence of development which represents the business' true near-term priority mix.
On big backlog: you have surprised me here. My backlog has all kinds of stuff in it that I'm not even sure we will ever build (as I said before it is a research project). As long these vague stories are more than 2 iterations away they don't distract the team but, at the same time, show them roughly what I am considering in the long term. I personally find it very important that the team knows the big picture and where and why we are heading so they can take more informed decisions. As a bonus once in a while I get unexpected insights from the team. They are smart guys, after all :)
Regarding the client involvement, what you describe is, in my eyes, not your problem but your clients' - they clearly have no idea what they want to have. If the project is important for the client I sometimes add one more (senior) person to the project from our side and charge him with the task of helping the client to figure out their needs. This new person takes over the PO role on the team side but spends most of his time with the client asking questions, guiding him etc.
I think the daily standup and retrospective meetings are easy to implement because they can be seen as status meetings for the chicken's benefit. They aren't, really, but it does seem easy to turn these from "developers appraising other developers about their problems and status" to "give me, the chicken, a list of the ticket numbers you plan on working on today and their status"
Retrospectives of course are seen as meetings (and managers love meetings) where the team works internally to make itself better. Woh , what a great idea! Except this also misses the point - sometimes the retrospective generates feedback for the organization/environment the team works in. "Sales people should file tickets, instead of cornering us and making us listen/do their thing". Things like this may be ignored or shoved in a desk drawer because "it's just developers whining"
15 comments
[ 5.4 ms ] story [ 53.4 ms ] threadProvided you have that, I believe the greatest success factors are outside of the scum team and that the effort to improve working conditions should be concentrated there.
Though I'd love the idea of a methodology race, where the fittest win. Wonder if there ever is an organization open minded enough to try this...
Every organization does that, to a degree, unknowingly. I know a (secret, undisclosed) organization where we (er, they!) do Scrum but if you analyzed what the teams actually do you probably wouldn't guess they follow anything resembling a single recipe :)
Curiously it seems to support the thesis of the article. I believe that all of the teams have some sort of a backlog and focus on making it good. The difference is that while the author strikes "prioritized" we, the devs, are more focused on "well specified".
The successful clients all had someone inhouse they could dedicate full-time to defining a well-structured backlog, grooming stories, balancing feedback from stakeholders, acceptance testing work, communicating with design and development, and generally acting as the unary executive voice of the product.
SomeONE. And the problem is that the role here calls for both executive, rather than committee, function and requires a broad generalist skillset. A good product owner needs to think analytically, write clearly, communicate firmly and negotiate competing needs and priorities. They need to be comfortable discussing technical details, even if they are not themselves technical. They need taste and understanding for user experience, even if they are not themselves a designer. They need delegation skills and a keen editorial instinct.
There are many more people with money to build software than with someone in-house with a matching set of aptitudes and is available to own a project.
Instead we get a group of department heads, with overfull schedules and competing needs. We get people who come to us with ideas for apps they are sure will make them wealthy. We create beautiful software for them, they "launch" in the App Store, and we never hear from them again. We get VPs of Product who spend more time in endless fundraising meetings than talking to their customers and development team.
The real surprise is that the success ratio has been this high.
Department heads are not product owners. In fact, I am a firm believer that being in any way responsible for staff is generally incompatible with the product owner role.
I has the luxury of working with a good product owner once. We recruited him for the task at hand, so he had no background in the organization doing nothing other than his PO duties. This turned out to be a great boon, and managed to avoid the usual pitfalls of developer-turned-PO or boss-also-doing-PO.
When I first learned scrum, the product owner was described to me as the "single, ringable, neck."
The problem is that no one wants to put their neck out there. Decisions can't be made without committee, and individuals are literally afraid to own anything for fear of being held accountable if things go wrong.
You don't "ring" a neck, you wring a neck.
Like one wrings a towel dry.
Take a towel into your hands and wring it dry.
Now imagine a clasping your hands around a neck and doing the same thing.
I've just used a mnemonic trick to prevent you from ever making this mistake again.
I was fairly certain 'ringable' was not a word so I fudged the quote. Unfortunately, even 'wringable' isn't a word. I guess it has to be 'wring-able', which just doesn't look right.
And that latter part is where, in my opinion, lies the difference. Not in the artifact but in the person.
2-3 iterations is doable - trying to maintain a backlog of stories 2-3 releases ahead usually results in a big sloppy mess of a backlog.
Unfortunately, I've worked with many clients where thinking about priorities in the future far enough to have 2-3 days worth of stories in place beyond the current iteration is a struggle. This is where things usually go really off the tracks, because you build the thing it's easiest to describe right now to keep everyone working, or run from externally-directed fire to fire, instead of setting a cadence of development which represents the business' true near-term priority mix.
Regarding the client involvement, what you describe is, in my eyes, not your problem but your clients' - they clearly have no idea what they want to have. If the project is important for the client I sometimes add one more (senior) person to the project from our side and charge him with the task of helping the client to figure out their needs. This new person takes over the PO role on the team side but spends most of his time with the client asking questions, guiding him etc.
Retrospectives of course are seen as meetings (and managers love meetings) where the team works internally to make itself better. Woh , what a great idea! Except this also misses the point - sometimes the retrospective generates feedback for the organization/environment the team works in. "Sales people should file tickets, instead of cornering us and making us listen/do their thing". Things like this may be ignored or shoved in a desk drawer because "it's just developers whining"