Posted on

Agile at a Large Enterprise

I’ve spent the last few years consulting at a large enterprise retailer that has traditionally managed IT projects using a waterfall methodology.  It made sense—being so large, the company is very silo’d with separate IT departments for different functions and a strong business operations team that constantly gets feedback from the field. A structured requirements and design process with very specific scope was a necessity, as budget was allocated to “projects” at the beginning of each year.

But a few months ago, some of the IT leadership started to push for projects in the new year to be managed with an agile methodology (which included the teams that we were working with). I had a lot of doubts as to whether this would work or not, mainly due to the size of the organization and because only a portion of IT was to use agile.

Some of our team members have had experience with agile in smaller organizations, usually startups, but this is a different beast. As one of my friends often jokes: “Agile is just waterfall without requirements and design.” I thought that’s what it was going to be, but a couple of months in, our progress has exceeded my expectations.

Early Going

The first few weeks of the project I tried to keep a positive attitude, but was definitely cautious about how this was going to turn out. Some of my initial questions about how things would work were:

  • What was going to happen when we needed some data modeling work from a team that didn’t use agile?
  • How is testing going to work when there’s an entire department dedicated to QA?
  • How will non-project work, like production issues or helping other teams, be integrated into the process?
  • How will deployments work with continuous integration? We can’t just deploy to every retail store in one day (current process take 6 weeks to get everywhere), so how often are we going to have production deployments and how quickly will they roll out?

Within the first few days my skepticism grew. What’s with all of these meetings? We really need 4 to 8 hours for sprint planning? AND we’re going to spend hours preparing for and doing a demo at the end of each sprint. How does that make us more productive if we’re spending all of this time in meetings?

What’s Worked

Here are a few things that our team has figured out so far:

Since those first couple of weeks, we’ve learned and have grown a lot as a team. I wouldn’t say we’re functioning at our peak yet, but I think things have worked out better than I expected.

  • We had 2 solid weeks of Sprint 0 to start the project to complete tasks such as: environment setup, build setup, high level design documentation, etc. We didn’t complete everything, but it definitely set the project up for success and we really hit the ground running on Sprint 1.
  • The first sprint planning meeting was a long and tedious process, but since then we’ve all become more efficient and comfortable with the discussion.
  • It’s so much easier to see what everyone is working on and the progress we are making (a project manager’s dream). We’ve been using Jira to manage user stories and sub-tasks, which has some limitations and sometimes causes frustration; but generally it gets the job done.

Some Growing Pains

Here are some of the pain points we’ve encountered that we’ll look to fix in the upcoming months:

  • One week almost the entire team was at a local developer conference and was out three days. We tried estimating this during the sprint planning meeting, but we underestimated what impact this would have. When this happens again—like around 4th of July—we’ll be more prepared to estimate properly.
  • As expected, relying on teams and departments external to the project has been challenging. While we try to drive each user story to completion by the end of the sprint, the other teams are on their own timeline and often don’t prioritize helping us because it’s not their project.
  • Recently there’s been some last-minute requests from outside teams that require work and time from our team members. These aren’t included in the sprint user stories, so how do we track these? And how will they impact our burn rate? We talked about adding them as tasks so that we can at least compare our burn rate across sprints (e.g. one sprint we have two non-project tasks and the next sprint we have six non-project tasks). We’ll need to figure this out.

What’s Next

I have no doubt that we’ve been successful because of the strength of all of the team members. We’d probably be just as productive using waterfall methodology too, but the fact that everyone has picked up the changes so quickly and effectively is a testament to the talented team members we have.

It will be interesting to see how our first production deployment goes in a few weeks and how much time is spent on that versus other user stories. I’m looking forward to a retrospective in a few more months to see how we’ve progressed.

Posted on

The Benefits of Being A Technical Project Manager

Over the years I’ve worked with a lot of other IT project managers that never really understand the technical side of their project or product.  Most didn’t even have a desire to do so!  Coming from both a business and technical background, I’ve found that being a technical PM is a huge advantage, not only to me, but also to the greater project and the other members of my team.

In most organizations, a project manager is responsible for:

  • Creating and maintaining a project plan with tasks and estimates
  • Communicating with both IT and business stakeholders
  • Risk management and escalation
  • Managing scope

Yet how can a good project manager…

…verify whether a developer’s estimates are correct for a given task?

…create effective and meaningful status updates without knowing what’s going on with development and QA, and what are the major issues the development team is running into?

…take effective and meaningful meeting notes without understanding what is being talked about?

The benefits of being a technical project manager extend beyond the typical PM responsibilities and create a more well-rounded individual that can help a project in many different ways.


 1. Better Estimates

Fact: Estimating is hard.

If you’re curious why software development projects are always running late, read this great article:

Why are software development estimates regularly off by a factor of 2-3 times?

With software development, it’s easy to forget about things like environment downtime, requirements changes and organization red tape.  When someone estimates it will take “1 hour” to develop a widget because “it’s a very simple [screen/component/function],” I can call B.S. knowing it’s going to take much longer than that.  People often forget about unit testing, handling negative test cases, creating test data to validate, code merges, documentation, etc.  Almost nothing takes 1 hour.

When doing the initial project planning, I think it’s important to work with the developers on the team to map out what the schedule will look like.  I try to ask questions about how complex a task is from a technical perspective, what kind of potential road blocks may arise and how confident they are in the estimate.  This not only helps during the initial planning phase, but also helps with load balancing and figuring out what areas of the project will need the most focus to stay on track.

2. Add Value to Other Parts of the Project

What are the typical ways for a project manager to add value to a project?  Keeping the schedule on track, staying organized, reporting status, etc. But there are only so many status reports one can write. How can a project manager directly help drive the project forward in other ways?

Another great benefit to being a technical project manager is being able to help out where the project team needs it the most.  Here are some ideas during the different application phases where a technical PM can be helpful:

  • Requirements: take notes in meetings to capture requirements and help the BA turn those into documentation
  • Design: ask good questions and sometimes make suggestions during design session that will hopefully generate more discussion and ideas from other team members
  • Development: smoke testing the application before it gets to QA
  • QA: help with defect triage and manage the relationship between development and QA
  • Pilot: work with the application users and take notes on feedback items that can be brought back to the development team for fixes or enhancements

On my projects, I’ve done everything from flashing new OS builds onto mobile devices to suggesting branching strategies and testing applications during pilot with my business team partners.  I will do anything I can to help the project and the rest of my team.

3. Be the Link Between Development and the Business

Perhaps the biggest advantage to being a technical project manager is having the ability to fill the communication gap between the development team and the business team.  This can manifest itself in many ways:

  • Describing how individual development components relate to the big picture for an organization
  • Ensuring the business team understands why certain technical decisions were made along with the benefits and trade-offs
  • Explaining to the business why a requirement may not be technologically feasible – but here are some alternatives

What Now?

So now you’re convinced that you should become a technical project manager…but how?

1. Take Time to Understand Your Project/Product  

Talk to the developers on your team about the software stack.  What kind of database is being used, is the code native or cross-platform, is the application a thin client or thick client?  (And if you’re not sure what those terms mean, go find out.)  What are competitors doing with similar applications or devices, and can anything be learned from those?

Becoming a good technical PM also requires knowledge from the business side of the project to see how it relates to technology.  Take a look at the requirements and talk to the BA on the project.  Talk to the end user (not just the decision makers who draw up the requirements) and learn how the product is going to impact them.  How did the requirements drive technology decisions?

In the end, a project manager is never going to understand the code as well as the developers or the software stack as well as the architect or the requirements as well as the business analyst – but a project manager can be well rounded in all facets of the project and have a high-level understanding of each area.

2. Learn to Code on Your Own

The internet has some great resources and there are plenty of places to learn.  One of the best I’ve found is codecademy, a free and interactive tutorial that lets you code right from the browser for javascript, python, and ruby.  Use this tool as a foundation for understanding data types, boolean logic, conditional statements, and loops – things that can be applied to almost any programming language.

I would suggest starting with web development: javascript, HTML, and CSS.  It is the quickest to get up and running: code doesn’t need to be complied, it can be developed in any text editor and it can run on a browser (something everyone already has).  Plus a lot of people have dabbled with creating a webpage.

3. Build Something on Your Own

After you learn to code, the next step is to work on a side project towards a goal.  Maybe it’s a website or an iPhone/Android application.  Just make sure it’s something that you’re interested in so you enjoy working on it.

In my spare time I’ve worked on a couple of side projects.  One such project is a “Yammer” replacement: a couple of years ago BlueFletch was using Yammer, the “enterprise social network,” but it was slow and constantly required those annoying (and endless) Adobe updates.  I decided to work on a webapp that allows people to post links and comments, and BlueFletch has been using it ever since.  I used that opportunity to improve my javascript skills, play around with node.js (javascript for server-side code), and learn about mongodb.  I built on that knowledge to work on another project for tracking our Fitbit challenge.

4. Share Your Code

My final suggestion is one that you probably will dismiss right now: get on github and share your code with developers.  Even though it may be intimidating to have more experienced developers look at your code, their feedback is going to be even more valuable than the development work you’ve done on your own.

There are still questions over how technical an IT project manager should be?  From my experience, I’ve found it to be invaluable and strive to become even more technical every day.