Thursday, October 27, 2011

iPhone 3GS Upgrade to iOS 5

I've been using iOS 5 for a week now. It's installed on a iPhone 3GS. The upgrade was a little painful because of the time it took but relatively easy overall.

To obtain iOS 5 you need iTunes 10.5. This is a large download around 500MB in size. There was also a Lion upgrade available. You need to Lion upgrade if you want to tie both your phone and your computer to iCloud but you don't need the Lion upgrade to use iTunes 10.5 (see the iTunes System Requirements).

Saturday, October 22, 2011

Story Points and Velocity

I am re-reading Mike Cohn's book "Agile Estimating and Planning". Chapter four, "Estimating Size with Story Points", introduces the concept of story points and velocity.

Story points represent a relative estimate of the complexity, size or risk in a story. As a relative measure the focus is on assigning stories of similar complexity, size or risk the same number of story points. A relative measure simplifies estimation because it separates size from duration.

Velocity is a measure of the number of story points a team completes in an iteration. Use common sense when managing velocity. For example, if someone takes a day off during the week their contribution to the team's velocty should be reduced.

Velocity also provides the abilty to correct estimates as velocity changes without having to re-estimate the stories themselves. For example, a team with a velocity of 25 might find itself moving closer to 20. This change increases the duration of the project because the total number of story points is known but the rate at which they are completed is reduced.

Duration is derived on Agile projects. It is derived by observing a team's velocity. Duration is the number of story points in a project divided by the team's velocity.

Duration calculations using velocity need to be considered in light of the assumptions velocity brings with it. For example, such calculations assume that all things remain equal over the course of the project. This means that personal changes on a team will impact velocity. It also means that duration calculations should bear in mind the lessons of the cone of uncertainty.

Monday, October 17, 2011

What Are Projects?

I am re-reading Mike Cohn's book "Agile Estimating and Planning". In chapter three, "An Agile Approach", Mike references an article by Hal Macomber entitled "Achieving Change in Construction". Hal's article pulls the main points from a study conducted on the construction industry with the same title.

Hal's article made me aware of a misconception of mine about project management in the construction industry. My view up to this point was very limited--I was under the impression that project management in construction was well understood and effective. Hal's article pointed out that even a well established industry can have its issues.

This article proved useful to me because it summarized in a couple of sentences what I believe is a key motivation behind adopting Agile methods:
... suggest there are two complementary approaches for achieving change. The first has to do with producing economic value. They argue that people will adopt an approach that produces higher value. They couple this with a high involvement high learning organizational approach. High involvement will bring about the change.
People will use an approach that produces higher value. If you add this to an approach the embodies high involvement and learning then the approach should be self perpetuating and result in real positive change.  For me, these two sentences really make explicit the motivation for Agile methods.

(The links in Hal's article to the original paper are dead. Use instead.)

Wednesday, October 12, 2011

Manifesto for Agile Software Development

I am re-reading Mike Cohn's book "Agile Estimating and Planning". In chapter three, "An Agile Approach", Mike references the Manifesto for Agile Software Development. A lot has been written about the manifesto. I won't add much.

Two important things stand out when I read the manifesto that I think are very enlightened. First, I like the acknowledgement that we are still learning how to develop software better. Second, I like the emphasis on people rather than tools and process.

The first point reflects an enlightened view of software development, particularly if you view software development as knowledge acquisition. You are learning how to do something that perhaps no else is doing. That is a hard job and worth acknowledging.

The second point reflects an enlightened view of software development because it recognizes that people are the important element in the creation and use of software. The shift in focus is a stroke of genius. It reflects a change in understanding around who is developing and using the software.

Friday, October 7, 2011

Toss Out Productivity

A recent post on ZenHabits entitled Toss Productivity Out has piqued my interest. The title says the post is about productivity but a lot of the content strikes me as a comment on the benefits of understanding your priorities. Understanding and focusing on priorities simplifies your life.

Take the simplification argument used against getting organized. If you simplify you are effectively making choices on importance. If not then you introduce complexity into your life. Simplification forces you to prioritize. If you focus your priorities life becomes simpler.

The same argument can be made on the number of goals you set. And again for focusing on a couple of things to be done during the day instead of keeping detailed context lists.

The post makes other points against productivity methods. These look like an argument against selecting productivity methods that don't help you identify what's important.

In all, the important message is about managing priorities and about selecting ways that support the identification of your priorities. Evaluating your productivity methods in light of how they help you determine your highest priorities and then focusing on them is a great way to simplify.

Sunday, October 2, 2011

Estimates are Not Commitments

I am re-reading Mike Cohn's book "Agile Estimating and Planning". It's turning into a good opportunity to take a second look at the references. In chapter two, "Why Planning Fails", Mike references an article by Phillip Armour "Ten Unmyths of Project Estimation" published in the November 2002 issue of  Communications of the ACM.

Mike's main point for referencing the article is to link the idea that an estimate represents a probability of completing a project but that it often become a commitment to an end date. I view this as a variation of the idea presented in chapter one "The Purpose of Planning" and what the concept of the cone of uncertainty teaches us.  The two reenforce the point that estimates are not 100% accurate.