Would you expect to see something about tracking project progress in the skillz?
Closed this issue · 8 comments
Specifically I'm talking about things like velocity, release burndowns, spends, etc and then having the conversation with customers to explain how these concepts work and help in comparison with traditional PM practices.
I'm also thinking this is an LC+ expecation. Yes, some SCs can do it, but I wouldn't expect all of them to, mainly because of the explanation to the customer component. The mechanics of project tracking is all but a given.
I think this is pretty important and should be there.
The LC+ expectation seems right too though ideally, there would be something about this at the SC level that conveys that an SC should at least understand these concepts since they are expected to lead small teams to ship a product from start to finish...though I can't think of how to word this right now.
+1
mainly because of the explanation to the customer component
I thought our expectations that our SC's were equipped to consult - hence the C. If a person can't be persuasive in regards to our preferred approaches with our clients, or are not yet equipped with negotiation skills to help gain some traction with the customer - perhaps the person should still be an SD working their way to SC?
A small addition to that: our promotions have always been based on someone being fully capable of fulfilling a given position: do the job you want, prove your capability, then be recognized with the promotion. I would think that by the time someone has been promoted to SC, they have proven that they have some reasonable consulting capabilities in the field - they are not just a 'technical team lead'.
+1 to nev and richard
@andrewabest While the SC role covers estimating an engagement, it's really a job about consulting not team leading or project management. See #8 for reasoning.
@rbanks54 "Team Leadership" is listed under the competencies expected of the SC position. So is Scrum.
"Yes, some SCs can do it, but I wouldn't expect all of them to, mainly because of the explanation to the customer component"
"The mechanics of project tracking is all but a given."
Followed by
"it's really a job about consulting"
I would have thought that if you know the mechanics of a given system, and are expected to have 'consulting expertise', then the act of consulting with the customer regarding the system should be an extension of these.
I disagree with the idea that an SC should struggle explaining these concepts to a customer.
However I agree with what @nevillemehta was moving towards though - that there are two parts to this that build on top of each other.
An SC should be able to:
- Discuss the benefits of empiricism
- Discuss what velocity is, what it can be used to measure, and some of the caveats of its usage
- Construct and take the customer through a release burndown / burnup and contrast the benefits of the two
- Discuss what scrum is and what it benefits it provides ("software in 30 days" level of explanation)
An LC should be able to:
- Effectively contrast the empiric PM model with existing non-empiric models based on experience
- Strategise on mixing or marrying PM approaches where required (i.e. agile within prince 2)
- Be able to advise how traditional PMs can provide value in an agile project
- ... whatever else I've missed (you mentioned spends)
So how do we summarize each of those in a dot point? :)
"Straw man" commit.
Let me know if the wording works for you of if it needs tweaking.