What's better, Agile or Waterfall? How about Program Evaluation and Review Technique (PERT), Rapid Application Development (RAD), PRojects IN Controlled Environments (PRINCE2), Extreme Programming (XP), or some of the other more obscure techniques? This shouldn't be an either/or question. All of these project management methodologies have value, and smart CIOs use elements from all of them to be successful. There's no sorting hat that declares you Agile or Waterfall before your project begins. Don't make project management a religion—people get projects done, and the tools they use are just that: tools. What tool do you prefer, a hammer or a screwdriver? It depends on the job (although hammers are way more fun).
It's important to carefully balance team-level autonomy with enterprise consistency. Teams should be permitted to create and follow their own processes depending on the type of work. A pure app dev team follows different methods than the team supporting SaaS software. Infrastructure teams have completely different needs than app dev teams. Grant these teams flexibility within the context of enterprise-level guardrails.
Regardless of your methodologies and specific needs, a number of concepts, tools, and approaches can help you manage your projects and your teams. Let's take a look.
Standardize across your organization on terminology, forms, and meeting minutes. The exact form is less important than consistency across teams. Many of your internal customers will be involved in more than one IT project. It creates confusion when every team uses different lingo. QA, dev, test, and sandbox should mean the same thing from team to team. Do you prefer bug or defect? I don't care; just pick one.
At the enterprise (portfolio) level, you need a ranked project list. As discussed in depth in Chapter 30, this list provides clarity on what is most important. If the number one project requires virtual servers and your cloud engineer says they're too busy setting up the servers for project #25, something is awry.
Imagine your company sells goods and services online. The web team is operating on two-week sprints that end every other Wednesday. This team is following advanced DevOps practices with an established Continuous Integration (CI) / Continuous Deployment (CD) pipeline. Your order management (OMS) team, also Agile (ish), operates on three-week (ish) sprints; if the release is not accepted, they adjust the deployment schedule until it is ready. Down the hall, the warehouse management team (WMS) is following a Waterfall model where they deploy code to production at the end of a major project, usually two or three times per year. When a new feature requires all three teams to make a change, you have a mess on your hands. Let's go back to culture for a moment. It's hard to imagine that these three teams feel like they're part of the same organization. The friction created by the different styles will create animosity and erode the culture you're trying to foster.
An easy first step is to unify on a single release calendar. In this example, I'd make the web team's calendar the department standard. From now on, everyone deploys to production every other Wednesday. If a team is not ready, they skip that cycle. At first, the OMS team may slip to a four-week sprint, and the WMS team still only deploys a few times a year. But at least they're all going to production on the same day, which is a good start. Once the calendar is unified, focus on automated testing for the OMS and WMS teams. Automated testing is the key to more frequent releases.
The best process I learned from SAFe is big room planning. This is a quarterly meeting that brings together all constituents across the organization to plan, prioritize, and review the work for the next quarter. Big room planning takes the prioritized project list down to the feature and story (use case scenario) level. It makes IT work visible. It's an extremely powerful opportunity to communicate everything IT does with your executive peers. We used blue painters' tape to draw a line on the wall. Everything below the blue line was out of scope for the quarter based on the team's capacity. Something unexpected happens when you openly and honestly tell your business partners what work you can't get to: they are now empowered to prioritize something else, come up with a manual process, or intervene to provide IT with more resources.
The Covid-19 pandemic has put a temporary halt on big room planning events. Clever people are devising virtual equivalents, but in-person meetings are still best. Post-pandemic, we will continue to have a more remote workforce. Big room planning is the ideal activity to bring cross-functional teams together four times per year.
Every project needs a charter. A charter is not just a legacy Waterfall tool. If the term charter sounds too heavy for your organization, use terms of reference or some other gentler-sounding name. Regardless of what you call it, the document needs to contain the who, what, why, when, where, how, and how much: the basics that explain the objective at the highest level and how to accomplish that objective. Keep this document concise. For some projects, it's important to include an out-of-scope section in the charter. Approved projects tend to get add-on work. The bus is leaving, and everyone wants a seat. I even advocate putting small items into your projects in Chapter 28, “What Should I Work on First?” While a few small things can be included, scope creep is the enemy of on-time and on-budget. Be clear about what's in and what's out in the beginning; this avoids misunderstandings later.
I will happily argue that Microsoft Office is the best and most important business tool ever produced. On the flip side, Microsoft Project may be the worst thing that's happened to IT project management. Microsoft Project is a project scheduling tool, not a project management tool. The latest Project Management Body of Knowledge (PMBOK 7) includes 49 project management processes, and MS Project can help with fewer than five of them. In an Agile environment, there is no place at all for MS Project. I may be overly salty on this point, but I've seen too many projects go awry when the project manager became hyper-focused on creating a schedule at the expense of the other 48 processes. At the very least, Microsoft should change the name of this application to MS Project Scheduler.
Rant over. I have good news regarding tools: Microsoft 365 comes with a powerful new tool called Microsoft Tasks. This tool can be made visible from within Microsoft Teams, and it combines the Planner functionality with the To-Do functionality from Wunderlist. Whether your team follows Scrum, Kanban, or traditional methodologies, this embedded lightweight tool is a terrific way to organize and visualize tasks.
Kanban is the Japanese word for a visual board or a sign. In project management, the word Kanban represents a process by which tasks are visually displayed on a board aligned into columns based on their status. Making work visible is a powerful tool for getting work done. A three-column Kanban board with backlog, in-process, and completed as the columns is an excellent way to get started with Kanban. When the team meets, team members move their assigned tasks from the in-process column to the completed column. Then they take a task they wish to work on next from the backlog and move it to the in-process column. The team member is selecting their next task; their supervisor is not assigning the task. This improves buy-in and, therefore, productivity. It's motivating to move tasks to completed, and it doesn't feel so good to have the work assigned to you sitting unfinished for very long. If your team meets in person, a large, on-the-wall Kanban board is preferred. If your team is virtual, then use a tool like Microsoft Tasks, or Microsoft Whiteboard using the included Kanban template, to create and display an online Kanban board.
Regardless of the specific tools and processes your team follows, CIOs and CEOs need to instill an Agile mindset in their organization. The Agile manifesto implores us to place a high value on human interactions and collaboration. By delivering working software more frequently, changes are less expensive and, therefore, well-tolerated in an Agile organization.
Entrepreneurs have learned that failure is a valuable learning tool, and they've embraced a fail-fast culture. Will large, risk-averse organizations be able to adopt these practices? Compare NASA's SLS program to SpaceX's starship program. After 10 years, NASA has spent over $18 billion without a single launch. By the time the rocket flies, the design will be obsolete. Meanwhile, SpaceX follows a launch, explode, learn, adapt, and repeat method. The iterative or Agile approach of SpaceX is creating a better, cheaper, more capable rocket than NASA's traditional approach. Agile is not all or nothing, as some of the Agile zealots would have you believe. Instill an Agile mindset in your organization, and iterate to more Agile practices over time.
In an attempt to improve output, I once added two people to a four-person team. My simple math concluded that this team would be 33% more productive. What happened? In the next sprint, their output decreased. What was going on? More people, less velocity? In 1965, Bruce Tuckman published the forming–storming–norming–performing model.37 My scrum master explained that any change to a team, including adding resources, resets this model back to the start. In the long run, the team's velocity will increase, but in the short term, the change moves the team from performing to forming.
The worst thing you can do at the end of a successful project is disband the successful team. A team that delivers is a precious commodity. Keep the team intact, and flow work to it. In a pure Agile environment, we fund teams, not projects. The work they deliver is based on the feature backlog. It takes time and trust to get to acceptance for this practice in an annual budgeting, ROI corporate business model, but when you do, the output is impressive.