A quick glance at the dictionary gives us a definition of the word agile – “marked by ready ability to move with quick easy grace.” The IT community has co-opted this word and extrapolated a meaning that is really beyond description. Of course, what else were we supposed to do?
Much comparison has been drawn between building software and physical construction (e.g. building a house). But this comparison really isn’t fair. While it’s true that it’s extremely costly to make changes to a building after it is erected, the same multipliers used in that industry cannot be applied to software. Seriously – have you ever had to bring a demolition crew in to remove a section of code? The delete key is our wrecking ball.
At some point, I’m sure a manager looked at this software construction like building construction parallel and said, “I need you guys to work in a more agile manner.” And there it began. Sure, there were puzzled looks in the conference room, but then they all went back to their war room or desks and started figuring out what the manager meant by agile. Today, we have a half dozen agile methodologies that address this perceived need to move fast. Each of them has their own caveats of “this may not be the best approach for you.” Unfortunately those sections seem to be often skipped.
The Software Development Life Cycle you choose for your project should not be dictated by whichever magazine article is sitting on your desk at the moment. It is a choice that needs to be carefully made based on your entire situation. What is the makeup of your team? Do they work best on well-defined tasks or are they better when left to find creative approaches? What is your relationship and level of involvement and commitment with your customer? What type of project is it – are you solving a well defined problem or is further research required?
My parting thought for today is a continuation of the last paragraph’s them – ask questions. If you are the team lead or project manager, your value comes from applying the experience you’ve gathered from past projects. When your customer or manager makes a broad statement, dive into it and understand what he is asking for. You will then have a much clearer shot at success, no matter what methodology you choose to deliver it.
Image via Wikipedia
If you have spent any time on a formally managed project, you have no doubt seen the status reports with the green / yellow / red codings. These symbols are taken from the traffic signal concept, a concept that is universally accepted. Green means go, red means stop, and yellow means SPEED UP!!! Just kidding – yellow means caution / clear the intersection. With such clear meanings while driving, and the generally anal nature of project managers, you would think that clear meanings would be established for green, yellow and red signals on project status reports.
You would be wrong.
My favorite current example is a project whose one-slider (one slide divided into four quadrants for accomplishments, issues, milestones and budget) is covered up in red on the milestone sections. It is clear that the milestones that have been set have been blown through, and the work necessary to complete that milestone is late. However, the project overall was still showing green on time. This is a project that has not met A SINGLE DELIVERABLE DEADLINE. How can you be green on overall time, but red on practically everything else (the milestones that were still in flight were showing yellow). This led to a somewhat heated debate – and I got my point across. The project is now at least showing its tracking yellow.
My point here is not to throw anyone under the bus, but rather to share a lesson learned. You need as a team to agree up front on how status will be reported and what the criteria for having a green, yellow or red color code is (or whatever system you are going to use to give high level status). That way, the status is not being re-negotiated when it really should be black & white (or in this case red).
I have a tremendous pet peeve that I am going to share with you – it’s the misunderstanding of risk by managers around the world. We are currently working on a number of projects at work, and are paying close attention to the risks associated with them. I could practically make a drinking game of the phrase “what is your mitigation strategy?” – except that players would be completely drunk within 15 minutes of the start of the meeting.
What is my issue? Mitigation is only 1 of 4 strategies that you can employ when dealing with risk. So rather than creating a column in your worksheet labeled “Mitigation” you really need 2, one for “Strategy” and one for “Action Plan”. The action plan is the implementation of the strategy. So what goes in the Strategy column? You have 4 choices:
Take for example your house – one of the risks of home ownership is that a fire could start and wipe away your house and all of your belongings. We could employ any of the above techniques to our home ownership example (and in fact, usually apply multiple).
- Avoidance – you could decide not to buy a house at all. No risk of fire then!
- Transference – this is what most people do – they buy insurance! They have transferred the financial risk of a fire to an insurance company. Note that not all of the risk has been transferred, there is usually a deductible involved in the case of a claim event. This provides an incentive to the insured to work to minimize the risk of said event.
- Mitigation – You could build your house out of non-flammable materials (an igloo, maybe) or flame retardant materials. You could also install fire sprinkler systems. These are examples of mitigation techniques designed to lessen the impact of a fire.
- Acceptance – You could just accept the risk and live your life. This probably isn’t the best approach when it comes to owning a home, but note that even with an insurance policy, you are accepting a certain amount of risk based on the deductible.
I may be overstepping my bounds here, but the other aspect to risk management to understand is that not all risks are bad. In fact, if some turn into issues, they may actually present opportunities to the person or company experiencing them. The recent financial crisis in America is a good example of a risk (extension of credit to borrowers tightening) that presents an opportunity for many. Companies may have implemented a strategy of having significant cash reserves in order to mitigate the risks of not being able to get loans. They now find themselves in the unique position of having a stockpile of cash to use to purchase land (maybe they want to expand their production facilities) or provide loans to other cash strapped companies who are issuing bonds.
Ok – I’ll get off my soap box for now. If I’ve piqued your interest and you want to become a more informed manager of risk, check out the book Enterprise Risk Management: From Incentives to Controls. These techniques apply to projects, programs, companies and even your own personal life.
I have spent a lot of time over the past year (really over the last 20 years) looking at the keys to success and failure that have been experienced by certain technologies and platforms. Many product organizations take a kitchen sink approach to delivering features in their product. This can lead to a “jack of all trades, master of none” perception in the marketplace. It can also confuse users as to exactly a product should do. On the flip side, you have groups that release products that seem to be incomplete.
Right now I am a fan of Apple and its approach over the past decade to personal electronics. They seem to have taken the approach of delivering a chunk of value, letting people adjust to it, and then have the customers say “it would be really nice if this thing did x.” iPhone OS 3 gave us the ability to cut / copy / paste. This function point has been ubiquitous in computing for the past 2 decades, and yet Apple decided not to include it in the original release. The same is true with multitasking – even the Palm platform in the mid 90’s allowed a form of multi-tasking (such as it was) and yet Apple it’s waiting to the 4th generation of it’s OS to make it available.
When you first look at this, you may think “Gee, they just wanted to lock in a monetary stream of upgrades.” But if you think further, they have really been delivering fully baked features at the time they really become needed. When the iPhone app store first opened, there weren’t enough apps with functionality that would make you want to multitask. Who knew how quickly apps would catch on that people would want to copy / paste? Apple has done a great job of delivering features at a pace that allows the ecosystem to adjust, and the customers to understand how to use it.
Hopefully, on the next generation of our intranet platform, we can duplicate this success. For now, I’m calling it reductive feature design and I think that it can be viewed through the lens of technical and organizational readiness. If either of those two factors truly aren’t ready to introduce the feature, it should be removed from the version stream and placed into the backlog. Now to pitch it to the rest of the folks and see if it flies…
Over the last decade, many lessons have been learned about sending software development work overseas. These lessons have been documented in books, magazines and blogs the world over. Many lessons are similar to those that you would face if you chose a consultancy down the street from you. Others are simply lessons of doing business with cultures foreign to your own.
For those who have been working with offshore partners for a number of years, what I write here on the subject will be a “no duh” moment. Others looking to embark on a pilot of sending work overseas may think “this won’t happen to me.” Regardless – what I write over the coming weeks and years will be my observations and a sort of record of my experiences.
My thought for today is this -> It can be more challenging than it might appear. On the surface, the idea sounds great. You do the customer interactions, the requirements definition and design work – then turn it over to your partners to implement. But what if there are issues? When the work is done within 3 timezones of yourself, getting people together to discuss the issue is very straightforward. Even emailing back and forth is possible when the timezones are close.
But the problem with sending work 12 timezones away is the lag in time. If there is an issue that impacts delivery dates, resolving it via email is a guaranteed way to miss your deadline. One model that has worked well is to use an “onshore coordinator” – a technical individual that works for your offshore partner whose job is to interface with you and the offshore team and work across time boundaries to get issues resolved.
One final thought on this matter is this -> no matter which of the above options you take, whether you have an onshore coordinator or you are up at midnight on the phone – YOU are the bottleneck. It may be that the team overseas is incompetent, but it’s your job to make them competent (or take some other action). If systems are unreachable, requirements are unclear, or deliverables are of poor quality it is your responsibility to remove the obstacles and rectify the situation. If you execute well, your chances for a successful program are higher.