Core10 Insights

I managed a project to implement a new network design in an active data center. We needed to physically and logically move everything related to the network in one weekend; Core switches, firewalls, guest Wi-Fi, web and application controllers, routers, and some ancillary items all needed to move. A change of this significance needed detailed planning, communication, and coordination. Despite all of those being waterfall methodologies, we applied an Agile mindset. We started by aligning responsibility and authority. A Senior Network Engineer was asked to be responsible for making this effort a success and we gave him the authority to organize the team.

I managed a project to renovate a data center that had been built in the 1960s when mainframes, which require little power and produce very little heat, were the primary occupants. The building simply couldn’t handle the power and cooling needs of modern servers. This data center was an active data center with production equipment running; Care needed to be taken in every step, including demolition, to ensure business as usual continued.

When things still don’t go as planned, how do you respond? Do you fall back on the documentation and blame the customer? Do you blame the developer for incorrectly estimating how long the task will take? Both traditional and agile methodologies allow you to take these approaches. Rather, simply state the facts and involve the customer in these discussions. You’ll find that almost everyone understands some things are out of your control; The true test is how you deal with these events. You can hide behind your “contract” or you can have an agile mindset and put the issue out in the open to be worked on collaboratively.

The governance that often comes with a traditional waterfall project management environment can reduce opportunity for critical thought and personal accountability. Project Managers are often held to strict methodology guidelines and monitored relentlessly to make sure they are completing every step. They in turn assign tasks to the project team members and monitor the tasks with little thought as to the relationship of the task to the goal. This strict governance leads to a Project Manager modifying reality to fit the plan rather than responding to change.

When creating a team, look for attitude, which is difficult to train, over skills that can be trained. Put more value on a professional in their trade than experience in a short-term need (e.g. “I need a strong UI developer with x skills” rather than “I need a UI developer with x specific experience”). Create a team based on competency rather than pedigree and teach them how to use the tools, whatever the methodology.

“Are you an Agile PM?” is a question I often heard earlier in my career as a Project Management consultant. And often, my answer had been somewhat awkward because I inferred the question was really “Do you use scrum or other agile methods?” I use agile methods, and they are my preferred project methodology. Yet in my career, I have worked on many projects that required a more traditional waterfall approach due to their nature. Traditional waterfall clients asked, “Why do projects you manage have a higher success rate than our average?” I’ve realized the answer to both questions: I have an Agile mindset in a Waterfall world.