Posts Tagged ‘process’

Kickoff to Delivery: The Most Difficult Phases

May 8th, 2009

Something I've noticed over the years of being an engineer is that project staffing tends to look something like, "Let's get our best and brightest involved early to get the project moving--once it's moving, the rest of the team can finish the job."  Part of this statement shows great sense for project delivery--and the other completely opposes it.  The two most difficult phases of any project are the initial kickoff and the final delivery--and you need a different set of people for each.

Looking at the philosophy above, it is generally understood that getting the ball rolling on a project is a difficult task.  Especially in the IT world where a project may call for some new technology that the majority of your staffers aren't yet up to speed on, it's great to bring people in who tend to be somewhat ahead of the curve.  They serve both to lay the initial groundwork in actual code--but more importantly they support the development of the staffers that will continue the work after they leave for the next project.

The best people for this phase are your leaders, your entrepreneurs.   They're some of your top technical people who also bring strong technical leadership to your team.  They inspire others to follow them into the project and motivate the people around them.  Most of all, they are able to charge into complex technical problems and tackle some big challenges early on and clear those roadblocks for the team while providing solid examples of how the team should proceed.

As these people move off the project, it is assumed that the team "left behind" will bring the project to its completion. However, completing a project presents the same level of challenge as starting it.  The challenges are different, but they are equally complex: fixing defects, tying up loose ends, and the inevitable realization that something that worked every time you tested it up until now has a couple of edge cases that, while not common, are possible enough that they must be accounted for in a new design. As a project approaches that end date, another personality type is required to join the team.  I call them "closers."

Closers are methodical, detail-oriented executors.  Winding a project to completion involves fixing often very delicate defects without destabilizing the entire system (or even large portions of it).  Rather than being solid team leaders, they are usually the absolute top technical talent you have.  They're people who have seen nearly everything that can happen as launch approaches and can maintain their calm while dealing with the challenges.  Most importantly, these closers act as a buffer between management (which is usually in full-panic mode as the launch approaches) and the rest of the team working to knock out those last few defects before launch.

We already put a lot of effort into people and process to get a project started; it's time to pay more attention to Closing the Deal.

Emergence Drowns in a Waterfall

May 6th, 2009

In July of this year I'll be taking a class to become a certified ScrumMaster.  It will be the first industry certification that I've earned in my career--I've frankly never found them to be valuable so I've avoided them.  But as much as I'm passionate about building quality products, I'm even more passionate about the processes that enable building quality products.  And besides, what's cooler than a title that identifies me as Master.

The classical model of software development follows the Waterfall Model--that is, each process completes a set of deliverables and they "fall down" to the next tier.  At least, that's the theory.  In practice it usually works more like a set of walls that each group throws their deliverables over as they're completed--and the team who receives that deliverable is asked to follow that deliverable explicitly.  The further "downstream" you are in the waterfall, the more frustrating this process becomes as you get further and further away from the true objective of the project.

Often we find that when we fill the requirements, we don't really meet the objectives and happen upon a better way to meet the objective: this is called Emergence.  While attempting to reduce uncertainty downstream (often quite unsuccessfully), the Waterfall also restricts our ability to act on the Emergent Properties we discover in a system as it is built.  In my opinion, this restriction is the single largest cause of poor software design as it causes us to accept our requirements time leaps of faith over development time observations.

Emergent properties are very powerful tools to guide the way to great products and they should be embraced.  Scrum and other Agile methodologies support these properties while the Waterfall, with all pun intended, drowns them.