Agile Software Development
Agile software development is a major methodology research area for me. Of particular importance is adapting it to the large, complex programs that I work with on a regular basis. These are just some generic links.
Although project management is not always thought of highly in the agile community, it is a necessity, in my opinion. Learning how to take the best of the project management world and apply it to more adaptive situations is of great interest. These are just some generic links.
Facts are stubborn things; and whatever may be our wishes, our inclinations, or dictates of our passions, they cannot alter the state of the facts and evidence.
— John Adams, December 1770
Be sure you put your feet in the right place, then stand firm.
— Abraham Lincoln
This page lists the most latest entries from my blog. The blog itself is stored on blogger. The five most recent entries are always accessible via a link from the left navigator. The ten most recent entries are displayed on this page. I've found the services API from Google to be somewhat slow, so the information is actually gathered in batch (via cron) and then included here so that the page does not take so long to load. What this means is that there is the potential for this page to be different than the actual blog if the cron has not yet run.
Sat July 26, 2014 (6:25 am)
|Before and After: Alignment and colors corrected.|
|Canon's Digital Photo Professional with AF Point(s) shown.|
|Two stacks of bracketed photos. Note that there are very few visual cues excepting the "" at the beginning of the stack and the very light line break at its end.|
|Two stacks of bracketed photos. Selecting a photo reveals its position relative to the stack's beginning and end.|
|Two stacks of bracketed photos. Coloring the stacks made them stand out for me.|
|Editing in Photoshop from Lightroom.|
Wed July 16, 2014 (12:17 pm)
|Is now the time to move to Adobe Lightroom?|
Sat November 3, 2012 (5:20 pm)
|Image credit: gow27 / 123RF Stock Photo|
1. not ever : at no time < I never met her>
2. not in any degree : not under any condition < never the wiser for his experience >
Source: Merriam-Webster, http://www.merriam-webster.com, accessed November 3, 2012What happens if the platform substantially deteriorates, like Blackberry's did? Would they still not switch? What psychological drivers are at work here? Perhaps there is some sort of platform attachment psychosis in play or perhaps some of these individuals were personally burned when using the competing platform. Maybe they are just surer of themselves than I am. As an eight year Blackberry user that switched to an iPhone earlier this year, I can tell you that Apple does not have a lock on my business: if I find something better when my contract is up, that will be the next smartphone for me.
Fri October 19, 2012 (9:47 pm)
|Blogger's Advanced Blog Address Settings|
|Modwest's DNS Configuration Settings (Fragment)|
Mon May 21, 2012 (12:45 pm)
While this does not follow my normal thread about software, it is interesting to me on a personal level (and I'll link it to software at the end). Those who know me well know that I have had my share of interesting travel experiences. From delayed flights to subsequent missed connections to natural disasters that have stranded me one place or another, I am never at a loss for a good travel story.
As I write this, I am experiencing something a little different from the past. As our plane was waiting in line to take off, it was called back to the gate to pick up a passenger whose bag made it on the plane, but they did not. Because of the return trip, they also need to refuel the plane. When the passenger came on board, air marshals accompanied the person.
We now await at least two things before we can push off from the gate again: first, the refueling needs to be completed (wonder if the late passenger gets to pay for that? Stranger things have happened); second, the person in my row that got up to go to the bathroom about 15-20 minutes ago needs to return. There are probably a couple other things, but those two would seem to be a must.
It will be interesting to see how long we will be waiting and how late we subsequently arrive at our destination. The flight is a long one already: 13+ hours from Newark, NJ to Beijing.
Getting back to software: The airline and/or airport knew they were missing someone whose baggage was loaded onto the plane, yet not soon enough prior to departure to do something about it and save a return trip to the gate. Enhancing their capability to detect this type of issue prior to departure could save them some money and possibly protect their on-time rating (not to mention keeping people at ease): a software enhancement worth thinking about.
Wed April 4, 2012 (11:14 pm)
Wed July 20, 2011 (8:42 am)
|Canon T70 35mm Camera|
|Canon 7D Digital SLR Camera|
Fri October 22, 2010 (9:05 am)
In my last blog entry, I wrote about an agile review that I was preparing to conduct with one of my teams. This team began using the agile software development methodology in earnest in late July after receiving training. At that time, several experienced agile scrum masters and independent coaches were inserted to help guide the transition. I noted specifically that the team has some characteristics that make an agile implementation challenging and success uncertain: the team's overall size is greater than 80 individuals and growing; there are inter-organizational and leadership dynamics in play that could derail the implementation; and the technical environment (SAP), with its functional orientation, poses a unique technical challenge.
The data-gathering portion of the review ended on October 8. As hoped, the number and variety of input sources and forums for leaders, coaches, mentors, practitioners, and customers proved to be quite robust. Indeed, this review approach yielded more data than one could hope to analyze in a short period of time—particularly when other responsibilities begin to intrude. Despite my initial worries, gathering input is the easier part of the review. What remains is much more difficult: fully understanding the data that was gathered, deriving major themes, identifying recommendations, and implementing those recommendations, as appropriate.
While the review is still incomplete, some themes have begun to emerge that suggest the characteristics of this team's working and technical environment are not driving a significant number of unique challenges and problems. That is, many of the concerns raised by the team and their leadership are reminiscent of earlier agile implementation experiences: difficulty breaking down epic user stores, an initial inability to size in story points, general role confusion, problematic team communications, and getting good quality user stories and acceptance criteria. Nonetheless, there are some themes that do appear to be unique or, perhaps, this team has a different spin on an otherwise generic theme.
Iteration planning is of particular concern in part due to the functional orientation of the team and the underlying product. The functional orientation of the product makes planning an iteration challenging in that the stories selected need to match the team's composition or the work contour will be uneven. This implies that a potentially higher priority story might have to take a back seat to a slightly lower one because resources may not be available to complete it during the iteration. This is not wholly unique—other agile teams also run out of resources—but it is more acute because the functional breakdown of the team is so granular. To smooth out the work contour means you need to know more than just the team's velocity. As one colleague aptly put it: you need to identify and understand the micro-velocity by functional orientation to be successful. In addition, the team does not have a rigorous planning background to fall back on: they are learning it as they learn agile.
The technical infrastructure surrounding the application and the functional orientation of the product presents unique challenges. The inter-dependencies between modules (which also effect planning) are somewhat mind-boggling. Too, the ability to keep various environments synchronized has become an issue, though not one due to the implementation of agile. Regardless of the source, it is clear these items will need to be addressed as they are a systemic source for blockers during and after an iteration.
Meeting overload. One of the things that came through loud and clear was that practitioners and leaders felt that they were attending too many meetings. The team itself is distributed, so some "meeting creep" is expected, since in-person communications are not always possible. But, the prevalence of the sentiment shows that it is a larger issue than just adding a 15-minute scrum and another 15-minute scrum-of-scrums call during the day. While there are instances of people who do not need to attend certain meetings being expected to attend—much of which has already been rectified—we failed to consider the impact of these additional meetings on an apparently already busy meeting schedule. In fact, existing meetings have grown to encompass much of the same material covered in the scrum of scrums meaning we now have some redundancy.
More to Come
Preliminary insights are just that: preliminary. They only give a hint of the direction you may eventually need to follow. Assuming I can wade through all the data with my review team in a timely manner I am sure we can figure this out. I am also sure we will find a lot more.
Sun September 19, 2010 (10:25 pm)
In a couple of weeks, I am going to be performing a formal review of our progress implementing agile software development practices for one of our sub-teams. While agile is a deeply ingrained methodology for most of our team, this one area has some unique characteristics that make adoption both interesting and challenging. Indeed, the team's size (greater than 80 individuals and growing), the inter-organizational and leadership dynamics in play, and the technical environment (SAP) mean that success is not assured. Nevertheless, there does not appear to be anything in this environment that would rule out the implementation of some form of agile software development. While all environments are not created equal, higher productivity, higher quality, and increased developer and customer satisfaction have accrued from past implementations.
Selecting What to Review and How to Review It
Preparing for a review of this magnitude can be stressful. Each decision made in preparation has the potential to expose useful information and provide a deeper understanding of the team and the environment in which they are now working. Unfortunately, those same decisions may inadvertently suppress useful information, resulting in a faulty analysis that generates incorrect conclusions and follow-on actions. A deep understanding is necessary to determine what is truly working well and what is just not working at all—it has ramifications on what happens next.
Multifaceted Approach. Gathering the correct information is essential for any successful review. Since information can be lurking in unexpected places, the best approach would seem to be a multifaceted one. That is, using several different techniques may be the best way to reduce the possibility of missing something important. To best understand what the team is experiencing on a daily basis, staying away from using the review period to question people about performance metrics would also seem prudent. Those types of questions tend to make people uncomfortable and, more importantly, a team that has just begun using agile is not going to fully understand what those metrics mean or how they are influenced. Instead, all of the review techniques selected thus far are intended to pull meaning from each of the interpersonal interactions. They are also intended to help the team better understand their own performance and allow them to think through what they might need to do to make this successful: a tall order.
The Mini Retrospective. Those familiar with agile have most likely heard of the project retrospective. Nevertheless, most have never actually participated in one—at least not along the lines proposed by Norm Kerth . A full-blown review is time consuming, but rewarding. On the other hand, this review is not about a single successful or troubled project (not yet, anyway). Instead, its focus is on gathering enough information about the new methodology surrounding many the projects in this area and to understand where things are going well or poorly. Variations of two exercises that Kerth proposes are well suited to enable the type of breakthrough thinking that will allow the team to explore what they are experiencing: the "develop a time line" exercise [1 pp. 121-126] and the "emotions seismograph" exercise [1 pp. 127-130]. For good or ill, this part of the review is being called a "mini retrospective." While the name may be a bit generous, the goal of deeply understanding what the team is experiencing is the same. Because only a couple of hours are allocated for each scrum team, there there will need to be some work done by the team prior to the discussion so that the entire time is not spent creating the time line.
Talk to the Individuals. You can learn a lot from a conversation if you ask open-ended questions and listen carefully. When your attention is on more than a person's words you become aware of their underlying mood, energy level, and attitude. You can also develop a better understanding of the person you are listening to. This is called Global Listening—it is sometimes also referred to as level three listening. It seems reasonable to conclude that the ability to listen will determine whether these sessions are ultimately successful. (As an aside, I learned about the three types of listening from a class I took earlier this year. I found a pretty good summary of the three levels themselves, if you are interested ).
Getting the Team Together. As important as individual conversations with selected team members are, it is just as important to schedule time with the various sub-teams within the wider team to gain insight into the entire group—insight that might not otherwise appear in a one-on-one setting. This group has a complex matrix management structure. That means that there are several different types of groups from which to gather information: the scrums themselves, the management team, the functional leadership team, and the business team, to name a few. These types of gatherings are often called round tables after the table used by King Arthur and his knights: such a table does not inherently grant precedence to any one person. That description seems appropriate for this part of the team review. By maintaining equanimity, individuals are given a forum and the freedom to discuss collective matters of importance about the team, the methodology, or any other pertinent topic.
Let the Leader Present Their Findings. It always seems best to have the people leading a team take responsibility and ownership for conveying the major themes discussed during the early part of the review with their local management team. This may be somewhat counter-intuitive, but the theory is that by having the team's leader present the findings that they and their team worked so hard to identify will help ensure that the information is complete and accurate. This has the added benefit of giving them visibility to their local management team and giving an overall insight into their dedication and competence.
The aforementioned techniques are intended to cover an array of individual and group meetings during the review. Missing is how we intend to conduct an analysis of the information gathered and how conclusions will be drawn. While these rather important topics remain partially open as of this writing, one thing seems clear: a tentative summary of findings should be available to the team quickly -- before the on-site review period concludes. This will give the review team additional feedback and serve as a further assurance that something important was not missed.
In a few weeks, I will know whether any of this was effective. Either way, I am sure I will learn something.
 N. L. Kerth, Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing, 2001.
 S. Smith, —The Three Levels of Listening—, http://careersintheory.wordpress.com/2009/09/08/three-levels-of-listening/, 2009, Accessed September 19, 2010.
Sat August 21, 2010 (10:44 am)
Last month, I read an article in Newsweek that put into words a fear I have been having about creativity in America. The article, "The Creativity Crisis" by Po Bronson and Ashely Merryman , appeared in the July 19, 2010 issue of Newsweek and can still be found online.
A little background: The article refers to scores on a creativity test originally developed by Ellis Paul Torrance in the late 1950s and formalized in 1966 as the Torrance Tests of Creative Thinking . The test is similar to an intelligence test in that a psychologist administers it and it requires the performance of discrete tasks over a fixed duration. Instead of deriving an Intelligence Quotient (IQ), it derives a Creativity Quotient (CQ). The article briefly explains the difference between the two tests noting that while the IQ test is subject to the Flynn effect —"each generation, scores go up about ten points," which requires the test to be re-normalized periodically to maintain an average score of 100—while the CQ test, apparently, is not. The implication is that scores on an IQ test may be inflated between re-normalizations. It is unclear to me whether CQ tests can suffer from a similar phenomenon and whether any comparison to past results is truly valid: the article assumes they are. Nevertheless, up until 1990, CQ scores were steadily rising. Since 1990, they have been consistently falling with the decrease in younger children between kindergarten and sixth grade being regarded as the most significant.
While it is unclear whether the premise of the problem presented within the article is completely factual—popular magazines tend to skew information to their audience, do not provide peer reviewed references, and are not themselves peer reviewed—I believe the issue itself is real. The vast information we now have available to us via the Internet and the latest trend toward social networking and online communities would seem to be positive development. Indeed, the recession-induced workplace of 2010 with its "always on, always available" philosophy would also seem to be a boon to businesses, albeit somewhat temporary. The negative, in my opinion, is that these advancements in information availability, trends toward hyper-connectivity, and workplace expectations are systematically eliminating the time available to assimilate and process information: to allow people to think through what they have seen and learned and come up with new ways of solving problems or doing things better.
The need for assimilation time does not mean I think that we should never have deadlines or that we should not attempt to complete our various projects (personal or professional) in a timely manner. Indeed, I have found that in some cases these pressures can help me find new ways of doing things (out of necessity). Yet, these solutions are often not of the same quality as when I have a chance to think them through. While they tend to get the job done in the short-term they may be one-time solutions that cannot be easily repeated or transformed into longer-term success. For me, those ideas that have lasted are those that I had the time to think through, try with some willing participants, and modify upon some reflection and with the input of those same participants. The process is not linear and certainly not easily scheduled against an arbitrary time line. I suspect this is also true of others.
Unfortunately, time is often seen as something that needs to be consumed efficiently and completely. Thinking about new things or reflecting on your experiences does not give the appearance of being productive—at least in the short-term. Nevertheless, I believe this is an essential part of living a full and complete life and is an integral part of determining whether a business ultimately survives or withers away. Most disturbing to me is that I have also come to believe that this is equally applicable to a country that depends on its innovation and creativity.
We ignore creativity and its potential decline at our own peril. As the cartoonist Walt Kelly wrote in 1952 and later modified and attributed to his Pogo Possum character for the first Earth Day in 1971: "We have met the enemy and he is us."
What will we do to ensure we keep our creative and innovative edge? Our future depends on how we answer this question.
References / Links
 "Ellis Paul Torrance", http://en.wikipedia.org/wiki/Ellis_Paul_Torrance, Accessed August 21, 2010.
 P. Bronson and A. Merryman, —The Creativity Crisis—, Newsweek, vol. CLVI, no. 4, pp. 44-50, July 10, 2010, http://www.newsweek.com/2010/07/10/the-creativity-crisis.html.
 C. Graham and J. Plucker, —The Flynn Effect—, http://www.indiana.edu/~intell/flynneffect.shtml, 2001, Accessed August 21, 2010.