In Search Of

Perhaps you have experienced the struggles of on-boarding new developers into an already large team in the middle of a project. Everybody who comes wants to have a say in how things are done, no matter how late in the process they get involved. Here is a litany of the types of commentary that I hear in this situation:

• On my last project we used <insert product, pattern, or practice> and it worked great. We should certainly use that here.
• We don't need <insert pattern, product, or practice> its too <insert adjective>.
• Why don't you just <insert suggestion>.
• The code-base is in a bad state because <cite example>.

Each of these commentaries were delivered, without necessarily an understanding of the choices that were made by the team to get to this point, nor with a full understanding of the work remaining. I sincerely believe that each developer made the comments in a spirit of trying to help the team. I also believe that each of these comments reflects the developer trying to construct a "familiar" environment where he knows how to deliver value.

Here are the problems with this:

 

• Commentary rarely reflects a problem statement before offering a solution.
• Commentary rarely exposes the cost (in effort and risk) of adopting the solution.
• Commentator may or may not have the experience or skill to lead the team through the adoption of the solution.
• Commentator may or may not have thought through the solution to the ultimate conclusion - to determine whether it is feasible, valuable, or reasonable within the context of the project.

I attribute these commentaries to each developer's on-boarding process, and their process of "mourning" the familiarity of their last engagement, while also trying to understand the current environment.

Read the rest of this post »

I have worked with a lot of teams made up primarily of contract developers. Not teams from consulting firms, but teams of "assorted" contractors from assorted staff augmentation firms.

Folks that have been doing "short term" staff aug work for a while - (by my definition not longer than a year) - have an hourly mindset. That is, they get paid by the hour. They know that they are the last to show and the first to go - meaning they are only hired when needed, and are rolled off as soon as the work is done. They sometimes have slack periods between gigs, and are almost always willing to bill overtime while they are engaged.

Read the rest of this post »

Hiring has some words that we use to describe what we are looking for:

1) Been There, Done That - you want someone who can do this job with their eyes closed.
2) New Blood - you want someone who will never say, "that is not the way we do it here".
3) Fresh Meat - you want someone who isn't already burned out.
4) Youthful Optimism - you want someone who will not stop trying when things get ugly.
5) Hands - you want someone who cranks out work.
6) Brains - you want someone who can show us how to do it better.
7) Potential - you want someone who can become a star.

Hiring is difficult, because you don't always know what you are getting. But it helps to know what you want. I like these words, because they informally signal what that I am seeking.

Read the rest of this post »

Sometimes building software is ugly. There, I said it. Sometimes, especially at the beginning of a project that will result in a new system, especially when you are working with a new (to you) software paradigm, especially when you are working with a new team, building software is ugly.

I recently was part of a project which took an existing piece of software on one platform, with the intention of re-implementing it on a new platform. Perhaps the biggest challenge came from the fact that the technical architect or lead who had been instrumental in developing the original product, and who was familiar with both paradigms, defected from the project when we were preparing to start the re-implementation.

He had been the driver of the decision on the new paradigm, and it was on the basis of his capacity that we built estimates and plans. Without him, we had to hire resources to work in the new paradigm, and find a leadership paradigm that could move forward.

While the new team was forming, and the new leader was coming up to speed, we started an iteration 0 to build out new infrastructure, and then an iteration 1 building a walking skeleton. I had hoped that this would help the team form, and practices would be established. Without the right leadership in place, things were ugly. Decisions were not made in the right sequence. One of the managers involved in the project said:

Read the rest of this post »

When you adopt agile practices, especially agile life cycle plans - it is really simple to have your project manager become the scrum-master, right? Isn't that what everybody does? After all, it's just swapping a gantt chart for a burn down chart, right?

It certainly is what all of the project managers do when their companies start to adopt agile life cycles - but is it the best thing, or even a good thing?

Read the rest of this post »

Over the last few weeks I have overheard a couple of things that really tickled me, because of their brutal portrayal of some business truism, and because of the skill of the speaker in articulating:

Read the rest of this post »

In writing a recent post for my other blog

about planning and delegation, I fell into a set of 4 principles that define how to delegate successfully. The principles are Responsibility, Accountability, Trust, Success or RATS.

Here is the excerpt from that post:

 

 

Read the rest of this post »

I am not a fan of software methodologies, third party libraries, hyper-generalized frameworks or other so called productivity enhancers within the software development process. At the same time, I abhor the idea of a thousand developers at a thousand keyboards creating a thousand screens, features, pages and trying somehow to stitch them together into a cohesive software product.

What do I like? Small teams of smart developers who understand how to build small re-usable frameworks to solve problems that they have already solved, and are likely to need solving over and over. Guys and Gals who are likely to re-factor their initial solution into a mini-framework. Sometimes these frameworks "adhere" to each other, and grow into something more comprehensive. Other times they are simple labor saving through code re-use.

Read the rest of this post »

One of the most useless project management conventions I have ever worked with is the status stoplight or RAG status. From a simplicity perspective, it is designed to convey a general state of the project. Green means things are "OK". Amber means things aren't that OK. Red means things are not OK at all. The convention is to get the attention of stakeholders when the status changes from green to amber to red. It is a beacon, or warning signal that something needs to change.

Read the rest of this post »

Of course, the only valid reason for estimation is prediction. We want to predict the cost and duration of delivery for some set of working software capabilities. If we didn't care about time and cost, we wouldn't waste our time trying to predict. We realize that software task estimates alone are insufficient for this prediction. But at the heart, the task estimates being predictable; correctly representing the work that the team needs to do within some finite predictable variance is essential. Task estimates are the core of the plan.

Read the rest of this post »