There has been a second argument pushed forward by IT leaders to the H1B Visa shortage: If you can not increase levels of visas so that we can bring in workers qualified to help move us forward, then we will find ways to distribute the work to the workers’ homelands. From a Homeland Security position, the Bush administration has the champagne (real imported stuff, no domestic trash for them) popping as yet another victory in their triumphant march towards homogeneity. However, what they are missing was the industries conclusion, and indeed their actions. Once we are successful at distributing work, we can do so continuously until no work really resides in the US.
There are many companies that pride themselves for accepting 1 in 100 applicants (or even higher ratios). Most companies no longer will pay for relocation and so they cast local nets. The 1 they hire may be the best of the 100 resumes they got, but consider the difference between that company and the one that casts a global net and picks the 1 best candidate and can actually integrate them productively without moving them. Which company will have a better team?
True in an agile environment (and any other), productivity is significantly better when the team is co-located. However, now is our time to examine as to whether I can, at a lower overall cost, have a better team working in a distributed way with a lower productivity but still be more cost effective than someone else’s team that is collocated in the US.
Saturday 29 March 2008
Thursday 27 March 2008
American Programmer
Yourdan wrote two books in the 90's that dealt with the state of the IT industry at the time. The first, The Decline and Fall of the American Programmer, was pretty pivotal in my interest in Process Improvement. His basic premise was that unless american programmers spent more of their time renewing their skills and staying at the forefront of the state of the art, they were going to find their jobs outsourced to software factories in other countries.
One tremendous effect this book had on me was a poignant statement that Yourdan made towards the end of the book: most american "programmers" only had execution manuals in their office (programming books) if they had any books at all and actually rarely read anything beyond language manuals. It was that comment that made me look around in my office (I had an office back then) as well as that of the rest of my team and realize he was right. I immediately began compiling a library and reading it voraciously.
His second book was the Rise and Resurrection of the American Programmer. Its message was
that we seemed to have organically heeded his call and rallied to the call. Our productivity was back up and though the drive to outsource was still there, it was mostly focused at the lower end of the spectrum - the help desks and the call centers. The book ended on a happier note.
Well, he could have rewritten them again in the naughts. As you all realize, we are a global economy and highly leveraging offshore skills, talents, and capabilities. There are reports all the time about how the education and skill levels outside the US meet or exceed those in the US. The reality is different though. There are good people everywhere in the world. There are also great people and not so good people (from both the skill and intent point of view). There are companies around the world that actively seek out the best and the brightest regardless of their location and then create means of distributed collaboration.
Regardless, there are also companies that merely seek adequate capabilities but at the lowest cost. I had a company tell me recently that they had found a way to get qualified teams of people all around the world bid by reverse auction for work they wanted to outsource. Their coup d'etat was that for a particular book of java work, they managed to find a team in Vietnam that would do the work for $2.5/hr*. This is an extreme case but many organizations now are outsourcing work because they can find rates so low that even with inherent communications and skill inefficiencies, the rates are still below what the costs would be onshore.
Yourdan's point was that if we don't make ourselves skill-wise relevant, we would be outsourced. Now, we are seeing skills taking a back seat to volume. If organizations continue to accept "good enough" (one of Yourdan's watch word phrases that, once we began to practice mid-90's, we were able to climb back in to relevance in the US) at continuously lower levels of "good", there will be no way we in the US can compete.
* When I asked whether if they would consider accepting the bid and paying $3/hr just to boost their standard of living, I was met with blank stares and an incredulous "why?". This is a different situation, one of abdicating global responsibility perhaps, but not the point I am making here.
One tremendous effect this book had on me was a poignant statement that Yourdan made towards the end of the book: most american "programmers" only had execution manuals in their office (programming books) if they had any books at all and actually rarely read anything beyond language manuals. It was that comment that made me look around in my office (I had an office back then) as well as that of the rest of my team and realize he was right. I immediately began compiling a library and reading it voraciously.
His second book was the Rise and Resurrection of the American Programmer. Its message was
that we seemed to have organically heeded his call and rallied to the call. Our productivity was back up and though the drive to outsource was still there, it was mostly focused at the lower end of the spectrum - the help desks and the call centers. The book ended on a happier note.
Well, he could have rewritten them again in the naughts. As you all realize, we are a global economy and highly leveraging offshore skills, talents, and capabilities. There are reports all the time about how the education and skill levels outside the US meet or exceed those in the US. The reality is different though. There are good people everywhere in the world. There are also great people and not so good people (from both the skill and intent point of view). There are companies around the world that actively seek out the best and the brightest regardless of their location and then create means of distributed collaboration.
Regardless, there are also companies that merely seek adequate capabilities but at the lowest cost. I had a company tell me recently that they had found a way to get qualified teams of people all around the world bid by reverse auction for work they wanted to outsource. Their coup d'etat was that for a particular book of java work, they managed to find a team in Vietnam that would do the work for $2.5/hr*. This is an extreme case but many organizations now are outsourcing work because they can find rates so low that even with inherent communications and skill inefficiencies, the rates are still below what the costs would be onshore.
Yourdan's point was that if we don't make ourselves skill-wise relevant, we would be outsourced. Now, we are seeing skills taking a back seat to volume. If organizations continue to accept "good enough" (one of Yourdan's watch word phrases that, once we began to practice mid-90's, we were able to climb back in to relevance in the US) at continuously lower levels of "good", there will be no way we in the US can compete.
* When I asked whether if they would consider accepting the bid and paying $3/hr just to boost their standard of living, I was met with blank stares and an incredulous "why?". This is a different situation, one of abdicating global responsibility perhaps, but not the point I am making here.
Tuesday 18 March 2008
How do we establish a new truth?
Truths are strange ducks. You hope they will be self evident, but more frequently, they are not. The biggest issue tends to be in that a truth to one person is not necessarily so held by another. Much of it centers around faith, and much of the proliferation of the truths center around trust in the one asking you to hold some concept as the truth.
So, perhaps the critical step in the process of establishing a new truth is being able to trust those that are recommending the ideas behind the to-be truths. Trust is also an interesting concept. In relationship to truths and trust, the venerable Einstein has been quoted saying “whoever is careless with the truth in small matters can not be trusted with important matters”. Stephen Covey Jr., in his book The Speed of Trust states that the principal path to Trust is through integrity and in turn integrity is seen as not only telling the truth, but leaving the right impression about that truth. In other words, you can be truthful and honest, but twist it for your own purposes. Think about the sales process in most consulting or product organizations. Often, the sales people believe they are truthful, but skate in the fuzzy boundary between fabric and fabrication.
If we are going to instantiate a new truth we, the purveyors, must retain our integrity and meet the expectations that we set for ourselves. It is inappropriate to set the bar so high that there is only a small probability of achieving is; but equally, we can not set it so low that any methodology would perform as well. Let’s us strive to be aggressive but possible, meet the expectations we set, and make them clearly above what other methodologies can accomplish. This is the way we will establish a new truth.
So, perhaps the critical step in the process of establishing a new truth is being able to trust those that are recommending the ideas behind the to-be truths. Trust is also an interesting concept. In relationship to truths and trust, the venerable Einstein has been quoted saying “whoever is careless with the truth in small matters can not be trusted with important matters”. Stephen Covey Jr., in his book The Speed of Trust states that the principal path to Trust is through integrity and in turn integrity is seen as not only telling the truth, but leaving the right impression about that truth. In other words, you can be truthful and honest, but twist it for your own purposes. Think about the sales process in most consulting or product organizations. Often, the sales people believe they are truthful, but skate in the fuzzy boundary between fabric and fabrication.
If we are going to instantiate a new truth we, the purveyors, must retain our integrity and meet the expectations that we set for ourselves. It is inappropriate to set the bar so high that there is only a small probability of achieving is; but equally, we can not set it so low that any methodology would perform as well. Let’s us strive to be aggressive but possible, meet the expectations we set, and make them clearly above what other methodologies can accomplish. This is the way we will establish a new truth.
Thursday 13 March 2008
self evident truths of agile project management
Often I get asked how you ensure that your project is done one time when you use an Agile approach. Upon deeper probing, what I find they are really asking is how do you protect against a run-away project. There has developed a common misconception in the industry that, just like agile engineering techniques, agile project management is a cowboy approach. The view is that with continuous iterations and “releaseable” code, when do you stop and, indeed, how do you stop all that requirements-creep?
To me, what this is, is a cry for help. Clearly, the project manager is not managing the project (or perhaps even the people). Regardless of what methodology is being used, the project manager is that person who has been given the role with delivery responsibility for the project. In many of the canonical depictions of agile methods tend to tread lightly on the role responsible for project delivery: often it is implied that the team itself takes on this responsibility. Well, that in itself is fine. This makes the team the defacto PM and collectively responsible for delivery.
In Agile methods, we commonly assure customers that we are geared up to meet their expectations, but there is a non-diminishing perception that once we are given control, we don’t give back product on their schedule. Further, there is a palpable and growing fear that the development teams will estimate poorly and the product release will string out continuously to “Next Iteration” – the agile developer’s version of manana. However, if the project team is collectively the responsible for delivery – as a PM collaborative, they should be holding each other to as delivery standard such that the Release is as time boxed as the iterations and that, if the customer directs, the release happens on schedule, but with less content if necessary.
If we can establish a new commonly held truth that agile teams deliver within time boxes and that the time boxes are indeed that: time boxes, then much of the fear of transformation will, in my estimation ebb away.
To me, what this is, is a cry for help. Clearly, the project manager is not managing the project (or perhaps even the people). Regardless of what methodology is being used, the project manager is that person who has been given the role with delivery responsibility for the project. In many of the canonical depictions of agile methods tend to tread lightly on the role responsible for project delivery: often it is implied that the team itself takes on this responsibility. Well, that in itself is fine. This makes the team the defacto PM and collectively responsible for delivery.
In Agile methods, we commonly assure customers that we are geared up to meet their expectations, but there is a non-diminishing perception that once we are given control, we don’t give back product on their schedule. Further, there is a palpable and growing fear that the development teams will estimate poorly and the product release will string out continuously to “Next Iteration” – the agile developer’s version of manana. However, if the project team is collectively the responsible for delivery – as a PM collaborative, they should be holding each other to as delivery standard such that the Release is as time boxed as the iterations and that, if the customer directs, the release happens on schedule, but with less content if necessary.
If we can establish a new commonly held truth that agile teams deliver within time boxes and that the time boxes are indeed that: time boxes, then much of the fear of transformation will, in my estimation ebb away.
Saturday 1 March 2008
Question #10
How do you get companies to follow scrum? In a CMMI implementation, there is a SEPG that is responsible for both institutionalizing and verifying the processes. This becomes a two prong effort – one to review and revise the process and the other to educate the people. Organizationally, management enforces that they must use this process across all projects, though individual teams can ask for waivers on parts of the process. The SEPG also is responsible for negotiating and granting these waivers.
Usually, any agile method is a collaborative effort. My favorite approach towards enabling an organization is to take a team of curious and energized individuals with a cross functional distribution and level their education with respect to the state of the art in agile methods. Collaboratively, we would pick a point to start from, a point of departure for the enablement - so to speak. Then with Sr. Mgmt’s input, we would pick a pilot project (or two) and begin a process implementation with the team. The pilot should be important and visible enough in the organization so that other individuals and teams would actually take notice of both success and failure.
Across the implementation, we would over socialize and over communicate so that the curious across the organization would watch and become interested. By keeping attention high, the approach would be to infect them with the desire to try something different and then as our successes become visible, encourage them to try it on their own. The expectation would be that the methodology would catch on and spread virally. It is also expected that support networks would be encouraged and grown so that when new teams needed help (whether they knew it or not) there would be both a place they could go for answers and a place from which guidance could come when it was not requested (the collaborative element). This is the truest way for an organization to follow scrum.
Once a critical mass of projects is attained, there needs to be various mechanisms put in place to support and maintain the process and separately to oversee and guide projects to their completion. This is best served by a PMO. Not a classical one, but an agile one. In a classical sense, the PMO is responsible for policing the execution of projects. In an agile sense, there is a more collaborative environment and indeed the function of the PMO is to help the PMs better execute their projects and meet their commitments. It is, shall we say, a retrospective opportunity for the company with respect to how it monetizes its undertakings.
Usually, any agile method is a collaborative effort. My favorite approach towards enabling an organization is to take a team of curious and energized individuals with a cross functional distribution and level their education with respect to the state of the art in agile methods. Collaboratively, we would pick a point to start from, a point of departure for the enablement - so to speak. Then with Sr. Mgmt’s input, we would pick a pilot project (or two) and begin a process implementation with the team. The pilot should be important and visible enough in the organization so that other individuals and teams would actually take notice of both success and failure.
Across the implementation, we would over socialize and over communicate so that the curious across the organization would watch and become interested. By keeping attention high, the approach would be to infect them with the desire to try something different and then as our successes become visible, encourage them to try it on their own. The expectation would be that the methodology would catch on and spread virally. It is also expected that support networks would be encouraged and grown so that when new teams needed help (whether they knew it or not) there would be both a place they could go for answers and a place from which guidance could come when it was not requested (the collaborative element). This is the truest way for an organization to follow scrum.
Once a critical mass of projects is attained, there needs to be various mechanisms put in place to support and maintain the process and separately to oversee and guide projects to their completion. This is best served by a PMO. Not a classical one, but an agile one. In a classical sense, the PMO is responsible for policing the execution of projects. In an agile sense, there is a more collaborative environment and indeed the function of the PMO is to help the PMs better execute their projects and meet their commitments. It is, shall we say, a retrospective opportunity for the company with respect to how it monetizes its undertakings.
Subscribe to:
Posts (Atom)