The pacesetter?

Pacesetting is a leadership style based on the premise that the leader’s manner of doing things is best. While the intentions may be noble (getting the project done) it’s a form of ego and can border on recklessness. Often times the individual doesn’t even realize that he/she is exhibiting classic signs of this leadership style.

First and foremost, we must recognize that agile development can provide a wealth of opportunities to act as a pacesetter. Consider the effect of one week iterations: given the right circumstances, at the end of every week there’s an opportunity to be a hero – to ensure that the team makes the weekly commitment goal. Another problem is that immature product owners can take advantage of pacesetters, pressuring them to add little features, and with agile’s emphasis on collaboration, there is often no way of telling (e.g. no documentation and change control) that the pacesetter is allowing micro bursts of scope creep. The technique of pair programming provides another prime opportunity for the pacesetter to be the center of gravity for getting things done, leading (or pushing) the pairing partner. Self selecting stories from the backlog can easily turn into a game where the pacesetter assigns him/herself to an inordinate number of stories early in the sprint – effectively marking many stories “in process”.

Agile development can also be a threat to the pacesetter’s sense of control – which can exaggerate the negative behavior. Agile emphasizes whole team participation, responsibility, and rewards. The pacesetter may feel lost and long to add value as an individual.

Back to product owners

So what's it take for a product owner to work well?

Observations:
• Technical people (i.e. former or current developers) can make poor product owners as they can tend to focus on the technical rather than business side of the house.
• Some of the best product owners are those that are very close to the customer.
• A manager may be a poor product owner because they tend to see the product in terms of tasks rather than features.
• Rotating a product owner causes quite a bit of churn. Don’t do it.
• Multiple product owners can be a bad idea unless they can collaborate together. Multiple product owners can be just as bad as multiple managers trying to manage one project.
• Product owners must be organized enough so they have stories ready for the sprint planning session.
• Business analysts can make good product owners as can technical sales people and product trainers.
• Look at the values of the agile manifesto and make sure your product owner can buy into them.
• If multiple stakeholders are involved in the product, you need one product owner to represent them. And that one representative must have the authority to make decisions without constant negotiation of the other stakeholders.

Word Cloud generators?

I had an interesting experience, I created a word cloud of my resume.  Have you tried wordclouding unusual items?   I've seen it done on code (if you remove the comments).  I used wordle. Pretty cool.

Product owners?

What are some of the things to look for when starting up an agile team and choosing the product owner?

-->

A good product owner must have:

Knowledge

·      Knows enough about the product to create and maintain a backlog – can write reasonable requirements and eventually stories.

·      Knows enough about the product and it’s context to conveys the vision and goals of the project and each sprint.

·      Understands the needs of the customer.

·      Knows enough about the technology to make reasonable decisions.

Authority

·      Can carry through the result of any tough decisions.

·      Owns the product success (or failure), so can prioritize the backlog and eliminate stories if they’re not high value.

·      Represents the customer, interfaces and engages the customer.

·      Can change the course of the project at the end of every Sprint.

·      Can terminate a Sprint if he/she determines such action is required.

·      Has the recognition to communicate status externally.

Availability

·      Has the time to work on the product backlog, despite other responsibilities.

·      Can actively participate in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives.

·      Has enough time to quickly respond to questions (that day) and sit with the development team when needed.

·      Actively inspects the product progress at the end of every Sprint and has complete authority to accept or reject work done.

Aptitude

·      Able to resist the temptation to micromanage.

·      Not be afraid to make tough decisions.

·      Able to work in a team environment.

·      Focused, proactive, and engaged in the product.   

·      Good negotiator.

·      Deeply interested in helping the team be successful.

·      A “People Person” with patience.

·      Willing to learn and flexible enough to deal with the changes of agile.