Development Team Management

The Phoenix Project book take aways

I just finished listening to the audio book of the Phoenix project. I had a few primary take aways from this book:
1. Reduce WIP (work in progress). I’ve been on projects in my career where when we’d get blocked on doing some work, we needed to keep the team busy so we’d pull in other work. Soon enough you’d have 100 initiatives going on at once that you’re able to devote to each only ten minutes per week. In this project we paused for two weeks where no new work was added and we just focused on completing the work already in progress. It reduces context switching and allows more work to get completed.

2. Automated builds and deployments. I’ve also been on teams where this has been done and it’s fantastic. Building and maintaining the tool itself takes effort, so plan for that. But, once it’s finished you can deploy all day with consistency and accuracy.

3. Identify your workflow’s constraint (bottleneck). Any improvements to the workflow that are not at the constraint are worthless.

4. Unplanned work prevents you from meeting your goals. Minimize this.

Here are a couple great resources for notes and take aways and

Jira: Give user access to one project

Let’s face it, you found this blog post because like me you found Jira permissions to be ten times more confusing than necessary. After a really really long time, I figured out how to give a user access to just one project instead of every project on my account.

1. Copy the default permission scheme to another like “Project-Client-Permissions”
2. Create a group, “Project-Client”
3. Add that group only to the permissions you want them to have. For me, it is Browse Project, Create Issues, Edit Issues, Resolve Issues, Add Comments, Edit Own Comments, Delete Own Comments, Create Attachments, and Delete Own Attachments
4. Apply that Permission scheme to the project
5. Add a user and add them only to the Project-Client group (they should also be in jira-users by default so they can login)
6. One additional step I did – edit the permissions of the default permission scheme and remove “Application Access” – “Any logged in user” from the “browse projects” permission in order to hide other projects from my one project user.

Finalizing Project Specifications

As the team lead for the past year, I’ve been playing the role of politician, requirements gatherer, specifications writer, and project manager for VISI’s development team. Requirements and specifications are something completely new to VISI’s development projects since I started taking ownership of them. Upper management has been asking for more quality and this is one of the steps we’ve taken to reach that goal.

I won’t go into detail about how to gather requirements or build a specifications document at this time, but I’d like to inform you how I’m “finalizing” our internal project specifications so we can starting building out the project. Two of the projects I’ve been preparing specifications for have come to a close just yesterday and today. One of them is a small project that is projected to take 8 days to build out and the other is a large project expected to take many months. After many revisions of the specifications document for each project and repeatedly asking for, and not receiving, an approval from the “customer”, who is an internal employee, the revisions just continued creeping in slowly for a couple weeks time.  This is not productive time and is only delaying the project, especially when you have a developer on your team looking for something productive and meaningful to work on.  The project “customer” may have trouble committing to a specification, knowing that changes during the build and after launch are harder to come by. They may also be indecisive for fear of making a commitment and overlooking an important requirement or feature.

Because this is an internal project for the company, I am able to “help” facilitate and keep things moving.  It’s very simple: the company needed this project completed yesterday, so we need to draw the line and get started.  For you sales people out there, “asking for the sale”, or “close”, did not work with these projects.  Therefore, I’ve realized it’s up to me to draw the line and tell them when the specifications are finished.  How do you know when this time has arrived with a project spec? When the change requests and revisions have slowed and decreased in severity to the point where you’d be able to makes the modifications very easily on the fly during the project build.  I’m not saying it’s good to make a bunch of changes to the spec during the build, but they will come inevitably and will never cease, even after the project is completed.   The other important factor is that your team is ready to get started.  If you’re developer for the project is tied up for another month with something else, then there is little need to bring closure to the specification discussion at this time since you know little changes and modifications will forever continue with larger projects.

When it comes to the internal project that is starting to drag on forever, just remind yourself and the internal “customer” that the company needs the project completed and a line must be drawn.

Tips for interviewing software developers

I’ve been interviewing developers on and off for most of the last year and have lead more than twenty five or thirty interviews in total.  A couple years ago myself and other inexperienced coworkers started interviewing developer candidates and made some critical mistakes in the our approach as we didn’t know any better.  Our interview at the time was generic and strictly verbal; it pretty much went like it would for a non technical position.  The two coworkers that came out of those first few interviews are fortunately long gone as they didn’t work out.  One of these guys had five years experience writing PHP and referred to himself a senior developer.  After hiring him (when I didn’t know how to interview somebody), we learned through looking at his code that he didn’t know how to return a value from a function!  This was just one example of the never ending blunders that could have been identified during the interview process.  He had a difficult time learning new things.  You’ll need to evaluate the candidate’s skill level in areas and make sure they’re on par with where they should be for the duration of experience.

I have read other blogs and read books that cover interviewing developers.  From this I have put together an interview that usually takes 1.5 to 2 hours depending on the person.  After this time, I have a very good grasp of what the candidate is capable of.  Training a developer can easily cost the company tens of thousands of dollars in salaries of both the new hire and the trainer, not to mention a loss of productivity.  Hiring the wrong person, one who will never perform up to par, will cost the company even more.

Below are some tips for successfully interviewing a developer and feeling confident about them when making an offer.  Don’t feel bad about holding a tough interview; hire the wrong person and it’ll be you sitting through a tough performance review later on.

  1. Watch them write code.  It’s pretty simple, almost too simple, but you’ll be surprised how it separates those who can talk the talk and walk the walk in a hurry.  For the interview I hold, I have a simple open ended task where the developer will create a data structure of their choosing and write a loop to display the data in any programming language of their choosing.  Naturally, since I work at a PHP shop, that is the preferred language.  I recently had a 4 year college graduate with a computer focused degree, who was unable to even start on this code writing task.  Not one line of code.  He was a nice guy and a geek, but not a programmer by any means.
  2. Give them a written skill assessment covering the areas of focus they’ll be working with at your company.  Cover a few areas of focus and ask and easier and more difficult question for each.  Again, it’s amazing what you’ll find.  Some people will ace it and their knowledge and experience will show.  Others will bomb it.  This is another indicator of how much training the candidate will require.  If the candidate has years of experience on the subject matter and bombs it, don’t hire them!  See paragraph one in this article for an example.
  3. Try to identify a real “passion” for their work.  There are a couple  basic types of successful developers or computer geeks out there.
    1. There are geeks that like computers and are also good with business management.  MIS/CIS majors will usually be like this.  Ask about any side businesses or revenue producing projects they have to identify this trait.  They’re more likely to use CPanel or Plesk to setup their websites in a hurry because it’s easy, it works, and it’s fast.  They’re generally less concerned about all the configurations and settings as they’re more concerned about getting their product to market quickly.  These will be your development managers one day.  The tough part is, this person must start out at the bottom by writing code and much of their college training was on the business side of things and not so much programming languages.
    2. The second type are the real geeks.  Computer Science majors that do command line everything and do it because they just want to know how it works.  They get excited about bits and bytes and working on tiny performance tweaks for six hours that save 0.01 second of processing time.  Their eyes light up when talking about their side projects and will go into great detail of what it is they’re working on.  If you’re looking for a brilliant coder, a good worker, fast learner that teaches themselves, this is the type you want.  The challenge will be to keep this person on task and focused on the company’s goal.  They have a tendency to spend way too much time on the little things and may kill the project deadline.

As the manager and person making the hire, If you’re not 100% sure about a candidate, don’t make them an offer.  If you’re 90% sure about somebody, only make them an offer if your circumstances require you to hire somebody immediately.  Just when you think you’ve looked at everybody’s resume, another great candidate always comes along with a little time.