1 May 2008, 10:35 pm
There’s nothing like a dose of humility to remind us all that even the best plan can wind up a disaster if we aren’t careful. Take my own personal example of a 5K race I recently “ran”. This is a very hilly 5K race I’ve run in the past, but to make a short story even shorter, the picture below tells the tale. The green line represents the actual race course, and the red line represents the scenic tour that I decided to add to the race this year.
Besides more than tripling my normal time with a 60 minute 5K record, I learned a few things along the way. First, taking frequent checkpoints of where you are cannot be underestimated. If you are an Agile purist, this means short iterations – two weeks preferred. Second, just because you’ve been there before doesn’t mean this time will be the same. To emphasize this point, I like the quote “if you feel comfortable, you should be uncomfortable” (author unknown), and my discomfort was only compounded when I had to stop and ask a local resident for directions on how to get back to the finish (twice). And last, the hare doesn’t stand a chance against a tortoise that knows about the first two lessons.
10 December 2007, 10:23 pm
Have you recently told someone on your team to do something? If so, there’s a good chance that some management training may be in your future. (Disclaimer: This blog post doesn’t just apply to software development.) We often hear that the command-and-control style of management is the “old way”, and removing roadblocks is the “agile way”. While this sounds like a good thing every time we hear it, there isn’t a quick and easy way to determine how to adjust. I often find that it’s difficult to take many of these self improvement suggestions and act on them, so I prefer internal triggers that can shape behavior in an ad hoc manner.
In this case, the key trigger is simple asking/telling someone to do something. What?! Our internal voices may find this proclamation to be borderline-insane as this is method by which we get almost everything done. But wait, there is a better way that creates self-empowering teams and removes the management dependence. The alternative approach, simple and elegant, involves explaining the expected result and trusting the teams to accomplish the resulting tasks. In some cases, the difference is a subtle change in the wording and intentions, and in others, there may be political reasons why specific commands are given. In the later, this is a trigger in itself that the political issues (often elephants in the room) should be tackled head-on instead of being obfuscated.
It’s true that since childhood none of us have liked being told what to do, and each of us wants to feel that we had some say in the planning. Using the method above solves both of these common psychological dilemmas. The bottom line is that if you can’t trust people on a team to know the intended result, there could be a problem with having the right people on the team or managing the team.
5 August 2007, 5:31 pm
If you are like me and capture digital pictures in almost every circumstance, the frustration of organizing all of these has crossed your mind once or twice. Two common options are (1) installing software on your computer to help keep track or (2) uploading all your pictures to an Internet site like Flickr. With the first option, the software to organize your pictures is likely to require you to open its user interface (i.e. application) to manage your pictures, and you will be responsible for transferring this application to another computer when you upgrade. With the Internet upload option, which I partially use, the idea of having all your pictures labeled, grouped, and constantly backed up does have its advantages; however, I’m not a big fan of uploading every picture I’ve ever taken out on the Internet. (Call me old-fashioned.) In both cases, there’s likely to be a license or subscription to purchase.
To alleviate this image nightmare, I’ve created a simple and free system for organizing and tagging pictures that allows for easy searching and backing up. This involves creating a directory/folder structure in Explorer similar to the following.
Each year has a folder, and within each year, there are groups of pictures with keywords as the name of the sub folder. Note that the beginning of each sub folder is a number, which indicates the month the picture was taken. This provides chronological searching, since the folders are sorted in order.
To group the pictures in Explorer, you can see a small preview of the picture on your hard drive or the memory chip from your camera by setting Explorer to show the Thumbnails view. If the preview isn’t enough to determine which folder to place the picture, moving your mouse pointer over the picture in question will provide additional details. If you are like me, I often have a set of pictures with the same date and relative time, which makes it easy to figure what goes where.
The benefits of this system are that it’s super easy to do while moving the pictures from the camera’s memory chip to your computer. Just create the folder on your hard drive with some memorable words, and drag the pictures into the folder. In addition, it makes backing up the pictures easy as well, since you can backup via the date/year. This is especially important once you have more pictures than can fit on one DVD. What’s best about this model is the ability to take the system to different computers without additional software or Internet access.
10 November 2006, 12:17 pm
30 October 2006, 12:18 pm
-
“Overall, the goal for our software engineering teams (and most others) is to create “working software” faster and with more relevance to our customers; consequently, the posts on this blog will be focused with that objective in mind.”
10 October 2006, 10:55 pm
It seems like the term ‘inertia’ has become washed-out in The Noughts, just as the term ‘paradigm’ was overused late in The Nineties. I often hear inertia as the key culprit for nearly every business problem encountered in the past 25 years. Inertia in this case can be defined as the force that keeps people and processes behaving in the same ways, even in light of superior methods. While there’s no doubt that changing the behaviors of 6.5 billion people isn’t going to happen overnight, not all problems can legitimately be blamed on this mystery force of forward momentum. In fact, as a general rule, one should question and further scrutinize any situation where the basis for some problem has been associated with “inertia”.
For instance, I’ve had several conversations where the creation of various roles in a business has been deemed questionable and mostly likely a product of corporate inertia. While this may be true in some aspects, especially with the standard approach used in handing out titles, there can be no denying the power of specialization in this process. If enough individuals existed with all the abilities to engineer, market, sell and support a product, market forces would soon push this new wave of white collar workers to the top of the food chain. Unfortunately/fortunately, these superhuman workers do not exist in significant numbers; thus, the need for most existing job roles continues.
Another similar situation often blamed on inertia is the existence of management within large institutions. Is the existence of VPs and CxO positions at Google a product of inertia at the enterprise level, or is this approach just the reality of not having a better system of organizing large numbers of people to accomplish a similar goal? If there has ever been a chance to rethink common ways of doing things, I believe Larry and Sergey would have found and promoted a different way. If innovation is the nemesis of inertia (and I believe it is), Google would be the Jedi force facing the Sith-based corporate mandate.
In general, pinning the responsibility on the “inertia effect” will typically provide little help in solving a problem. In fact, blaming inertia will most likely provide a red herring excuse for giving up on attacking a problem due to the overwhelming nature of tackling such a mystic force. Looking for smaller solutions to problems and taking baby steps to tackle a larger problem will lead to much more productive solutions, and in many cases, these smaller solutions may lead to the generation of superior methods which alter the state of the bodies in motion.
2 October 2006, 10:13 pm
There are occasionally some odd situations that transpire during the Agile planning process, and one question that frequently arises is how to stay releasable when certain features cannot be broken down into releasable code prior to the ship date. Ideally, the basic Agile tenets are observed before starting to classify something as out of the ordinary: nightly builds of fully installable and executable software, small increments of working software delivered (2 weeks), continuous testing, and etc. Even if a team is following all of these, there can still be some situations where the team cannot complete a feature to a point where it can be delivered to a customer. This could be a situation where the small increments of the feature, while working independently, do not add up to enough value to complete a useful workflow, or the team may have incorporated some 3rd party tool or product, which instantly overwhelms the team with integration test cases. In these rare cases, teams are left with the question of how do we keep the software releasable but continue working on features which may not make it to the customer’s release. The following list provides some ideas to combat this problem:
- Hide the functionality. This option could include several things such as hiding a tab (via configuration or unreferenced URL) with the incomplete functionality, but allowing access to the product owner, developers, and QA, so that testing can occur in the main branch of the software. It could also involve licensing, where a license key prohibits the customer from accessing the uncompleted parts of the product.
- Wait on delivering the 3rd party product. Even though the team may have spent vast amounts of time implementing new APIs and testing the new product during the release, the incorporation of the new 3rd party product should be constructed such that it does not prevent the rest of the product from shipping.
- Limit the selling points. While it’s never a good idea to have visible parts of the product which are not fully usable by the customer, the important point is to make sure the rest of the product continues to function properly. If other useful parts of the code can be delivered to the customer, the customer may want to take advantage of the other fully working functionality, and this is what should be promoted.
- Document unfinished workflows. As with the option above, release notes and known issues can documented where the product is lacking. With both of these last two suggestions, the limited functionality should not create additional problems nor allow the user to sabotage himself.
22 September 2006, 12:26 am
The next time you hear someone warn ‘if it ain’t broke, don’t fix it’, perk your ears and pay attention because dire straights may soon follow. The rate of change is increasing and what’s working today will be broken tomorrow because someone else will be doing it better, faster, cheaper, and with less effort. As the title of this blog declares “Continual Improvement”, this is the mindset necessary to compete, and frankly survive, in all areas of life today. (I was going to mention rapid globalization and technological advancement, but the double cliché was more than I could stomach.) Here are some examples:
- Don’t see any issues with your smooth flowing work process? Wake up! One of your competitors is or soon will be using the same process with 1-2 tweaks to increase productivity two fold.
- Think you know everything there is about programming language X? There’s 10,000 people connected to the Internet working to develop faster than you with an 8086 and for the same cost as an 8086.
- Does the significant other seem quietly content with the weekly routine going on X years? Wait too long to throw some spice in the mix, and breakup city will be in your future moving plans.
The point is just thinking something isn’t broke means it probably is. These complacency thoughts should be the trigger in the mind that jolts us out of our slumber and starts probing for better ways.
18 September 2006, 9:36 pm
“Decrease your iteration length.” – The Agile answer to how to overcome the problem of breaking down these seemingly large requirements. At first, it sounds simple, but after giving it some thought, it sounds like a Greek philosopher’s answer to the meaning of life. (i.e. Neat answer, but what do I do with it?!)
The two dilemmas that teams face when breaking down requirements are (1) a reluctance by software engineers to develop in a (perceived) less-than-efficient mode and (2) how to use multiple people in a common area of the code, where the “9 mothers and a baby” theory starts to show (no pun intended). I won’t go into all of the ROI reasons to offset both these fears because they are well documented in any Agile process book; however, there are some different ways to brainstorm the large requirement question.
In general, decreasing the iteration length may be taken in its literal form. If using a 4 week iteration, switch to a 2 week iteration. If using a 2 week iteration, the team might experiment with fully accepted story cards within a 1 week iteration. Assuming the team is already using a 2 (or less) week iteration, another way to consider the breakdown is by considering what would be done if only 2-3 days were given to accomplish part of a larger task and demonstrate some progress, no matter how small. Unless the answer is “give up and quit”, there is some part of the requirement that can be done in a shorter period of time. As stated before, the team must trust the counterintuitive notion that this approach will not result in the most productive use of everyone’s time.
Since many problems are too large for one person to code within one iteration, it only makes sense to use multiple software engineers. One way to look at using multiple people is to consider a drastic approach of being forced to solve the problem of how to write a ‘say hello’ program with equal participation from 3 people. While a completely ridiculous way to solve this problem (not to mention a ridiculous problem), each person could rotate typing the code on a single keyboard. The point is to highlight that every problem could be broken down (components, classes, methods, etc.), and once again, the team has to make a leap of faith that the paybacks in familiarizing multiple people with more of the code and the benefits of demonstrating working software will make the team more efficient over the long term.
Last but not least, teams can approach the requirements breakdown phase as a mental competition. While many engineers like to exhibit their problem solving skills, the team can make the breakdown process a problem in itself. Peer recognition and other forms of compensation can be added to help change the old mindset of cranking out code to put food on the table. In this case, the baby gets new shoes when high quality code is delivered frequently and not when the super engineer works 24 hours straight to code something no one else understands, which will take 3 weeks to test in the quality.
13 September 2006, 10:20 pm
This article about excessive overtime in the IT industry reminded me of a question I was asked about how meet a release date when the project was behind. While there are many things to try, asking the team to work additional overtime was low on my list, and here’s why.
Anyone who has worked in the software industry for any amount of time knows that releases can and often do have highs and lows in terms of work hours. If the team has been cohesively formed, development and QA engineers will most likely work extra as the release date approaches anyway. While a last extra push over a couple of weeks or so might help cleanup a few last details, the effects of doing this for many weeks will often cause the project to be delayed even further. This is because tired and burned out engineers will make more mistakes, which will create more churn and code chaos. In addition, if any team members quit before the release is complete, the project could take a serious setback and potentially fail. So, what can be done? Fortunately/unfortunately, there are three fundamental things.
- Decrease scope. If the project is using an Agile approach, this won’t be an issue because the team will maintain a releasable state for the majority of the project. Some will often mention decreasing the quality, but this is essentially decreasing the scope since releasing a quality product was a requirement in the beginning.
- Adjust resources. Adding people is a favorite suggestion for second and third level managers to make, and it never hurts to reevaluate the team. Unfortunately, software isn’t the same as building a highway, and in some cases, the additional resources can consume time from the key contributors and stretch the release date out even further. There are some interesting variations on this suggestion ranging from adding subject matter experts to help the existing team all the way to adding resources in specific areas, such as testing. With an Agile approach, resources are typically fixed, but if there are multiple Agile teams, some teams may be able to take tasks from another team that has encountered roadblocks. In addition, if the Agile teams have been formed over time as cross-functional teams, it becomes much easier for alternate teams to be able to take on extra tasks with minimal training time.
- Push the release date. If no compromises can be made in either of the first two areas, moving the date will be required. When using an Agile approach, everyone agrees to the three laws of software development, often referred to as the iron triangle, and in this model, additional iterations will added until the desired scope is achieved.
8 September 2006, 10:35 pm
There are many jobs that a product manager may do, and while most focus the vast majority of their time gathering requirements and selling the products to the sales team, I contend that another equally important role is necessary. This role involves selling the engineering team on the value the new features or changes in the product will have for the customer (and ultimately the success of the group). In other words, for a product to be successful, the engineering team must be motivated to implement the product manager’s feedback. Many projects have failed or been plagued by engineering feature creep because the team did not have confidence in the information stream coming from the product manager(s).
One way to motivate engineering groups is with statistics and objective data showing the value to the customers. Ideally, revenue projections per feature would be great, but this is on par with predicting the weather. Another approach is showing raw historical data on the number and names of customers who have requested a feature; furthermore, having historical revenue data for what each customer paid would be a welcomed bonus. Information like this would provide teams with some objective justification as to why priorities have been set and take the obscurity and mystique out of a proposed new feature set. Unfortunately, this information rarely seems to make a backlog or requirements document. It could be as simple as keeping a spreadsheet with the top 25 features and noting the customers who requested each feature. In addition, it seems like a good sanity check for the product manager to validate intuitions and cross check with others in the company.
29 August 2006, 9:05 pm
I’m often amused when someone says something is “Agile” in the software business. While I’m no expert, if there is such a person, it’s always interesting to see how almost any process can be classified as Agile regardless of how much water you can hear falling in the background. For instance, I recently heard of a new so-called-Agile approach that involved filling out a Word document to propose certain defects be fixed in the product as it neared the end of the release. It was justified the new approach (1) created a new process on the fly to allow change in the product and (2) was promoting change by allowing team members to submit change proposals. On the surface, it seems harmless enough, but for those that can’t read between the lines, this process ultimately creates a nonessential accountability hurdle which will make change much more difficult by requiring a form document.
So, begs the question, when is an appropriate time to throw out the “A” word as justification for a change in process? I would argue it should only be used when the proposed change meets the four tenets of the Agile Manifesto. Unfortunately, this seems like a cliché and/or and easy copout, so how about a few of simple guidelines that might trigger one to double-check the Manifesto. (I would argue these guidelines might be a good test prior to implementing any process in any business, but that off-the-cuff suggestion might be a tad haughty.)
Does the new process:
1) Increase the amount of time needed to make a decision by creating throwaway artifacts?
2) Primarily exist to make someone or some group accountable in the face of failure?
3) Attempt to minimize the amount of live interaction needed between one or more groups?
If you answered “yes” to any of these questions, it might be a good time to reflect on the change and reconsider the assumption of Agility.
26 August 2006, 9:03 am
As follow-up to a previous post, I wanted to share a recent experience related to having someone from outside the group come in and suggest new ideas. In this case, the outsider was myself, and I was representing the Agilist in a group that was just getting off the ground with Agile software practices. The first few things I noticed were: (1) how willing everyone was listen to my suggestions (as an unbiased outsider), (2) how much experience I had gained within my own group and (3) who the internal champion was and how he was working to transition the group.
This arrangement is an alternative to the more expensive approach of bringing consultants from outside the company; however, the obvious catch is the company has to be large enough to have experts from outside the group. The key to making this work is to ensure the experts from within the company remain neutral to any factions that may exist. This is easier said than done, as it quickly becomes obvious where the obstacles are. In addition, the experts should use in moderation specific examples of how they have succeeded with their own group as this may unintentionally arouse feelings of bias. In other words, the internal experts should not continually use “our product x is wildly successful doing blah process”. Instead, they should focus the advice towards helping the new group and showing the benefits the change will make. In general, the experience has made me much more attentive to looking for others who may have useful knowledge from within our organization.
20 August 2006, 10:32 am
If progressive process change is getting bogged down in an organization, one of the remedies to consider is bringing in outsiders. Most likely, these people from outside the company are either contractors or some other sort of consultants in a particular area. Another approach could be bringing in a new manager or other expert into the company as a full time employee. It’s amazing to see how people within the organization will accept the advice of a new voice, even if the message is exactly the same as a previous champion of the change from within the company. (I could write a novel about the reasoning for this, but I’m sure every dear reader has their own story to relate.)
Companies that create an environment of continually promoting change have less of a need for these outsiders; however, it’s sometimes difficult to determine that healthy new ideas are not being promoted when observing from the inside. The key to getting outsiders into the organization is to justify the ROI because of the expense that’s often required; however, in some cases, consultants will perform some free sampler training or consulting in order to get more business if the ideas are accepted.
19 August 2006, 9:07 am
For waterfall projects, the classic defect curve is used to determine when a product is ready to ship. This is because most of the features have been “completed” during the first part of the development cycle, and the only work left to do is fixing the remaining defects. With Agile, there is a different approach where the work for the next iteration (2-4 weeks) is determined at the beginning of each iteration. This work should include taking the highest priority items from the backlog and working on those. In an idea environment, any defects are including the backlog and prioritized along with all of the features or enhancements to complete. However, when the defects are separated, the counts take on a life of their own.
These counts create perception issues and also cripple the Agile process because they are not prioritized with all the other work that is needed for the product. For instance, ten defects may cause one engineer to cringe, while a customer may not care about one thousand defects as long as the software performs its job. In addition, these defect lists have to continually be reviewed as a separate work set, which makes overall prioritization nearly impossible. In general, separating the software defects from the rest of the work is a relic of the waterfall days, while the Agile way is an all-encompassing backlog. When looking at a defect chart and waiting for the slope to point downwards, a good question to ask is “Why am I looking at a defect chart?”.
