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.

Advertisements

2 Responses

  1. Based on my experience project tracking in a organization that is not mature is more important than Project Management.

    Project Tracking reduces complexity; it focuses on the progress of a project and its cost.

    Project Tracking allows us to define a clear process that minimizes confusion (get out of the forest) and follows a clearly defined project flow. In a mature project tracking process Project Managers can use different project management styles (waterfall, iterative, etc.), but must manage to established key milestones.

    At any time during a project stakeholders may want to take a closer look at the detail project plan and that should never be an issue (responsibility of the Project Manager). A mature Project Tracking process will have a central archive with easy access to key project artifacts.

    This process focuses on measuring progress (milestones), analyzing issues (Revisions) and controlling the cost of the project (Time Tracking).

    This process encourages interaction among stakeholders, and puts stakeholders in a position to take new actions as needed.

    Companies that benefit the most from focusing on Project Tracking are large companies that manage many applications to support their business, maintains its own software development area (internal / external) and depends on technology as a competitive advantage.

    Jim
    torres1429@gmail.com

  2. Thanks Jim! I agree that project tracking is critical. Part of what I was including in the project management umbrella is clearly defined goals/tasks for the team to work on (whether you call them User Stories, requirements, etc). I think that is just as important as tracking. If the team doesn’t have clear direction on what to be working on, then there won’t be anything to track.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: