Tuesday, February 13, 2007

The Gene Rodennberry Effect (aka Star Trek and Project Management)

What does Star Trek, Software Project Management and the TSP (Team Software Process) have to do with each other? You have to read this article by David Webb to find out. It's a unique approach to describing software development methodologies in a language that most techies (and Trekkies!) can understand.

In his article, David refers to the TSP software development process. The TSP model, developed by the Software Engineering Institute, works in conjunction with PSP (Personal Software Process) and is basically a light version of the CMMI. I have witnessed this methodology used in a couple of larger projects. It seems to work well, although this is a another blog subject.

The article summary provides some great advice on lessons learned. Many of them hold true for me personally, especially points 3, 7 and 10.

So the question is, as you work on your software project, are you a Kirk, Spock, Scotty, Uhura, Bones or Chekov? If you watch Star Trek The Next Generation, well you can use those characters as well.

Fixed Price vs. ODC

Outsourcing and offshoring of software development is gaining momentum every day. Most offshore vendors are embracing what's called the ODC model, which stands for Offshore Delivery Center. In this model, clients essentially rent resources on a monthly basis, largely manage the deliverables themselves, with accountability remaining primarily on the client. The vendor is only accountable for supplying "competent" and "productive" resources. The client must measure that competency and productivity, and if unsatisfied simply requests new/better resources.

Will this model continue to be the future of offshore outsourcing? Are clients satisfied with managing the risk themselves, even when key resources are often distributed around the globe - sometimes thousands of miles away? Do companies need to enhance their own skill sets to get adept at managing global outsourced resources? Or, is another model percolating?

There are a number of new companies springing up that are essentially adopting a more general contractor model. They work/source to a number of outsourcing firms, manage the client/project, and take on accountability themselves. Their expertise is that they know exactly how to manage global software development.

Is a shift underway? Doesn't specialization usually win over the day. Might the offshore outsourced software development model evolve into a 3-party relationship, where a company engages an onshore project management firm that specializes in global software development management. That firm then applies its expertise to compile a spec that meets the needs of offshore resources. It sends it out the design, development and testing aspect of the spec for bid to a number of outsourced providers, and then manages and is accountable for a fixed price deliverable.

I think this model is likely to gain momentum. It is all about specialization. Most offshore outsourcing firms don't want to be accountable, and most customers want them to be. This clash provides a real opportunity for the emergence of a new type of firm. Maybe onshore IT Services firms will see this as an opportunity to leverage their customer relationships, while taking advantage of the commoditization of software development services by tapping into a cadre of offshore engineering suppliers. Thoughts?

Friday, February 9, 2007

Distributed, Agile Development?

I came across a link to Agile Open Northwest. While this is the first time I heard about this conference, Kent Beck of Three Rivers Institute (and creator of JUnit) posted many of the session notes on a wiki. One that is particularly interesting to me was a session on Distributed Agile Development. In this session the speaker, David Churchville, talks about using different tools and travel as a way to facilitate conversations among "Agilists" (I don't like calling them resources either).

This contradicts a couple of points on the Agile Manifesto (at least by my interpretation). Specifically, how can a global or distributed project be developed in an Agile framework? Isn't daily communication and face to face conversations a major part of being Agile? If so, then that sounds like a lot of travel to promote an Agile project, and if you are trying to conserve costs, then offshoring with frequent travel doesn't make much sense.

I will be the first to admit that I did not attend the conference so cannot possibly know all that was said. I can only reference the materials posted on the conference wiki. Did anyone go to that conference, and can you provide some more information?

Wednesday, February 7, 2007

What is SDM and why does it matter?

Managing software projects is not the easiest job. There are just so many competing influences. Trying to line up what customers and users want, with what is reasonable for developers to build, and what can be done given the schedule, resources, and budget available, is basically the intractable force meeting the immovable object. So many times during software projects, I feel myself drifting into the Talking Heads song, Once in a Lifetime, as I ask myself, “well, how did I get here.”

Pardon the music reference. I’m predisposed to borrow quotes from music and movies to help me describe an event or emotion, so I hope this starts a trend and lots of you make similar contributions. And anyway, Once in a Lifetime is a very cool, albeit a bit twisted, and hence of of my favorite Talking Heads songs. But I digress.

Over the last few years, a new curveball began being tossed at the job of managing software development projects. Enter offshoring – stage right (or east actually). Now, on top of all the complexities involved in delivering software, we need to find, manage, and coordinate resources located around the globe. And, believe me, assimilating new cultures and personalities into the already quirky software development process ain’t no piece a cake.

So, what is SDM, and why does it matter? Well, SDM is the set of processes, resources, systems, and metrics that make up the job of delivering the software that, more and more powers virtually everything on our humble planet earth.

This blog is dedicated to identifying these items, discussing them, and helping us all better deal with the challenges of building software in today’s ever flattening world. As I stood in central Bangalore recently marveling at what truly looked like the new center of the software universe, Dorothy came to mind, cause “toto, I’ve a feeling we’re not in Kansas anymore.”