Diary Post 2 – First 2 weeks of work

Okay….so posting once a week seems too much for me!

So, I have been at my new job for 2.5 weeks now and things have already started to change and shift around for the better.  However, I am running across some much expected resistance from some folks as well.

I am also faced with the added challenge of needing to stay billable while working on implementing change and establishing testing practices.  This means I don’t have the luxury of taking a step back to get a full picture across all of our projects.  Instead, I am staffed on 3 projects that I can directly work on and bill my time to. So, all change and testing activity is focused on those 3 projects for now.

Week 1:

I spent the first week (only 4 days due to the holiday) in our headquarters meeting with a small number of folks to get a lay of the land on the 3 initial projects I am working on.  Project A is a very typical legacy software application with all of the typical legacy baggage.  Project B is a research project that has about 6 months left.  Project C is a Greenfield software development project that is just getting started and is currently contracted for the next 18 months.

Learning the company’s DNS is going to take some time…I have never been surrounded by so many acronyms before in my life!  My goal for the end of week 1 was to provide a document to the president that outlined my observations regarding areas for improvement and proposed recommendations (in priority order) on where to start.

A tough challenge I always face when I am “interviewing” folks to understand how things work today is to make sure it doesn’t feel like an interview.  I try to ask leading questions so that I am not talking much at all.  Then, as people are answering them, I try to keep a poker face.  So, when someone says, “Environments?  No, we just check in our code from our laptop and then push the build to the production server”  my gut reaction is to drop my jaw, grasp my heart, and stifle a scream.  Instead, I try to look calm and unaffected and then follow that up with a, “How is that working for you?”  What I find most valuable in these sessions is to have the people I am talking to come to their own conclusions on what may not be going so well.  This way, when the time comes to start implementing change, they are already on board with the need for it.  Or, even better, they start changing practices all on their own!

I won’t list all of the issues and recommendations I came up with but here are a few themes:

  1. Planning and Tracking projects
  2. Configuration Management (builds, environments, branching/merging practices)
  3. Testing
  4. Information Sharing within the company

Week 2:

One thing I failed to mention earlier is that I live in NC and the company HQ is in VA.  About ½ of the employees work in VA and the other half are scattered around the country working from home.  This obviously adds another dimension to implementing change and makes it harder.

After reviewing the recommendations document with my boss, we agreed to focus initially on planning/tracking and testing with the 3 projects.  I agreed to do a 2 hour webex with a core group of project leads focused on project planning and tracking.  The company already has Jira and has been using it sporadically on some projects.

I spent most of the first few days of my second week going through Jira and cleaning up some old projects, tasks, etc.  I found some fields that were not being used correctly and cleaned those up as well.  Project C (the Greenfield project) had a complete Microsoft Project Plan built out by the project lead so I imported all of that into Jira to use for the webex as well.

On Wednesday of week 2, I gave a 2 hour presentation that focused on the 5 levels of planning (vision, roadmap, release, iteration, daily).  For some political reasons, I am avoiding Scrum specific language and am avoiding the word Agile as well.  I am focusing my points on Lean and it seems to be received well.  We discussed tracking tools and the expected challenges and benefits from planning and tracking this way.  I was then able to show them a company specific project in Jira set up with a full roadmap and release plan and a burndown chart started for the current iteration (yay Project C!)  As expected, some people were excited, some were a little skeptical, and some don’t buy it all.  Also as expected, the non-believers at this point are the ones that historically have provided little to no direction for their project teams and things are pretty chaotic on that team.  This new approach will require them to get organized, plan better, and communicate regularly with the team to make sure they have what they need.

I spent the later half of the week getting FitNesse running for Project C as well and built a few fit tables to test the first feature that was just completed.

Finally, I am eating my own dog food and I translated the recommendations doc I gave to my boss into a project in Jira as well called “Continual Improvement.” This is where I am going to track the efforts that are non-project specific.  This includes things around CI, Planning, Infrastructure, Tools, etc.   I have monthly releases laid out with high level stories in each month.  For July, I have broken out those stories into detailed tasks with estimates and am updating my time daily as I work on those tasks.  I have set up a call every other Friday with my boss to review this backlog of work together and re-prioritize as necessary.

All in all, the first 2 weeks were a lot of fun and I am really excited about the work.

Week 3 is already throwing some expected curve balls at me….will share soon.


Diary of a Live Process and Quality Improvement Initiative

I just made a move out of the consultant world. I just joined a small company (about 35 folks). They have been in business for almost 5 years and do consulting and contracts mostly for NASA and the FAA. The company has grown quite a bit in the last year and recognized the need to establish some better quality practices across their programs and projects. So, enter me!

I was hired with a fairly loose job description which is a good and bad thing. It is good because I am able to really create this job and have pretty free reign on what I am allowed to do. The bad part is that there isn’t any real clear direction on what they want from me….they just know they need process and testing improvement. So, I don’t really have any solid goals, objectives or priorities to work from.

I will be posting an update every 1 or 2 weeks on what I am doing and how I am doing it (and most importantly, how well it is working!).  I hope this will bring some interesting conversations, suggestions, and feedback from others. My first post will be up next Monday on my first week of work.