Another agile correction

If you're trying to find information about agile on the internet, I hope you've found that there is a lot of wrong information out there. Let me give you an example.

Here's a response based on the question of lean relating to agile.

"Many of the principles will find an echo in a Lean principle too, but one fundamental difference to keep in mind: Lean does NOT talk about iterations - only about reducing work-in-progress and delivering early. So you can be Lean without doing any iterations, but you cannot be Agile without iterations."

This is an interesting statement: "you cannot be agile without iterations". I think Mary Poppendyke, David Anderson, and many, many other agile leaders would find this untrue. The Scrumban approach as well many of the articles I've read about Kanban focus on flow and still claim they are agile without iterations. I think Mary Poppendyke believes that lean is agile dispute not having iterations.

I suppose saying that agile requires iterations really depends on what you would define agile as. In my world, an agile project or team is one that consciously follows the values of the agile manifesto. The team may not be completely successfully at attaining the agile values, but understanding the values and moving in a direction that aligns with the manifesto means you are agile.

Small stories

If your stories are small, discrete pieces of work, Kanban fits well – no one story choked the backlog and stories didn’t need to be completed in groups. The business then has the flexibility to change the backlog of any story not on the Kanban board which means the process allowed the business to keep up with the development team. The business focuses on fewer stories, meaning that the stories they did focus on are of much higher quality. Keeping only 2 critical stories in the product backlog at any one time (limited by WIP), enables a fluid prioritization of the rest of backlog. The business team, who determines the content of the stories, is able to focus only the top few, leading to better time management and clearer stories.

Correction on Agile

If you're trying to find information about agile on the internet, I hope you've found that there is a lot of wrong information out there. Let me give you a couple of examples.

In a study group about agile certification, the question came up about iteration length. One of the participants posted the following;

"Sprint duration is fixed ONLY after some smiler (sic) Sprint cycles have finished so there is no such duration fixed (sic). Books may recommend some durations for understanding purposes and in practical (sic) smaller the Sprint, more effective it is.Once the Sprint is longer than 1 month or so, then again it effects its agility anyway(sic)."

Where did that come from? What does this mean? I wonder. Scrum.org paints iterations as time boxes of fixed length. Varying sprint lengths make it difficult to judge how much can be completed or do any type of forecasting. Sprint lengths are set and shouldn't vary - based on Schwaber, Cohn, Fowler, and more.

I have other examples I'll explore next month

Successive Refinement of Requirement/design

In agile, requirements are progressively detailed, with the finest details being developed as late as feasible. There are three main reasons for this just in time requirements detailing: no time is wasted on requirements that are possibly not going to be developed, decisions about requirements can take into account lessons learned in prior sprints and the requirements fresh in the mind of the team when they begin developing because the lag time between specification and implementation is short. Enabling flexibility in the requirements backlog and minimizing wasted work are just as important as detailing the requirements.

Design documentation has its highest value in helping work out the details of the software under construction, not as post implementation documentation. As a post-implementation artifact, documentation must be kept up to date with the software which adds to the cost of any software changes. If the documentation is even slightly out of date, the documentation looses credibility – the code becomes the ultimate documentation. Unless the documentation is automatically generated, design documentation is of limited value and should be prioritized low.

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.