I attended a user group meeting last week where a participant asked the question: “How do I keep my stand-ups from going so long?”. He cited greater-than 30-minute time for 10 people.
I didn’t get a chance to talk to him, but here is my advice.
First, discuss the topic with the team. Ensure that there is agreement that long stand-ups are negatively impacting the team. It may be (but it’s unlikely) that the content of the long stand-ups is important to everyone,
Determine root cause. I find a couple of causes that can be addressed in different ways.
Long-winded people offering irrelevant input or input that is relevant to only one other person: Record the contributions of each of the long-winded folks and review with them. Identify specific content that is not relevant to the team.
You’ll often find paycheck rationalization offerings (e.g. “I had my one-on-one with my manager yesterday”).
Or you may find someone simply regurgitating their calendar (managers are likely to be the offenders here).
Or it could be politically driven public thrashings that are more appropriate to share in private (“David – you seem to be checking code in without any tests. Remember, we agreed that we would write tests”).
I’ve seen stand-ups where multiple team members will regurgitate events in which the whole team participated. If the whole team attended the iteration planning meeting, there is no need to mention this in the stand-up.
Start timing folks. If anyone talks more than 2 minutes, make them stand on one leg, or ask them to extend their arm holding a heavy book while talking. Or use a timer (obnoxious alarms are best).
Conversations that are not relevant to the whole team: Institute a “parking lot” flip chart or white board where topics for further conversation can be captured for discussion after stand-up. Ask the whole team to help identify potential parking lot items when they occur; add them to the parking lot when identified and move on. Ensure that those follow-on conversations occur (else you run the risk that folks will continue to insist on in-stand-up dialog).
Use a speaking token and ask the team to be rigid about not talking when they don’t have the token. As conversations occur, the token passing will make it obvious that a conversation is occurring, which should help folks to self-identify opportunities to use the parking lot.
Explain to the team that the stand-up is not the only opportunity for conversation during the day.
Use a laser pointer to have folks point out the relevant stories/tasks on the physical card wall as they speak. They will be less likely to pontificate on irrelevant details if they have no card to point to.
I’ve attended stand-ups of over 40 people that have taken less than 10 minutes. That’s less than 15 seconds per person. Granted, these were teams that were pairing, so oftentimes the contribution of the second of the pair was of the form “ditto Joe”. Still – if a team of 40+ can get it done in 10 minutes, there’s no reason why your “2-pizza team” cannot.
Thursday, October 06, 2011
Thursday, June 30, 2011
Prioritizing vs. Sequencing the Product Backlog
A primary tenet of agile software development is doing the highest business-value work earlier. The idea is that you achieve a minimal marketable feature set as early as possible so that a) you can issue releases earlier and b) if the money runs out, you have something more valuable than if you didn't sequence your work in that manner.
Another, less frequently cited agile tenet is to do the riskiest work earlier. The idea here is that you avoid late surprises when risky work turns out to be expensive. Better to discover this expense earlier.
When most folks talk about the backlog order, they refer exclusively to business priority.
I think ordering or sequencing the backlog must take more than just business priority into account. Yes, business priority is important, but so are a whole host of other factors, such as early exposure of risk. Balancing these factors is part of the art of project management.
Factors to incorporate into sequencing decisions:
As I mentioned, these factors are often competing. The context of your project defines which of these dimensions are more or less important. Yes, do the highest business value work earlier, but don't forget to consider these other factors as well.
Another, less frequently cited agile tenet is to do the riskiest work earlier. The idea here is that you avoid late surprises when risky work turns out to be expensive. Better to discover this expense earlier.
When most folks talk about the backlog order, they refer exclusively to business priority.
I think ordering or sequencing the backlog must take more than just business priority into account. Yes, business priority is important, but so are a whole host of other factors, such as early exposure of risk. Balancing these factors is part of the art of project management.
Factors to incorporate into sequencing decisions:
- Business Priority
- Dependency Order: Despite our best efforts to decompose the backlog into independent stories, the fact is, the tension between the INVEST priorities sometimes cause us to define stories that are dependent on other stories.
- Mixture: The Rock/Pebble/Sand metaphor is helpful here. Consider a bucket at the beach. If you fill it only with rocks, you have a great deal of wasted space in the bucket, due to the space between the rocks. Though it may be unable to accommodate another rock, you may be able to slip in a handful of pebbles, to fill the spaces. Following that, you may be able to slip in some sand, to fill the spaces that the pebbles were unable to occupy. So it goes with an iteration. You don't want to fill your iteration bucket with only large stories, because you're losing the opportunity to slip in smaller stories. For example - if a developer finishes a story at 3pm on a Friday afternoon, you'd probably rather have him knock off a small story in the next couple of hours rather than start a large story.
- Crowding: Many advise that agile development teams define iteration themes. This is a good concept in theory, as it allows the team to focus on accomplishing a larger goal in the iteration. The risk here is that you have your whole development team working in the same parts of the code base. This can merge issues as the team commits code to the code repository. Consider the source-code crowding problem when sequencing the work.
- Risk: As mentioned above, the earlier you schedule the risky elements of the project, the more insight you have into your completion date. One element of risk is embedded in non-functional requirements. For example - if you have performance or scalability requirements that are risky, it's better to implement the stories that are sensitive to those requirements earlier.
- User Feedback: If you have elements of the software for which user feedback is critical to making the right decisions, schedule this work earlier. If you delay these features towards the end, the need to change the system in response to the feedback becomes a schedule surprise. Worse, if you decide not to incorporate the feedback in order to make your date, your users are not just unhappy; they'll feel that their input has been ignored.
- Exercise the architecture: Scheduling the highest business value work first may avoid elements of the architecture into later in the development cycle. For example, perhaps the "happy path" of execution is deemed the higher business value. This might delay consideration of elements of exception handling to the end of the release. First pass implementations within an architecture are always riskier, and could introduce schedule surprise. It is wise to exercise all elements of the architecture as early as possible.
As I mentioned, these factors are often competing. The context of your project defines which of these dimensions are more or less important. Yes, do the highest business value work earlier, but don't forget to consider these other factors as well.
Tuesday, June 28, 2011
Feedback Manifesto
I have come to value
Verbal, constructive feedback over written evaluations
Measuring output over measuring input
Frank feedback from colleagues over speculative management judgment
Real-time, frequent feedback over periodic high-ceremony assessments
Though the things on the right are commonplace and often dictated by antiquated HR policies, I value the things on the left more. Much more.
Principles
Giving feedback
My highest priority in giving feedback is to help my colleagues improve - to benefit them individually and the organization collectively. I always preface my feedback with this sentiment.
I understand that not all recipients are comfortable with feedback. I choose the time and place of delivery to respect this sensitivity.
I always ask the recipient if he/she is willing and receptive to feedback at that time/place and graciously accept "not now" for an answer.
My feedback focuses on behavior and outcomes - not the person.
When providing critical feedback, I consider the constraints and challenges in play at the time of the performance for which I am providing feedback.
I acknowledge intelligent risk-taking as a necessary component of creativity and delivery of value and incorporate my appreciation for it in my feedback.
I ask for feedback on my delivery in order to continually improve my ability to give constructive, valuable feedback.
Receiving feedback
I welcome critical feedback about my performance as a gift, and express my appreciation accordingly, regardless of whether I agree.
If I am not in a good place to receive feedback, I respectfully request an opportunity to reschedule.
I refrain from defensiveness or questioning the motives of the person giving me feedback in order that I can absorb the essence of the feedback.
Verbal, constructive feedback over written evaluations
Measuring output over measuring input
Frank feedback from colleagues over speculative management judgment
Real-time, frequent feedback over periodic high-ceremony assessments
Though the things on the right are commonplace and often dictated by antiquated HR policies, I value the things on the left more. Much more.
Principles
Giving feedback
My highest priority in giving feedback is to help my colleagues improve - to benefit them individually and the organization collectively. I always preface my feedback with this sentiment.
I understand that not all recipients are comfortable with feedback. I choose the time and place of delivery to respect this sensitivity.
I always ask the recipient if he/she is willing and receptive to feedback at that time/place and graciously accept "not now" for an answer.
My feedback focuses on behavior and outcomes - not the person.
When providing critical feedback, I consider the constraints and challenges in play at the time of the performance for which I am providing feedback.
I acknowledge intelligent risk-taking as a necessary component of creativity and delivery of value and incorporate my appreciation for it in my feedback.
I ask for feedback on my delivery in order to continually improve my ability to give constructive, valuable feedback.
Receiving feedback
I welcome critical feedback about my performance as a gift, and express my appreciation accordingly, regardless of whether I agree.
If I am not in a good place to receive feedback, I respectfully request an opportunity to reschedule.
I refrain from defensiveness or questioning the motives of the person giving me feedback in order that I can absorb the essence of the feedback.
Monday, June 20, 2011
The case against iteration based re-estimation
Many agile practitioners recommend re-estimating stories at the beginning of each iteration. I disagree with this practice.
For one thing, I believe it's a waste of time. Any value that you might get (which I doubt - see below) from the practice is lost on the time spent.
It's worse than that though. By re-estimating the iteration's stories, you are almost always estimating with a greater level of detail than what you had originally. With this increased level of detail, in my experience, estimates tend to grow.
Why is this a big deal?
Let's try an example.
I come in to my iteration planning meeting with 30 points worth of stories from the backlog. The team commits to those stories, but in re-estimating, the 30 points inflates to 40. In fact, this always seems to happen, as the team gets a little nervous about hitting their historical velocity and they know management is paying attention. Let's assume the team gets them all done. This increases the observed velocity by a third (40 points is a third more than 30). Now, let's say I have 120 more points left in the product backlog to get to the minimal marketable feature set for release. How many more iterations are left?
If you said 3 more iterations (i.e. 40 points per iteration gets you to 120), you are ignoring your team's tendency to inflate estimates. Assuming your estimate inflation rate is consistent (a third), you really don't have 120 points remaining, you have 160 points, or 4 more iterations remaining. Or, calculated another way, if you consider only the initial estimates to calculate your velocity (30), then you can determine that you have 4 iterations of 30 remaining. In both cases, you end up correctly predicting 4 more iterations. Then again - if you use the initial estimates, what value did your re-estimation from 30 to 40 provide you ? I say none.
If you regularly re-estimate at iteration planning meetings, make a note of the original vs. the updated estimates. See if they grow. Consider what impact this is having on the accuracy of your release planning.
OK, I can hear you now. "My team's estimates don't inflate ... some go up; some go down". I haven't seen this, but let's say you do. Let's revisit the example from above with this assumption. You go into the iteration planning meeting with 30 points and walk out with 29. Your velocity is not materially impacted. You are still on track with 3 remaining iterations (roughly). So the question is this: what value did that re-estimation provide? I say none.
When *do* you re-estimate then?
I believe in updating estimates when information arises from experience that pertains to some shared aspect of a subset of stories. For example, let's say that your retrospectives have shown that every time you have a story that hits a certain database, it ends up being much more effort than expected. In a case like this, it makes sense to revist those database stories to ensure that this knowledge is incorporated into those estimates. I call this aspect-oriented re-estimation (adapted from the term "aspect-oriented programming").
For one thing, I believe it's a waste of time. Any value that you might get (which I doubt - see below) from the practice is lost on the time spent.
It's worse than that though. By re-estimating the iteration's stories, you are almost always estimating with a greater level of detail than what you had originally. With this increased level of detail, in my experience, estimates tend to grow.
Why is this a big deal?
Let's try an example.
I come in to my iteration planning meeting with 30 points worth of stories from the backlog. The team commits to those stories, but in re-estimating, the 30 points inflates to 40. In fact, this always seems to happen, as the team gets a little nervous about hitting their historical velocity and they know management is paying attention. Let's assume the team gets them all done. This increases the observed velocity by a third (40 points is a third more than 30). Now, let's say I have 120 more points left in the product backlog to get to the minimal marketable feature set for release. How many more iterations are left?
If you said 3 more iterations (i.e. 40 points per iteration gets you to 120), you are ignoring your team's tendency to inflate estimates. Assuming your estimate inflation rate is consistent (a third), you really don't have 120 points remaining, you have 160 points, or 4 more iterations remaining. Or, calculated another way, if you consider only the initial estimates to calculate your velocity (30), then you can determine that you have 4 iterations of 30 remaining. In both cases, you end up correctly predicting 4 more iterations. Then again - if you use the initial estimates, what value did your re-estimation from 30 to 40 provide you ? I say none.
If you regularly re-estimate at iteration planning meetings, make a note of the original vs. the updated estimates. See if they grow. Consider what impact this is having on the accuracy of your release planning.
OK, I can hear you now. "My team's estimates don't inflate ... some go up; some go down". I haven't seen this, but let's say you do. Let's revisit the example from above with this assumption. You go into the iteration planning meeting with 30 points and walk out with 29. Your velocity is not materially impacted. You are still on track with 3 remaining iterations (roughly). So the question is this: what value did that re-estimation provide? I say none.
When *do* you re-estimate then?
I believe in updating estimates when information arises from experience that pertains to some shared aspect of a subset of stories. For example, let's say that your retrospectives have shown that every time you have a story that hits a certain database, it ends up being much more effort than expected. In a case like this, it makes sense to revist those database stories to ensure that this knowledge is incorporated into those estimates. I call this aspect-oriented re-estimation (adapted from the term "aspect-oriented programming").
Saturday, June 18, 2011
The case against Chickens and Pigs
Schwaber and Beedle's Scrum book introduces the pig and chicken fable to illustrate a point. It goes something like this:
Chicken:
Let's start a restaurant!
Pig:
What would we call it?
Chicken:
Ham n' Eggs!
Pig: No thanks. I'd be committed, but you'd only be involved!
The story is used to illustrate a difference between
a) the core team members - the "pigs" who are committed to the success of the project (blood sweat and tears maybe?) and
b) outside contributors - the "chickens" who contribute but are presumably not "sacrificing" for the cause
First - I think the analogy is confusing. I always have a hard time explaining it and I haven't heard a coherent verbal description of the concept. There's got to be a better way to make the point.
My higher purpose here, however, is to extinguish the point.
A commonly cited rule is that "only pigs can talk in the stand-up". There is an underlying premise here that anything a "chicken" or non-core team member has to say is wasteful of the team's time. A corollary perhaps: anything a core team member has to say is important.
I have participated in stand-ups where chicken "contributions" have been extremely valuable. Example:
pig: "My computer monitor froze last night; I need to order a new one"
chicken: "Stop by my desk after stand-up. I have a spare"
pig: "Today, I'm meeting with the product owner to review stories for the next iteration"
chicken: "Product owner is out sick today. Let's talk after stand-up about rescheduling or doing it remotely"
Or how 'bout a chicken who participates in the stand-up and shares relevant information. Maybe the normal contribution is "pass" (meaning - there's nothing of import to the team to share). But maybe she's got something important to say:
chicken: "Yesterday, I met with a group of 6 customers to review the prototype. Feedback was overwhelmingly positive. They had some good suggestions. Today, I'd like to sit down with Joe to review some of them and get stories added to the backlog".
What a great contribution to the stand-up! The team gets a valuable shot in the arm (positive feedback) and Joe gets a heads up on some work for later that day.
I've also witnessed many examples of core team members' verbosity and sharing unimportant information.
pig: "Yesterday I had a one-on-one with my manager and worked on my mid-year performance review"
Huh? It seems that this information is being shared not for the benefit of the team, but to justify someone's paycheck for the time they spent in the office.
pig: "I ran into an issue when creating the xyz service. When I compiled the code, I got an Exception in the compiler. I stepped through the compiler assembler logic, but couldn't figure anything out. I then spent about an hour on Google looking for the cause. I finally found this bizarre reference in a Japanese website - thank goodness for Google translation - but it's kind of funny how they botch the translation, I mean, it's not exactly the King's English. Anyway, I translated it, and found someone had this issue because they were running service pack 1 of the IDE without the next two patches on a MacBook Pro running Boot Camp. I installed the patches and still had the problem. I tried a bunch of other things after that and finally got things working. I think clearing the cache did the trick. I thought I'd be done yesterday, but that issue set me back a bit. Barring any other bizarre issues today, I expect to be done with the story by end of day.
OK, I made all that stuff up. This guy needs some coaching on being more succinct. There's some valuable info in there ("hey everyone - make sure you have those two patches", and "I should be done today") but it's buried in irrelevant detail.
My general point is this: I think the chickens/pigs designation is more harmful than helpful. Common sense - about what's valuable to share - should carry the day. Open and honest conversations with *all* participants about expected behavior in stand-ups and beyond should trump this arbitrary dividing line about whose voice should be heard when.
Chicken:
Let's start a restaurant!
Pig:
What would we call it?
Chicken:
Ham n' Eggs!
Pig: No thanks. I'd be committed, but you'd only be involved!
The story is used to illustrate a difference between
a) the core team members - the "pigs" who are committed to the success of the project (blood sweat and tears maybe?) and
b) outside contributors - the "chickens" who contribute but are presumably not "sacrificing" for the cause
First - I think the analogy is confusing. I always have a hard time explaining it and I haven't heard a coherent verbal description of the concept. There's got to be a better way to make the point.
My higher purpose here, however, is to extinguish the point.
A commonly cited rule is that "only pigs can talk in the stand-up". There is an underlying premise here that anything a "chicken" or non-core team member has to say is wasteful of the team's time. A corollary perhaps: anything a core team member has to say is important.
I have participated in stand-ups where chicken "contributions" have been extremely valuable. Example:
pig: "My computer monitor froze last night; I need to order a new one"
chicken: "Stop by my desk after stand-up. I have a spare"
pig: "Today, I'm meeting with the product owner to review stories for the next iteration"
chicken: "Product owner is out sick today. Let's talk after stand-up about rescheduling or doing it remotely"
Or how 'bout a chicken who participates in the stand-up and shares relevant information. Maybe the normal contribution is "pass" (meaning - there's nothing of import to the team to share). But maybe she's got something important to say:
chicken: "Yesterday, I met with a group of 6 customers to review the prototype. Feedback was overwhelmingly positive. They had some good suggestions. Today, I'd like to sit down with Joe to review some of them and get stories added to the backlog".
What a great contribution to the stand-up! The team gets a valuable shot in the arm (positive feedback) and Joe gets a heads up on some work for later that day.
I've also witnessed many examples of core team members' verbosity and sharing unimportant information.
pig: "Yesterday I had a one-on-one with my manager and worked on my mid-year performance review"
Huh? It seems that this information is being shared not for the benefit of the team, but to justify someone's paycheck for the time they spent in the office.
pig: "I ran into an issue when creating the xyz service. When I compiled the code, I got an Exception in the compiler. I stepped through the compiler assembler logic, but couldn't figure anything out. I then spent about an hour on Google looking for the cause. I finally found this bizarre reference in a Japanese website - thank goodness for Google translation - but it's kind of funny how they botch the translation, I mean, it's not exactly the King's English. Anyway, I translated it, and found someone had this issue because they were running service pack 1 of the IDE without the next two patches on a MacBook Pro running Boot Camp. I installed the patches and still had the problem. I tried a bunch of other things after that and finally got things working. I think clearing the cache did the trick. I thought I'd be done yesterday, but that issue set me back a bit. Barring any other bizarre issues today, I expect to be done with the story by end of day.
OK, I made all that stuff up. This guy needs some coaching on being more succinct. There's some valuable info in there ("hey everyone - make sure you have those two patches", and "I should be done today") but it's buried in irrelevant detail.
My general point is this: I think the chickens/pigs designation is more harmful than helpful. Common sense - about what's valuable to share - should carry the day. Open and honest conversations with *all* participants about expected behavior in stand-ups and beyond should trump this arbitrary dividing line about whose voice should be heard when.
Agile talent market
Do you have agile/lean running through your veins?
I know of a couple of great companies seeking agile/lean talent.
If you're not into travel - perhaps you've been on the road and are looking to settle down, Lab49 has opportunities in New York and London for agile UX, development (.Net/Java/other), and project management talent. Travel is minimal. Smart people. Finance domain.
If you're thinking of moving from a captive arrangement (employee of a company that owns everything you produce) into a more independent contractor arrangement, LeanDog might be the place for you. Their office is on a boat in Cleveland. A big boat. Great management team. Organizational transformation, coaching, training, delivery, multiple technologies, craftsmanship. Business is booming.
Contact me for an introduction to either of these great companies. Warning: both firms are extremely selective.
I know of a couple of great companies seeking agile/lean talent.
If you're not into travel - perhaps you've been on the road and are looking to settle down, Lab49 has opportunities in New York and London for agile UX, development (.Net/Java/other), and project management talent. Travel is minimal. Smart people. Finance domain.
If you're thinking of moving from a captive arrangement (employee of a company that owns everything you produce) into a more independent contractor arrangement, LeanDog might be the place for you. Their office is on a boat in Cleveland. A big boat. Great management team. Organizational transformation, coaching, training, delivery, multiple technologies, craftsmanship. Business is booming.
Contact me for an introduction to either of these great companies. Warning: both firms are extremely selective.
Monday, January 31, 2011
Agile within a non-agile ecosystem
Agile, like Texas Hold 'Em poker, is pretty simple. The agile manifesto is straightforward. Some agile practices are more difficult than others. Stand-ups are probably the simplest agile technique (though it confounds me how difficult it is sometimes to get people to make them short and sweet, relevant, and focused). Test-driven development is one of the harder concepts to grasp. Estimation with abstract units is sometimes hard to grasp. These are all localized challenges that can be addressed fairly easily with team members that have the attitude and aptitude to change.
These team-based challenges are dwarfed in complexity, in my experience, by the immense challenges of adapting an agile team's relationship to the non-agile ecosystem in which these teams/organizations typically exist. These ecosystems often foist irrational demands on software projects in general (not just those of agile teams). An example: the budgeting process requires you to commit to your scope, schedule and resources up front. You're then damned when you ask for more time, money or request to reduce scope. This isn't just a bad practice for agile teams; it's bad practice for most software development projects.
Cultures that reward individuals based on heroics are another example of ecosystem conflicts with agile philosophy.
Leaders and executives who desire to nurture the agile teams in their organizations would be well-advised to help their agile teams address these "impedance mismatches" between agile and the ecosystem - and to stand up and defend the team's approach against the "that's the way we've always done it" mentality that oftentimes exists within the culture.
These team-based challenges are dwarfed in complexity, in my experience, by the immense challenges of adapting an agile team's relationship to the non-agile ecosystem in which these teams/organizations typically exist. These ecosystems often foist irrational demands on software projects in general (not just those of agile teams). An example: the budgeting process requires you to commit to your scope, schedule and resources up front. You're then damned when you ask for more time, money or request to reduce scope. This isn't just a bad practice for agile teams; it's bad practice for most software development projects.
Cultures that reward individuals based on heroics are another example of ecosystem conflicts with agile philosophy.
Leaders and executives who desire to nurture the agile teams in their organizations would be well-advised to help their agile teams address these "impedance mismatches" between agile and the ecosystem - and to stand up and defend the team's approach against the "that's the way we've always done it" mentality that oftentimes exists within the culture.
Tuesday, November 09, 2010
Simple UX plea
Dear UX designers,
If I'm not authorized to perform a specific function in the application, please show me a grayed-out button or disabled select list, rather than not showing anything to me.
This way, I know that I'm not authorized, and I won't waste hours scanning the application looking in other corners of your app for the functionality you have simply hidden.
Thanks.
If I'm not authorized to perform a specific function in the application, please show me a grayed-out button or disabled select list, rather than not showing anything to me.
This way, I know that I'm not authorized, and I won't waste hours scanning the application looking in other corners of your app for the functionality you have simply hidden.
Thanks.
Monday, April 26, 2010
Verbal Combat
And here is where the decision is made. Do I retreat to my established viewpoint? Do I dig in my heels? Or do I consider the alternative, offered by my combatant? And suffer the indignity of being judged wrong?
Friday, April 16, 2010
Truck Factor Mitigation
One of the strong selling points of pair programming is that knowledge of the code base, techniques, and domain are shared across multiple people. We joke that this reduces the "truck factor" for a team. Truck factor is the risk to the team or project of any specific person getting "hit by a truck".
Some other phrases: "beer truck factor", for those who like to imagine being hit by a worthy cause, or "lottery factor", as one colleague suggested, since it is a happier ending.
High truck factors can be good for the individual. After all, if your specific knowledge or talent is critical to the firm, so too, is your ability to negotiate for higher compensation or to easily acquire extra latitude for resources and decision-making authority. Management does not want to scare away the geese that lay the golden eggs when they have no idea how the egg-laying works.
A high truck factor has a downside for the individual though. When you finally get tired of the same platform/domain/language and want to move on, the hand that feeds you is likely to restrain you from departing to other projects. Sometimes, the only departure path is to leave the company. That can be a good thing for getting out of a rut (and introducing potentially lucrative contract work with your prior employer), but can also force you to start from scratch in building a reputation in a new situation.
What of leadership/management? How do we reduce the truck factor for managers? They don't typically pair. What happens when opportunities arise for a promotion, or an exciting lateral move, but the leader is tied to his current position with no replacement in site? Perhaps he needs to turn the new position down. Perhaps the external market is tapped for a replacement. Perhaps he just adds the new position's responsibilities to his current responsibilities. These are smells of poor succession planning.
If you're a technical superstar, or simply a master of your technical niche, or
if you're a domain expert, or simply master of your domain niche, or
if you're a leadership expert, or simply the most ingrained leader in your current role:
Identify, train and groom your successor(s)
You never know when that lottery ticket will hit.
Some other phrases: "beer truck factor", for those who like to imagine being hit by a worthy cause, or "lottery factor", as one colleague suggested, since it is a happier ending.
High truck factors can be good for the individual. After all, if your specific knowledge or talent is critical to the firm, so too, is your ability to negotiate for higher compensation or to easily acquire extra latitude for resources and decision-making authority. Management does not want to scare away the geese that lay the golden eggs when they have no idea how the egg-laying works.
A high truck factor has a downside for the individual though. When you finally get tired of the same platform/domain/language and want to move on, the hand that feeds you is likely to restrain you from departing to other projects. Sometimes, the only departure path is to leave the company. That can be a good thing for getting out of a rut (and introducing potentially lucrative contract work with your prior employer), but can also force you to start from scratch in building a reputation in a new situation.
What of leadership/management? How do we reduce the truck factor for managers? They don't typically pair. What happens when opportunities arise for a promotion, or an exciting lateral move, but the leader is tied to his current position with no replacement in site? Perhaps he needs to turn the new position down. Perhaps the external market is tapped for a replacement. Perhaps he just adds the new position's responsibilities to his current responsibilities. These are smells of poor succession planning.
If you're a technical superstar, or simply a master of your technical niche, or
if you're a domain expert, or simply master of your domain niche, or
if you're a leadership expert, or simply the most ingrained leader in your current role:
Identify, train and groom your successor(s)
You never know when that lottery ticket will hit.
Thursday, January 28, 2010
Talent acquisition and retention
My friend, Brad Cross, posted an interesting blog entry recently on how compensation relates to attracting and retaining technical talent. This particular phrase resonated for me:
"Great workers long to work on interesting and challenging problems and collaborate with other great people who have a strong sense of vision and purpose in their work. They long for an open and supportive environment grounded in mutual respect that enables them to make their own decisions as appropriate."
His blog post goes on to relate the disconnect between the 10X productivity difference between the best and the worst software developers and the incongruence of the meager salary differential proffered by employers to recognize this difference (hint: it's not 10x).
Brad's post is thought-provoking, as usual.
"Great workers long to work on interesting and challenging problems and collaborate with other great people who have a strong sense of vision and purpose in their work. They long for an open and supportive environment grounded in mutual respect that enables them to make their own decisions as appropriate."
His blog post goes on to relate the disconnect between the 10X productivity difference between the best and the worst software developers and the incongruence of the meager salary differential proffered by employers to recognize this difference (hint: it's not 10x).
Brad's post is thought-provoking, as usual.
Tuesday, January 26, 2010
No applause, just throw money
I have an aversion to the applause that occurs in some iteration showcases (aka sprint reviews) on agile teams. The showcases are the meetings at the end of an iteration where the team shows working software to project stakeholders. Unfortunately, many teams end up displaying PowerPoint presentations instead or in addition, but that's a topic for another post.
I once witnessed a team that had 2-week iterations and held a 2 hour review at the end of each iteration. Each team member presented what he had worked on and accomplished over the course of the iteration. First of all, two hours was too long for this team for a 2-week iteration. They simply did not produce enough demonstrable working software to warrant a two-hour meeting. Worse, they often resorted to presenting partially completed stories - another problem, but again, fodder for a future post.
Having each team member speak and present his accomplishments might have been a good thing for that particular team. It can provide a similar social pressure that stand-up meetings provide - nobody wants to stand up and say they didn't accomplish anything, so each team member strives to deliver demonstrable value. The problem I had with this particular team was that the norms established that everyone applaud each person after his little piece of the presentation. Not only was the applause time-consuming, it was gratuitous. Folks in the meeting applauded simply because they were expected to, not because of any remarkable achievement.
In some cases, the team member didn't really accomplish anything of note on his own and the applause was simply out of place. It is as if my dog takes a dump in the middle of the carpet during a party and the crowd rushes up to pet and praise him, and offer him doggie treats. Clearly, this confuses the dog.
Though applauding every presenter is certainly overkill, I argue that applause at the end of an iteration showcase should be eliminated (or better, never started in the first place). In any case, it should never be de rigeur, and should never be instigated by an outsider who may have no clue as to whether the team really accomplished something special.
Applauding showcases for mediocre or even poor iterations can have a deleterious effect on motivation. Consider this possible thought going through a team member's head: "They applauded for this crap? They have no clue what we're doing".
We have a habit of rewarding performance. If my kids come home with straight-A report cards, I heap praise on them. If a see a C, I begin my own inspect and adapt cycle at home. But in report cards, the grades are clear, and are mostly objective. That is - the "A" reflects a large number of assignments, tests, and projects, and the teacher assessing the outcome has a substantial pool of similar production to compare against. Outcomes of iterations/sprints, on the other hand, are hardly objective, and are not comparable to other teams' output. It is truly only the team members who know, in their collective heart of hearts, whether they really deserve applause or not.
So my suggestion: omit the applause until the code gets into production and the customers' rave reviews start flowing. That's when the party should start.
I once witnessed a team that had 2-week iterations and held a 2 hour review at the end of each iteration. Each team member presented what he had worked on and accomplished over the course of the iteration. First of all, two hours was too long for this team for a 2-week iteration. They simply did not produce enough demonstrable working software to warrant a two-hour meeting. Worse, they often resorted to presenting partially completed stories - another problem, but again, fodder for a future post.
Having each team member speak and present his accomplishments might have been a good thing for that particular team. It can provide a similar social pressure that stand-up meetings provide - nobody wants to stand up and say they didn't accomplish anything, so each team member strives to deliver demonstrable value. The problem I had with this particular team was that the norms established that everyone applaud each person after his little piece of the presentation. Not only was the applause time-consuming, it was gratuitous. Folks in the meeting applauded simply because they were expected to, not because of any remarkable achievement.
In some cases, the team member didn't really accomplish anything of note on his own and the applause was simply out of place. It is as if my dog takes a dump in the middle of the carpet during a party and the crowd rushes up to pet and praise him, and offer him doggie treats. Clearly, this confuses the dog.
Though applauding every presenter is certainly overkill, I argue that applause at the end of an iteration showcase should be eliminated (or better, never started in the first place). In any case, it should never be de rigeur, and should never be instigated by an outsider who may have no clue as to whether the team really accomplished something special.
Applauding showcases for mediocre or even poor iterations can have a deleterious effect on motivation. Consider this possible thought going through a team member's head: "They applauded for this crap? They have no clue what we're doing".
We have a habit of rewarding performance. If my kids come home with straight-A report cards, I heap praise on them. If a see a C, I begin my own inspect and adapt cycle at home. But in report cards, the grades are clear, and are mostly objective. That is - the "A" reflects a large number of assignments, tests, and projects, and the teacher assessing the outcome has a substantial pool of similar production to compare against. Outcomes of iterations/sprints, on the other hand, are hardly objective, and are not comparable to other teams' output. It is truly only the team members who know, in their collective heart of hearts, whether they really deserve applause or not.
So my suggestion: omit the applause until the code gets into production and the customers' rave reviews start flowing. That's when the party should start.
Tuesday, December 22, 2009
Crew bags in the bulkhead overhead
<pet peeve>
This has happened to me on several recent flights. I am seated in the bulkhead of the airplane - sometimes in first class. I open the overhead bins and airline crew bags are taking up that precious space.
As frequent travelers know, bulkhead travelers must put *all* baggage in the overhead, which increases their overhead space requirements. Flight attendants putting their luggage into that limited overhead space is inexcusable, particularly since there is no need for them to gather their luggage until everyone else is off the plane. When they use this space, bulkhead passengers must place their bags several rows back, making the deplaning process much more difficult (swimming upstream to retrieve bags).
</pet peeve>
Kudos to the Airtran flight attendants on my most recent trip, who spaced their bags out over several different rows beyond the bulkhead.
This has happened to me on several recent flights. I am seated in the bulkhead of the airplane - sometimes in first class. I open the overhead bins and airline crew bags are taking up that precious space.
As frequent travelers know, bulkhead travelers must put *all* baggage in the overhead, which increases their overhead space requirements. Flight attendants putting their luggage into that limited overhead space is inexcusable, particularly since there is no need for them to gather their luggage until everyone else is off the plane. When they use this space, bulkhead passengers must place their bags several rows back, making the deplaning process much more difficult (swimming upstream to retrieve bags).
</pet peeve>
Kudos to the Airtran flight attendants on my most recent trip, who spaced their bags out over several different rows beyond the bulkhead.
Monday, December 21, 2009
www
Listening to the radio - folks talking about words. One problematic pronunciation is for folks pronouncing website names.
double-you, double-you, double-you ... 9 syllables, awkward
dub dub dub .... 3 syllables - better
Three-Dub ... OK - maybe this one isn't used - just throwin' it out for consideration.
double-you, double-you, double-you ... 9 syllables, awkward
dub dub dub .... 3 syllables - better
Three-Dub ... OK - maybe this one isn't used - just throwin' it out for consideration.
Wednesday, December 09, 2009
Politics at work
I just read The Five Dysfunctions of a Team on the plane this week.
I saw an interesting interpretation of the term "politics" which intrigues me:
"Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think."
I saw an interesting interpretation of the term "politics" which intrigues me:
"Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think."
Friday, November 27, 2009
Threshold Anxiety
"Kierkegaard, the nineteenth-century Danish philosopher, first described what has come to be known as 'threshold anxiety'. He describes the feelings of a young man who is about to leave home to go out into the world to seek his fortune. As he stands on the threshold of the house, about to leave, he feels that he's turning his back on everything that is warm, familiar, and secure -- what he has known all his life. Beyond the threshold lies the world, filled with all that is unknown and strange. If the young man turns back at this point, he is lost. If, however, he can take the fear of the unknown and turn it into the excitement of the unlimited possibilities which are open before him, he grows in the moment and is alive, as never before."
- Mildred Newmand and Dr. Bernard Berkowitz
How to Take Charge of Your Life
- Mildred Newmand and Dr. Bernard Berkowitz
How to Take Charge of Your Life
Saturday, November 21, 2009
Squirrel Agile
A client shared this term a few weeks ago that I really liked: Squirrel Agile. Thanks Steve.
I'm sure you've seen a squirrel trying to cross a street. The squirrel starts off on one side of the street, looks, darts out, then sees something scary and retreats. Sometimes he retreats all the way... sometimes he just stops in his tracks. When he starts again, he may continue trying to cross, or may high-tail it back to the original side of the street.
In agile adoption, we sometimes see fits and starts... and retreats - just like the squirrel.
One aspect of agile adoption - self directed teams - seem to me to suffer a great deal from this behavior. Management agrees to self-directed teams in principle, but as soon as the manager fears loss of control, or loses confidence in the team's ability to deliver, the agile squirrel darts back towards the original side of the street. The command-and-control tendencies return.
Other fits and starts occur when you start taking shortcuts in your approach. "We don't need to do a showcase this iteration; we don't have much to show". Or "We're 98% complete with this story - let's take credit for the story in our burn-up, since we'll finish it quickly at the beginning of the next sprint." I'm sure you can come up with other examples.
These behaviors mirror the squirrel's fear. These short-cuts and adaptations are typically not to improve effectiveness or efficiency, but reactions to fear of judgment. My suggestion: rather than darting back and forth as you cross the road, take a deliberate approach with courage.
I'm sure you've seen a squirrel trying to cross a street. The squirrel starts off on one side of the street, looks, darts out, then sees something scary and retreats. Sometimes he retreats all the way... sometimes he just stops in his tracks. When he starts again, he may continue trying to cross, or may high-tail it back to the original side of the street.
In agile adoption, we sometimes see fits and starts... and retreats - just like the squirrel.
One aspect of agile adoption - self directed teams - seem to me to suffer a great deal from this behavior. Management agrees to self-directed teams in principle, but as soon as the manager fears loss of control, or loses confidence in the team's ability to deliver, the agile squirrel darts back towards the original side of the street. The command-and-control tendencies return.
Other fits and starts occur when you start taking shortcuts in your approach. "We don't need to do a showcase this iteration; we don't have much to show". Or "We're 98% complete with this story - let's take credit for the story in our burn-up, since we'll finish it quickly at the beginning of the next sprint." I'm sure you can come up with other examples.
These behaviors mirror the squirrel's fear. These short-cuts and adaptations are typically not to improve effectiveness or efficiency, but reactions to fear of judgment. My suggestion: rather than darting back and forth as you cross the road, take a deliberate approach with courage.
agileshout
I just recently discovered this StackOverflow implementation focused on Agile issues: http://agileshout.com. Seems to be low traffic at the moment, but perhaps my agile friends can find some value there.
I'm not quite sure why it's necessary to have a separate site from StackOverflow, since the tagging mechanism in StackOverflow permits differentiation of topics (e.g. "agile") and cross tagging of topics (e.g. "agile" and "BI") that might not otherwise find a specific home on a specific site.
I'm not quite sure why it's necessary to have a separate site from StackOverflow, since the tagging mechanism in StackOverflow permits differentiation of topics (e.g. "agile") and cross tagging of topics (e.g. "agile" and "BI") that might not otherwise find a specific home on a specific site.
Wednesday, November 18, 2009
Task breakdown - To do or not to do
I've had this conversation with agile folks over the years. It's about task breakdown. This is not entirely fair, but I'll say it anyway: I consider it one of the "thou shalt" approaches of agile by the numbers... or by the tools.
Assume a master story list with estimates based on points.
The iteration planning meeting (IPM) looks like this:
Foreach Story in Candidate list:
As the iteration progresses, we see this:
Foreach Day in iteration:
Task breakdown smells (and yes, I've seen them all):
I remember my elevated caffeine intake as a developer at interminable IPM's where I just wanted to get on with the work.
I remember debating minutia about whether a task belongs or not, and whether it's 8 hours (by Kurman) or 16 hours (by someone else). Yes - all those issues that the point-level estimating deigns to abstract by using relative estimates can rear their ugly heads in hour-based estimating. (By the way - if your solution is to assign the tasks at IPM time, you'll suffer from other problems).
I remember being the first to pick up a story as a developer and finding a better approach that implied a totally different task breakdown. Yes, I used the new approach, and yes I had to fix the accounting (XPlanner) to reflect my new approach. (Umm... on second thought - I just left the existing task list in place and fudged the actual hours into the old list. You might think this was wrong. I knew, however, in my heart of hearts, that the micro-accounting really didn't matter).
I've also worked with teams that have eliminated task breakdown/estimates and felt freed by the defenestration of the bureaucracy.
This tends to become a heated topic of conversation. In the end, the best answer, I think, is to let the team choose the approach that's right for them. Mandating task breakdown or mandating against it is almost always wrong. Drive the questioning to determine if task breakdown adds value or not, and try it both ways. If you have an agile management tool that requires tasks in order to do reporting, and you want to avoid defining tasks, just create one task per story that says "Do it". (In parallel, find a different tool that provides more flexibility).
scrum terminology decoder:
iteration = sprint
iteration planning meeting or IPM = sprint planning meeting
iteration manager = scrum master
iteration showcase = sprint review = sprint demo
master story list = product backlog (or possibly release backlog)
Assume a master story list with estimates based on points.
The iteration planning meeting (IPM) looks like this:
Foreach Story in Candidate list:
- Product owner: Describe the story
- Team: break the story down into tasks
- Team: estimate the effort for each task in hours
- Iteration Manager: Increment the task hours counter by the amount of the task hours for this new story
- Iteration Manager: Measure the task hours against the team's ideal capacity and report how full
- Team: If iteration is full (based on ideal/actual capacity) leave foreach
As the iteration progresses, we see this:
Foreach Day in iteration:
- Team member: update the remaining task hours for each of his/her tasks
- Iteration manager: udpate/publish burn-down
- Iteration manager: interrogate team members whose tasks are moving "slowly"
- Intra-story progress can be measured by the iteration manager who can address slowness ("John: you reported 2 hours left yesterday morning and today you're still not done... what's up?"
- The aggregate burn-down should show you how close you are to your target on a daily basis
- Tasks become the center of the reporting universe within the sprint and so progress against task completion may mask poor progress against story completion (e.g. due to undiscovered tasks)
- Team "feels" progress based on completed tasks, rather than on the real objective: completed stories
- Weird reward structures get created ("John - yesterday you said you had 12 hours remaining on the task, yet you finished it. Great job!")
- Weird negative feedback is inferred ("John - yesterday you said you had 2 hours left and you're not done yet": inference - you're not working hard enough)
- Daily reporting requirements implies distrust of the team to raise issues or problem: "If I don't keep an eye on the task level reporting, I can't hold them responsible on a daily basis"
- Estimating iteration capacity based on ideal task hours may conflict with iteration capacity planning based on historical velocity. What happens if my hour capacity is reached in the IPM, yet my booked story point total is below my historical velocity? (I'll save the tendency for re-estimation for another blog entry). Reminds me of the old adage - experienced sailors never go to sea with two compasses. They go with one or with three, because if the two disagree, you have no idea which one is right.
- if the team feels that the benefit outweighs the cost
- if a developer or pair needs to break the story down into tasks in order to understand the work to be done, go for it (but don't worry about tracking all the details in a tool)
- Perhaps if your team is not mature enough to understand how to break down a story into tasks, and so you must spoon feed them with tasks (even then, I think it better to have them pair with experienced developers to learn how to become self-sufficient.)
- If the tasks to implement a story can be parallelized (different developers or pairs can be working on different tasks for the same story in parallel)
- If your team has "silo dysfunction" that requires choosing stories that don't overload a skill or domain area on the team
Example: let's say you have a project with equal parts C++, Java, and Fortran code and you have C++, Java, and Fortran programmers who can't span technologies. In order to keep from overloading one technology group, you must choose stories that balance the work across those silos. Sometimes, the only way to create this balance is to task out the work across technologies, to ensure you're not overloading one camp.My feeling: Using the whole team's time in the IPM doing task breakdown and estimating tasks is usually wasteful. I recommend that task breakdown be undertaken, if necessary, at the last responsible moment... when the story moves from "ready" to "in development", rather than at the IPM. The developer or pair picking up the story should do the breakdown.
By the way - removal of this dysfunction over time is recommended.
Task breakdown smells (and yes, I've seen them all):
- The tasks look like this:
Design the code
Write the code
Write the unit tests
QA the code
Why is this an issue? You're probably doing mini-waterfalls, not simple, evolutionary design
- The "remaining work" for a given task is reduced by 8 hours (or perhaps 6) each day
Why is this an issue? Team members are not providing real data, they're telling the iteration manager what he/she wants to hear
- The hour-based iteration burn-down (or, as I prefer, burn-up) is practically a straight line.
Why is this an issue? In reality, many things take more or less time than imagined. Straight lines are an indicator of "cooking the books"
- The iteration manager asks people throughout the day... "How many hours do you have left on this task? When will you be done?"
Why is this an issue? It's command and control leadership and dilutes the power of the self-directed team.
- Iteration Planning Meetings (IPM's) take more than an hour and are more about numbers than about story understanding
Why is this an issue? You spend more time taking swags at hour estimates than you do actually thinking about the functionality to deliver
- The iteration manager applauds the team for accomplishing "400 hours" when their calculated capacity was only "350".
Why is this an issue? It's focused on task hour accounting and doesn't imply anything about how successful the team was at completing storiesI've worked on projects with both approaches - task breakdown with hour-based burn charts and no-breakdown with point-based burn charts. My suggestion is to avoid speculation about the superiority of doing it the only way you've ever done it and at least give each approach a fair shot.
I remember my elevated caffeine intake as a developer at interminable IPM's where I just wanted to get on with the work.
I remember debating minutia about whether a task belongs or not, and whether it's 8 hours (by Kurman) or 16 hours (by someone else). Yes - all those issues that the point-level estimating deigns to abstract by using relative estimates can rear their ugly heads in hour-based estimating. (By the way - if your solution is to assign the tasks at IPM time, you'll suffer from other problems).
I remember being the first to pick up a story as a developer and finding a better approach that implied a totally different task breakdown. Yes, I used the new approach, and yes I had to fix the accounting (XPlanner) to reflect my new approach. (Umm... on second thought - I just left the existing task list in place and fudged the actual hours into the old list. You might think this was wrong. I knew, however, in my heart of hearts, that the micro-accounting really didn't matter).
I've also worked with teams that have eliminated task breakdown/estimates and felt freed by the defenestration of the bureaucracy.
This tends to become a heated topic of conversation. In the end, the best answer, I think, is to let the team choose the approach that's right for them. Mandating task breakdown or mandating against it is almost always wrong. Drive the questioning to determine if task breakdown adds value or not, and try it both ways. If you have an agile management tool that requires tasks in order to do reporting, and you want to avoid defining tasks, just create one task per story that says "Do it". (In parallel, find a different tool that provides more flexibility).
scrum terminology decoder:
iteration = sprint
iteration planning meeting or IPM = sprint planning meeting
iteration manager = scrum master
iteration showcase = sprint review = sprint demo
master story list = product backlog (or possibly release backlog)
Saturday, October 31, 2009
PMO vs. PPM
I have a visceral negative reaction to the PMO initialism; it stands for Project Management Office. I recently pounced (in an overreacting sort of way) on a colleague who was using this term. Sorry Carl.
I need to explain a bit. It's really all about the "O" - for Office.
"Project Management Office" screams bureaucracy to me. I've never seen an efficient and effective PMO. This is perhaps because most of them seem to be mired in "SDLC" - an oft-used euphemism for "waterfall" (despite it's innocuous spelled out translation: software development life cycle).
I once had to sign off on a 19-page document provided by the PMO to justify the acquisition of two load balancers for a test environment. This document had to be signed by 25 people in a 2000-person company. It was a stunning example of the need to feed the process beast. Some project manager in the PMO - who probably thought this process was necessary - filled out this template. My favorite section of the doc was "Metrics". Ostensibly this section existed to establish the metrics upon which the success of this project would be measured. The PM filling it out, indicated that 2 load balancers would be acquired - as if the number "2" satisfied whatever the template providers had in mind for metrics.
If we want to revamp the bureaucratic, inefficient, ineffective approach currently used for managing software project portfolios (the PMO), I think we need a departure from the term.
I'd love for us to agree to focus on the verb - not the noun. A brief digression:
I see many agile teams who use the iteration planning meeting - IPM - or the "sprint planning meeting" if you subscribe to that religion - as the only time in which the development team is exposed to upcoming work (other than, perhaps, estimation efforts that occurred months ago). I coach teams to treat iteration planning as a "verb": planning - rather than a noun: meeting. The "planning" should occur fluidly - some done in meetings before the IPM (e.g. estimation), some after (e.g. task breakdown).
Project portfolio management (the PPM in the title of this post) implies active engagement in assessing the health of the portfolio. The estimated release date or feature list should be adjusted after every iteration, and approaches need to be introduced to raise awareness of the new projections at least this often.
Let's please talk of project portfolio management, rather than project management offices.
I need to explain a bit. It's really all about the "O" - for Office.
"Project Management Office" screams bureaucracy to me. I've never seen an efficient and effective PMO. This is perhaps because most of them seem to be mired in "SDLC" - an oft-used euphemism for "waterfall" (despite it's innocuous spelled out translation: software development life cycle).
I once had to sign off on a 19-page document provided by the PMO to justify the acquisition of two load balancers for a test environment. This document had to be signed by 25 people in a 2000-person company. It was a stunning example of the need to feed the process beast. Some project manager in the PMO - who probably thought this process was necessary - filled out this template. My favorite section of the doc was "Metrics". Ostensibly this section existed to establish the metrics upon which the success of this project would be measured. The PM filling it out, indicated that 2 load balancers would be acquired - as if the number "2" satisfied whatever the template providers had in mind for metrics.
If we want to revamp the bureaucratic, inefficient, ineffective approach currently used for managing software project portfolios (the PMO), I think we need a departure from the term.
I'd love for us to agree to focus on the verb - not the noun. A brief digression:
I see many agile teams who use the iteration planning meeting - IPM - or the "sprint planning meeting" if you subscribe to that religion - as the only time in which the development team is exposed to upcoming work (other than, perhaps, estimation efforts that occurred months ago). I coach teams to treat iteration planning as a "verb": planning - rather than a noun: meeting. The "planning" should occur fluidly - some done in meetings before the IPM (e.g. estimation), some after (e.g. task breakdown).
Project portfolio management (the PPM in the title of this post) implies active engagement in assessing the health of the portfolio. The estimated release date or feature list should be adjusted after every iteration, and approaches need to be introduced to raise awareness of the new projections at least this often.
Let's please talk of project portfolio management, rather than project management offices.
Subscribe to:
Posts (Atom)
