Another second Friday, another completed Iteration. This particular Iteration had a lot of carryover from the last one. Many stories were code complete but were not accepted by stakeholders due to lack of availabilty. A lot of those were accepted. Most of the stories that are required for the upcoming release are accepted or will be early Monday.
Next Iteration will be a "Qualification Iteration". This means that there will be little or no new features added during the next 2 weeks while we submit release candidate builds to Customer Support to run real-world tests. The goal is to have a real RC1 by Wednesday. We may also do a late night Wednesday or Thursday night and provide dinner to the Support group and Development to encourage a focused testing window of 2-3 hours so we can try to flush out regression defects sooner rather than later.
Our plan is to do Qual Iterations at the end of each release. A typical release cycle will be some number of normal scrum cycles where we accept a set of stories and defects. After all the feature-adding cycles we will have 1 or 2 Qual Iterations at the end of the cycle for a short Release Candidate period. External customer participation will be welcome as well to increase real-world testing.
On another topic, I have discovered 2 or 3 new blog sites that I am now following. These are great personal development blog sites that provide lots of positive thought-provoking inspiration to "be" better. We all want to "be" better, right? The better we "be" the better we "do". Take care of the "being" and the "doing" will follow.
First up is The Art of Manliness. This blog is an entertaining and informative resource with articles, blogs, and advice on how to be a better man. Even though it's primarily for men, there is a lot of good general advice for better "being". Man up!
Next is, Change Your Life. This is a more general recording of someone's personal journey toward self improvement. Again, lots of great thoughts and insights.
Finally, although I was not too impressed with the entire site, the Fifty Habits of Successful People was a good read. How many of these do you do? How many of them do you need to think about doing? Read them often.
I thought these sites were very good uses for blog sites. Spreading positive thinking is always good. We have enough negativity and fear already. We need more positivity, faith, courage and confidence.
Saturday, September 12, 2009
Fear
Fear has been the topic of many books and essays. It is viewed in most enlightened theological viewpoints as being in direct contrast to Faith. Fear is an ingrained emotion and instinct that we have inherited from our pre-historic ancestors. It is necessary to survival. Without it we'd always take unnecessary risks and have no caution when we should be. However, fear can sometimes control our lives in conscious as well as unconscious ways. It can cause us to behave very irrationally and create a life that is limited and paranoid.
Fear can be focused on many different targets. Fear of the unknown. Fear of the unfamiliar. Fear of death. Fear of life. Fear of authority. Fear of losing. Fear of winning. The list goes on and on. Fear controls us when we are not aware it is doing so. We control Fear when we are aware of it and then let our reason enter the arena to rationally check and analyze the source of the Fear. The book "The Science of Fear" refers to Gut and Head to describe how fear arises as an emotional reaction and reason is need to check Gut lest the Fear turn into a mushroom cloud overshadowing more balanced actions.
One response to Fear is to step back and look at what is actually known about the situation. Here, statistics can be very beneficial. Getting and knowing good statistical information can be difficult in our culture where selling Fear is more profitable than selling Faith. Saturation with media is a big problem when statements are made without being backed up or compared to relative statistics or information. Many times, once something is stated by a public figure, it takes on the stature of a fact, no matter how weak the support for the position might be.
Once whatever is responsible for the Fear is recognized and understood as some level of risk, Faith can drive through the Fear with strong belief in a positive outcome. We should move forward in Faith and Confidence, knowing that the outcome we desire will prevail and take actions that support progress toward positive ends that move forward.
Fear can be focused on many different targets. Fear of the unknown. Fear of the unfamiliar. Fear of death. Fear of life. Fear of authority. Fear of losing. Fear of winning. The list goes on and on. Fear controls us when we are not aware it is doing so. We control Fear when we are aware of it and then let our reason enter the arena to rationally check and analyze the source of the Fear. The book "The Science of Fear" refers to Gut and Head to describe how fear arises as an emotional reaction and reason is need to check Gut lest the Fear turn into a mushroom cloud overshadowing more balanced actions.
One response to Fear is to step back and look at what is actually known about the situation. Here, statistics can be very beneficial. Getting and knowing good statistical information can be difficult in our culture where selling Fear is more profitable than selling Faith. Saturation with media is a big problem when statements are made without being backed up or compared to relative statistics or information. Many times, once something is stated by a public figure, it takes on the stature of a fact, no matter how weak the support for the position might be.
Once whatever is responsible for the Fear is recognized and understood as some level of risk, Faith can drive through the Fear with strong belief in a positive outcome. We should move forward in Faith and Confidence, knowing that the outcome we desire will prevail and take actions that support progress toward positive ends that move forward.
Tuesday, September 1, 2009
Agile Update
We completed our third Agile iteration last week. Each iteration we've done has been a bit different from the other. Our first goal is to simply learn to iterate. It sounds so simple, right? Just agree on a set of work to try to complete within a 2 week span and get on with it. For the most part, we have been successful at a basic level. Each iteration has started on a Monday and ended the following Friday. However, some observations are worth mentioning.
First, the background of the team was minimally controlled anarchy. It was an approach that has taken them very far. For most of the past history the team has been very small. We have grown the team by 2 or 3 new members over the last several months. The total is 9 developers, 2 test engineers and 1 technical writer. It is a good-size team for experimenting with Agile.
Before starting the first iteration we had trialed and adopted Rally as an Agile project management tool. Having this tool in place made it easier in many respects to be more successful that if we had not done that. For one thing, it allows us to be a "little" Agile in that we actually work more like an iterative development team with very short iterations than a true Scrum or XP approach. Adopting one or both of those approaches would have been a pretty radical culture shift for the team.
The first iteration felt a little frazzled. Some team members were stressed about getting everything done in 2 weeks, even though we had carefully scoped the work to fit. The additional urgency around actually committing to being done at the end of two weeks added energy to the team. Also, there were lots of questions about how to handle process-related things that came up. We learned a lot about Rally and how to use it to enable more efficient communication paths.
The second iteration felt a little more natural. We accepted a very high percentage of the work we had set out to accomplish. There were many less questions along the way and we adapted some of the practices we tried in the first iteration to be more natural in the second.
The third iteration was completely different. First, we started with much more committed work. We ended up only accepting about 45% of the work by the end of the iteration. That was good in that we learned that we can push work if it is not done and not feel too badly about it. Our average productivity over the 3 iterations was respectable. Pushing so much work into the next iteration renewed a commitment toward really being "done" with a story and not just chopping it up to make it fit within an iteration.
We had our first retrospective this past Monday at the beginning of the fourth iteration. The comments from the team were focused on how we get better at doing iterations. One common theme was the desire to do better at transtioning from one iteration to the next. Suggestions for a demo/planning day at the end of the iteration and more time discussing the stories at the start of an iteration were voiced. This will probably be the one thing we work on in this current iteration.
At this point our focus is on using iterations as a synchronization mechanism. We are not having daily standups (although we do send daily email status reports to the entire team with the same format as Agile standups). We do not do a good job of grooming the backlog and having stories fleshed out before we start the iteration. We are using an adjustment in "points estimation" that couples us a little too closely to concrete ideal time estimates. We also have to react to changes mid-iteration due to customer demands or whims within the company.
These are all things that need to be addressed over time if we are successful at getting real buy-in from other departments in the company.
First, the background of the team was minimally controlled anarchy. It was an approach that has taken them very far. For most of the past history the team has been very small. We have grown the team by 2 or 3 new members over the last several months. The total is 9 developers, 2 test engineers and 1 technical writer. It is a good-size team for experimenting with Agile.
Before starting the first iteration we had trialed and adopted Rally as an Agile project management tool. Having this tool in place made it easier in many respects to be more successful that if we had not done that. For one thing, it allows us to be a "little" Agile in that we actually work more like an iterative development team with very short iterations than a true Scrum or XP approach. Adopting one or both of those approaches would have been a pretty radical culture shift for the team.
The first iteration felt a little frazzled. Some team members were stressed about getting everything done in 2 weeks, even though we had carefully scoped the work to fit. The additional urgency around actually committing to being done at the end of two weeks added energy to the team. Also, there were lots of questions about how to handle process-related things that came up. We learned a lot about Rally and how to use it to enable more efficient communication paths.
The second iteration felt a little more natural. We accepted a very high percentage of the work we had set out to accomplish. There were many less questions along the way and we adapted some of the practices we tried in the first iteration to be more natural in the second.
The third iteration was completely different. First, we started with much more committed work. We ended up only accepting about 45% of the work by the end of the iteration. That was good in that we learned that we can push work if it is not done and not feel too badly about it. Our average productivity over the 3 iterations was respectable. Pushing so much work into the next iteration renewed a commitment toward really being "done" with a story and not just chopping it up to make it fit within an iteration.
We had our first retrospective this past Monday at the beginning of the fourth iteration. The comments from the team were focused on how we get better at doing iterations. One common theme was the desire to do better at transtioning from one iteration to the next. Suggestions for a demo/planning day at the end of the iteration and more time discussing the stories at the start of an iteration were voiced. This will probably be the one thing we work on in this current iteration.
At this point our focus is on using iterations as a synchronization mechanism. We are not having daily standups (although we do send daily email status reports to the entire team with the same format as Agile standups). We do not do a good job of grooming the backlog and having stories fleshed out before we start the iteration. We are using an adjustment in "points estimation" that couples us a little too closely to concrete ideal time estimates. We also have to react to changes mid-iteration due to customer demands or whims within the company.
These are all things that need to be addressed over time if we are successful at getting real buy-in from other departments in the company.
Subscribe to:
Posts (Atom)