How I Was on Time On, on Budget, High Impact at Microsoft for More than 10 Years

“Project managers function as bandleaders who pull together their players each a specialist with individual score and internal rhythm. Under the leader’s direction, they all respond to the same beat.” – L.R. Sayles

I know that not everybody is a fan of Agile Project Management and Agile Methodology.

Then again, not everybody got a chance at a proper introduction.

Maybe this is that chance

A colleague asked me to share what I learned about Agile Program Management.

I was on time, on budget, high impact for more than 10+ years as a Principal Program Manager.

Some directors referred to me as “the blockbuster PM” meaning I took on big challenges and nailed them.  (Note that the key to nailing big challenges is by setting Big, Harry, Audacious Goals and building amazing dream teams to pull it off.)

Another director referred to me as “the Abilities PM”, meaning that I focused on quality attributes like security, performance, testability, usability, reliability, maintainability, flexibility, etc.

What I Learned About Agile Project Management at Microsoft

My philosophy is that projects are a team sport and as a project leader your job is to bring out the best in every individual on the team to realize the dream.

I learned a lot about the most important ideas when it comes to shipping great things. In this post, I’m going to share what I learned from a people, process, product perspective.  I’m only going to use that a loose organizing model in the background, and I’m going to go beyond the pure scope of just Agile Project Management to share what’s really helped me.

Mostly I’m just going to dig deep and give you the good stuff you can hopefully use to change your project management game.

Executive Summary of Agile Project Management Lessons Learned

• Agile doesn’t mean fast, it means embracing change (but a byproduct is speed of value)
• A project is a focused effort of budget and resources within a schedule to achieve objectives and key results
• A program is a set of related projects to achieve a bigger, broader set of objectives and key results
• The hierarchy is a portfolio is a set of programs and initiatives, and programs are a set of projects
• Learn the concept of “critical path” so you can improve execution by creating clarity and focus on critical activities, outcomes, and milestones
• If you master Agile Program Management, you master the skill of creating and shaping the future
• The beauty of Agile Project Management is shipping ideas from cradle to grave and bringing ideas to life
• Agile is about embracing change
• Agile methodology wraps development around the customer’s pains, needs, and desired outcomes
• Build deep empathy for your customer’s pains, needs, and desired outcomes
• Agile methodology creates a rhythm of learning by shipping
• Agile methodology creates a rhythm of flowing continuous value
• Use Sprints to agree to a cadence of shipping value
• Demo to your customers to learn what’s valued faster
• Your Product Backlog is your “Everything” backlog, your Sprint Backlog is what you will execute
• Frame the problem to know what’s in scope and what’s out
• Work backwards from a compelling vision that “pulls” you forward
• Use User Stories to chunk value down into increments of value
• Limit work in flight
• Fix time, flex scope
• The people that do the work, should estimate the work
• It helps to have integrating generalists on the team
• Your MVP (Minimum Viable Product) is how you define the minimum working solution that will create initial value for your user base
• Lead with user experience, so your development actually matters
• The Delphi technique is a great way to interview experts while avoiding group think and herd mentality

How I Was on Time On, on Budget, High Impact for More than 10 Years at Microsoft

Before we start, I do need to say that my transition and transformation long ago from Waterfall to Agile was born from pain.

A lot of pain.

I made a lot of mistakes and learned the hard way how to do project management better, faster, easier, and more sustainable.

I wish I could say I was awesome from the beginning, but, no, it was a journey of trials and tribulations and lots of do-overs.  The school of hard knocks punched me really hard in the face to teach me the lessons I needed to learn.

Early on, I succeeded through heroic effort and “death marches”.

No good.  At all 🙁

Yes, I was on time, on budget, high impact, but it was by working incredible hours and ultimately burning out my teams.

There is a pattern among leaders who want to change the world.  When you want to change the world in big ways, it’s easy to be driven by scope.

So scope driven I was.

But as you chase that scope, aside from Scope Creep, the schedule starts to elude you, and your budget starts to evade you.  (the funny thing about scope is that scope is not an automatic lens or validation of customer value)

And next thing you know, everybody is waiting a really long time for the Value Fairy to show up and at least give a first taste of all what all this investment is supposed to be producing.

I transitioned to Agile by rethinking my product management model and by chunking things down into User Stories and System Stories.

“As Bob, I want to organize my work better, so I can feel more in control.”

At last–I finally had a “chunking” mechanism for customer value that worked!  (No Value Fairy required 🙂

And I ultimately found that getting teams on a cadence where the trains leave the station at regular intervals was my ultimate team optimization.

And creating a Sustainable Pace for my teams to flow continuous value while embracing change was my ultimate transformation.

And all I can say is that I hope I can help more leaders transition earlier vs. later, and easier vs. letting the school of hard knocks whack you upside the head.

A Special Note and a Special Mission – “Grow 1,000 Principal Program Managers!”

A former colleague who, sadly past away, challenged me to “grow 1,000 principal PMs at Microsoft”.

He said he never wanted to work with the kind of project managers he worked with, again.  He said he hated putting so much effort, so much time, so much of his life force into projects that either wasted his time or were slogs that didn’t realize his or the team’s potential, and burned people out.

He said he wanted every future project manager he worked with to use my approach.

I asked him what specifically did he think I did differently?

He said …

• You always start by working from a vision that is worth it—a journey worth going on.
•  You inspire great people to do great things through visionary leadership.
• You get people giving their best, where they have their best to give in the service of a greater goal and greater good, in a sustainable way.
• You connect the development team to real customers and real impact so they could feel the impact and see their work turn into a rippling effect and create a movement.  

He actually said a lot more than that, and he left me a bit dazed and confused.

But he said plenty enough for me to start paying attention to, and trying to figure out what exactly I do differently that really matters.

While one article is not enough to “grow 1,000 Principal Program Managers”, maybe it’s a start.

Big Idea #1 – Think of Your Projects as Epic Adventures

I’m putting my most transformational lessons right up front, since it completely transformed how I thought about project and program management.

In one of my leadership training sessions, a colleague told me that with all the stories I shared, that a sense of adventure is really important to me.

She challenged me to show up that way at work and actually “treat your projects like epic adventures!“.

After all, I was taking on big challenges—there were dragons to be slayed, and heroes to be made, as the team went on this journey of growth and greatness together.

Anybody can make a project plan, set milestones, break the work down into smaller chunks of work, estimate the work, assign, the work, etc.

But who is helping inspire the team to get their head in the game and to deeply understand the challenge before them?… to tap into their talents, to lean in with a Growth Mindset, and to coordinate their capabilities so can all win this game?

At her prompting, when I got back to work, I invited the team to hit the whiteboard and draw the movie poster of our epic adventure.

This really got us thinking about the call of adventure, the protagonists, the antagonists, and the trials and tribulations we would most likely fact.

It turned out this simple exercise was not only a great way to inspire a sense of adventure, but also to norm around who is the customer, what’s the problem, and what does success look like?

We were not artists, so our movie posters weren’t great.

But what a great way to start off our epic adventures!

Big Idea #2 – Accelerated Analysis and Design Sessions

This was another game changing move for me and transformation in my project management abilities.

No matter how much I tried to optimize the path, it seemed like trying to fix something from the inside, that needed to be fixed from the outside.

Well, it turned, out, really it needed to be fix up front so that the project could start off from higher ground.

I found the answer to my challenges in the book, How To Run Successful Projects III: The Silver Bullet, by Fergus O’Connell.

According to O’Connell, here are some examples of the key challenges that take the most time:

1. Large amounts of documentation to be produce; much of it caused by write, review, revise nature of traditional requirements and design approaches.
2. Loss of continuity due to the put-down/pick-up nature of the traditional approach.
3. Delay in getting responses and / or decisions.
4. Unfocused effort either resulting in, or because of, low team spirit.
5. Difficulty in getting the right people at the right time.
6. Interruptions.
7. People having other responsibilities.
8. The long time between reviews, walkthroughs, or meetings.
9. The natural overhead in traditional project management methods and structures.
10. Reworking and refining of ideas, documents, etc.

The solution is to compress the project into a focused effort up front, like a rapid scrimmage or a rapid dry run of solving the problem.

Think of this as a fast chance to prototype and assemble the future before people get pulled away or lose energy among the daily grind.

O’Connell calls this effort an “Accelerated Analysis and Design Session, or AAD, and here’s how he describes it:

“Accelerated Analysis and Design (AAD) addresses the problems in the following way:

A one- or two-week long meeting- an AAD session – is arranged. Ideally it will be held offsite.

Invited to the meeting are all the decision makers on a project, be they users and IS/IT people in the case of an in-house development, or engineering and marketing people in the case of developing a commercial product.

All the people who have a say have to attend”.

I’ve done variations of this core ideas from 3 days to 5 days to 10 days, all with various levels of success.

The most important thing I found is to figure out the scenarios, the architecture, and the value, as early as possible to give some solid shape for what you will ship.

You’re not trying to get everything right or do Big Upfront Design… you are simply trying to get going in the right direction, so that your scaffolding serves you.

Big Idea #3 –  Master the Work Breakdown Structure (WBS)

This one is tough, yet potentially could yield the most fruit if you haven’t really master the art of more effective Work Breakdown Structures (WBS).

I think there are a couple of really important ideas here.

The first thing is to realize that your Work Breakdown Structure is effectively the map of the work to be done.  It should be deliverable-based, not activity or task-based.  (Early guidance on Work Breakdown Structures was oriented around lists of tasks).

One of the most effective exercises I ever did was create a Mind Map with the team to map out all the components and sub-components of project success.

We already had our Product Backlog of User Stories as well as a solid Minimum Viable Product (MVP) and we had a set of 5 customers to un alongside us for deep validation.

But there is a lot of “stuff” that goes beyond the pure product that makes is part of the overall project success.  Walking through this, and building a shared map was an incredibly useful team exercise, that also helped build a lot of respect for each other’s areas of expertise.

If you use Work Breakdown Structures, you basically have a way to show the components of your success.  Even better, you can share this map with a mentor or somebody who is more seasoned to help you identify the risk areas and what to do.

This is an advanced concept, but the secret to building and advancing great product lines is building great Work Breakdown Structures.  Ultimately, if done well, it’s your institutional knowledge and blueprint for your crown jewels.

Yes, my friends, the WBS is one of the greatest tools, yet it’s so often ignored, misused or abused, or simply done he wrong way.

Top 10 Project Management Issues that Organizations and Teams Still Do Wrong

I think it helps to first really get a handle on how and why projects go wrong.  This way, we can use the right tool for the job.

Here are the top 10 project management issues in no particular order, based on scanning across hundreds of projects:

1. You ship something nobody wants or asked for (You ship something you didn’t validate with actual users)
2. You have the wrong team for the right job
3. You have the right team, working on the wrong job
4. You have no empathy for the user of your product / service / solution and can’t relate to their pains / needs / desired outcomes
5. You have a lack of stakeholder support and sponsorship (especially sponsorship to help you over the humps and hurdles)
6. Your awesome solution is hiding behind a horrible user experience design
7. You created a horrible “getting started” or “out of the box” or “first-time use” experience (or didn’t create one at all)
8. You made a bunch of plans without involving the team (and the people that do the work, need to estimate the work)
9. You can’t demo your prototype or solution in a compelling way
10. You drive from budget, schedule, task lists, but you don’t inspire from vision and you can’t get the team flowing continuous value, adapting, and learning from customers (and the energy vampires come out)

You can think of these as reasons why projects fail, but, even if projects don’t outright fail, these issues can create projects you don’t want to work on or be a part of or get embarrassed by.

On the flip side, you know you are doing things right when the team has vulnerability-based trust, loves solving the customer’s problem, and loves how they grow each other’s greatness…challenges and all.

Complex projects are never easy… so make them worth it.

The Big Idea of Agile is Embracing Change

I remember a conversation long ago where Ward Cunningham said to me, “You know, Agile isn’t about doing things fast..”

“It isn’t?”, I asked, as if Ward just shattered my world.

“No, it’s about embracing change.”, Ward said.

He continued…

“…But by embracing change, things often end up faster because instead of spending time on things that don’t matter, you spend more time on the things that do.”

And with that Ward let me soak that in, as the cloud parted for me, and I could see the light.

The essence of Agile is embracing change.

The whole point of Agile is that instead of fight the reality of change, embrace the reality of change.

Game on.

The Benefits of Agile Project Management

We should really take a quick look at the benefits of Agile so you have a firm foundation around “Why Agile?” and so that you can make the case when you need to.

Here is a list of the 10 key benefits of Agile:

1. Increase customer involvement which can build empathy
   and reduce do-overs and rework
2. Learn faster which means you can adapt to change
3. Improve quality through focus
4. Reduce risk through shorter feedback loops and
   customer interactio
5. Simplify by getting rid of overhead and waste (hey, is this a sustainability benefit? 🙂
6. Reduce cycle time through timeboxing and parallel
   development
7. Improve operational awareness through transparency
8. Drive process improvement through continuous
   improvement
9. Empower people through less mechanics and more
   interaction, continuous learning, and adaptation
10. Flow more value through more frequent releases and
    less “big bang”

What is Agile Project Management

Let’s make sure we know what we mean when we say “project”.

A project is a temporary endeavor to achieve goals by investing time, effort, and budget to create a product, service, or result.

There is a start date.  There is an end date.

That’s it.

So what makes it Agile?

The agile project management approach is a change in how you plan and execute projects.

Rather than big up front design, or figuring everything out up front and locking in plans that are difficult to change, you enable and empower change throughout the project.

You take an iterative approach and you work on smaller chunks of change at a time while validating with the customer and responding to what you learn around solving the problem through real usage and feedback.

Agile is a flexible approach that changes the way people interaction, the product or solution gets built, how people communicate, and of course, how change gets addressed.

Agile vs. Waterfall Approach

In a Waterfall approach, you move sequentially through traditional project management Phases:

• Requirements
• Design
• Development
• Integration
• Testing
• Deployment

And you complete each phase before the next.

In contrast, with Agile, you perform the same steps but in parallel instead of sequential as part of Sprints.

So you are planning and executing and adapting continuously.

Instead of saying this:

“You can’t change that, we agreed to that 3 months ago” (when we were first figuring this stuff out and didn’t really know what good looks like)

You might say this:

“Sounds like we learned something important, let’s get this on the backlog and prioritize this for the next Sprint.”

With Agile, change is a continuous thing versus an only at the start of a project or with a change request thing.

Waterfall at a Glance

I am a fan of being able to ‘see” the concept I am talking about.

Here is a simple visual that you can whiteboard or hold a thumbnail in your mind:

Waterfall resembles a waterfall because of the way the outputs of each phase cascades to the next.

Agile at a Glance

When I think of Agile, the first thing that comes to mind is that I am flowing continuous value while embracing continuous learning.

Here is a simple visual of Agile:

You can see how you perform the same activities as Waterfall, but instead of sequential, it’s parallel within each iteration.

Agile Project Management vs. Agile Program Management

So what makes it a program vs. a project?

Well, a program is a set of projects to achieve the objectives and key results.  Of course, when we are talking about programs versus projects, the complexity goes up by orders of magnitude because of coordination, orchestration, integration, etc.

This quote by G. Reiss is a clever way to get the point:

“Project management is like juggling three balls: time, cost and quality.

Program management is like a troupe of circus performers standing in a circle, each juggling three balls and swapping balls from time to time.”

And of course, that’s why Program Managers get paid the big bucks, to deal with that complexity.

You’ll notice that one of the highest paying jobs in the market is often technical program management.  So many companies need high caliber project leaders to make things happen and to bring organizational ambitions to fruition.

What I love about Program Management is that it’s a skill for work and life, and you take it with you wherever you go.  But what’s even more important is that with these kinds of skills, you gain the confidence to bring ideas to life.

Ideas don’t ship themselves.  That’s what projects and programs are for

Systems vs. Projects vs. Programs

I really want to call this out, simply because it’s something to consider when you are wrapping your head around the kind of work you are doing.

It’s worth calling out “systems” vs. “projects”.

A project is a change effort with a start date and end date.

A system, or process, is an ongoing effort.

So if something is going to be an ongoing effort, you might actually be setting up a system or a process.

If that’s the case then design accordingly, because designing something to startup, make a change, and shutdown is different than an ongoing effort.

Consider if your ongoing effort is going to be a dedicated team that focuses on routine work and maintenance…

…Or is it it really a program of coordinated projects to drive a big change?

Just like using the right tool for the job, using the right mental model and methodology goes a long way.

What is Agile Methodology

If you first ground yourself in Agile Principles and Practices, you have a firm foundation for your future.

It’s easy to skip over this, but let’s slow down to speed up.

There are 3 key sources for the mindset, the principals, and the values of Agile methodology:

1. The Agile Manifesto
2. 12 Principles of Agile Software
3. History of the Agile Manifesto

With that in mind, let’s take a quick tour of the mindset, the values, the principles and the practices behind the Agile movement and Agile methodology.

The Mindset Behind the Agile Movement

The mindset behind Agile Methodology is fundamentally the idea:

“Embrace change”

Here is a pretty good quote by Jim Highsmith from the History of The Agile Manifesto:

“The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology.

We want to restore a balance.

We embrace modeling, but not in order to file some diagram in a dusty corporate repository.

We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes.

We plan, but recognize the limits of planning in a turbulent environment.

Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as ‘hackers’ are ignorant of both the methodologies and the original definition of the term hacker.”

I think of Agile as embracing change in a disciplined, connected, coordinated, and collaborative way.

The Values of Agile Methodology

Here are the Values of Agile according to the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The Principles of Agile Methodology

The Manifesto for Agile Software Development is based on twelve principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As Ward Cunningham would tell me, “Agile is not about speed, it’s about embracing change” and “it’s all talk until the code runs.”

The Practices of Agile (the Most Important Modern Agile Practices)

I’m just going to call out the 9 practices that Steve McConnell focuses on in his most excellent book, More Effective Agile.

Here are the 9 core Agile practices according to Steve that can either hinder you or help you realize the benefits of Agile:

1. Cross-Functional, Self-Managing Development Team (Self-Organizing Team)
2. Daily Scrum
3. Product Backlog Refinement
4. Product Owner
5. Scrum Master
6. Sprint Backlog
7. Sprint Planning
8. Sprint Retrospective
9. Sprint Review

If you can build a backlog of customer value, ship increments of value, to flow continuous value, get feedback from real customers, and adapt to that feedback to create a continuous learning loop, you are doing really, really well.

In fact, you are probably doing better than most organizations and project efforts that fail at these basics and give project management a bad name.

A Quick Roundup of Practices that I Found Useful for Improving Agile Project Management

We covered the core and foundation of Agile methodologies.

I wanted to keep that clean so that more people understand the mindset, the values, the principles, and the practices of Agile methodology as it was born and applied to the world of software.

With that in mind, I’m going to expand and widen the space to walk through a broader set of ideas and approaches that have helped me transform my Agile Project Management game.

I really take a Bruce Lee approach here:

“Absorb what is useful, discard what is useless and add what is specifically your own.”

My driving force is always effectiveness, efficiency, and impact, while embracing the value of being human, warts and all.

With that in mind, please read on and absorb what is useful…

Framing is the Art of Separating the Should from the Could

As a project leader, you MUST master the art of framing.

Before we get into the details of Agile Project Management, I want to take a moment to acknowledge one of the most important skills that separates the greatest Agile Project Leaders, for the not so great:

The skill of framing

How you frame your project is really the foundation for great Agile Project Management.

If you ever heard someone ask, “How are you framing the situation?” or “How are you framing the problem”, what they mean is, “How are you looking at the situation?”.

They are asking what is in scope so that they know what is out of scope.

Here is my favorite summary on the art of framing from a masterful guide long ago called The Zen of PM:

“The unlimited potential of software makes program management an incredibly exciting job.  The unlimited potential of software also makes program management an incredibly important job.

At every milestone of every product cycle, feature teams face an essentially infinite set of possibilities.

They can build almost anything they dream up.

But to succeed, the team has to make smart choices about where to focus and what to build.  In the face of endless possibility, how do feature teams make these choices?

Framing is the art of identifying what is truly important and separating the ‘could’ from the ‘should.’

Early in the planning stages of a project, program managers work with customers, planners, and other team members to define this frame and ensure that every member of the team understands and internalizes it.”

See what I mean how it’s THE skill to master if you want to master Agile Project Management?

How To Create a Frame

To create a frame, you start with a simple set of questions that you will iterate on as you learn:

1. What are the customers and what are their needs and priorities?
2. What is happening in the market place?
3. What are competitors doing and what are our options for responding and differentiating?
4. How is technology changing and what possibilities does it offer our customers?
5. What are the priorities for our business?

The best frame is the one that works to help you scope the problem, get other people’s head in the game, and win your stakeholders over.  If you can put a good frame around the problem you are solving and how your project will address the problem, your frame will work wonders to help keep you on track, especially when you get mired in the thick of things.

Your frame is a tool to help you create clarity among the chaos and help you refocus back on what matters most and why your project exists in the first place.

Milestones (Significant Events at a Glance)

Wow, this is a big one.  Yet it sound so simple.   This is your chance to chunk up the timeline of events from the start of the project to the end of the project and call out those meaningful events where something significant will be achieved.

Here is my favorite definition of a milestone:

“An event marking a significant change or stage in development.”

Milestones are where you get a chance to visualize, verbalize, and socialize agreed significant events througout the stages of your project.

It’s your chance to put those meaningful milestones on a simple timeline and define success, outputs, and outcomes along the way, at least at a high level.

This gives everybody a sense of what’s going on, what to expect, and how to play in the game.

This also helps people get surprised less, when they know where you are in terms of the milestones.

My Simple Weekly Team Process for On Time, On Budget, High Impact

Thinking back, this really might have been my greatest productivity practice for building high performance, Agile teams.

I use “better energy, better results” to build high performance teams that can ship amazing things.

We all have the same time each week, but my ability to generate energy is THE force multiplier that compounds the team impact across the board.

And I teach each person to become a force of nature to realize and maximize their own productivity potential, the Agile Way.

I’ve shared my methodology long ago in few key guides:

• Quick Summary of Agile Results | Getting Results
• Deep Dive Guide to Agile Results
• How To Lead High-Performance Teams the Agile Way | Getting Results

But here I will summarize and share a quick story.   You can use Agile Results for leading teams the Agile Way with a pretty simple approach.

Here is the core:

1. Monday Vision
2. Daily Wins
3. Friday Reflection
4. Thursday Demos
5. Pair Up

The beauty is that right there will help you not only live and lead the Agile Way, but also create better learning loops.  And best of all, you will also be creating a more engaged team where individuals will be able to practice more mindfulness and create more meaning through their work.

Meaningful work is the backbone of people and teams that will go beyond the job to give you their creative best.   You will be helping everybody with their wellness and wellbeing by creating a positive place for productive flourishing.

I’ve given several talks across Microsoft on how to use Agile Results for team health and mental wellness, as well as how to be more mindful while building great things to change the world.

Wellness works 🙂

Ultimately, I used this approach for more than 2 decades because I wanted the team to have better Fridays.

With that in mind, let’s take a better look at each habit and practice…

Monday Vision (How You Win Your Week)

On Monday, create a great vision for the week by working backwards from your 3 Wins for This Week.

If this were Friday and you were looking back on your week, what do you want to be able to list off as your victories or wins or highlights?

This is your chance to tell a compelling story for the week, by actually working through your Backlog of User Stories and translating them into a simple story you can share in the halls.

For example this week, here is what our success looks like… X, Y, Z will be our 3 Wins for the Week.

You can do this at both the team level and the individual level.

Obviously uplevel it for the team level, so that you can tell a great story about the impact that your team is making.

Speak in terms of victories and if you get stuck, then think in terms of headlines or highlights.

You know it’s working when more people say, “Wow–what a week!”

Daily Wins (How You Win Your Day)

Each day, identify your 3 Wins for Today.   If you are a team leader, it feels good when you know the 3 key accomplishments or 3 key results the team is aiming for today.

But I find the real strength comes from your ability to inspire yourself, and model this behavior for those around you, by creating clarity around what your 3 Wins for Today are.

If you know what today is about because you identified your 3 Wins for Today, you are in pole position.  You can now prioritize, you can focus, and you can make trade-off decisions with skill because you actually have a mental model for what’s important today.

So many people don’t.

They just dive into their day and do stuff and hope it all works out in the end.  And sometimes they get lucky.  But most often, well, you know how that goes.

Does it really take much to step back today, take the balcony view and, given the time you have, the priorities you’ve got and the energy you have, to ask yourself, “What are my 3 Wins for Today?” 

The right questions go a long way for changing your day and transforming you through moments at a time.

Friday Reflection (How You Learn and Grow Better, Growth Mindset Style)

This is really your chance to slow down to speed up.   This is not an exercise to gloss over.

The insights you gain through Friday Reflection may become your greatest levers for growth, individually, and for the team.

For Friday Reflection, you ask yourself…

1. “What are 3 things going well?”
2. “What are 3 things to improve?”   

Use this for self-reflection to learn and get better.

Be honest with yourself.

• If you nail your 3 Wins for This Week, but you don’t feel the impact, do you have to learn more about what’s valued by you, your team, your customer, your organization?
• If you completely miss your 3 Wins, did you trade up or did you simply get randomized.
• If you traded up, use that insight to learn how did you get surprised by better opportunities and could you anticipate those easier in the future?

You can really build your skill of anticipation by looking back and looking for patterns.

But the most important thing is that you fully practice your Attitude of Gratitude here, for those Leadership Moments and Learning Opportunities where you made you proud.   

And this is your chance to really practice your Attitude of Gratitude with your teammates and really acknowledge their wins. 

You are bound to make somebody’s day.

Thursday Demos (Build Deep Empathy with Customers)

There is another practice that I used that fits in with my Monday Vision, Daily Wins, Friday Reflection pattern.   It’s called:

Thursday Demos

I used Thursday Demos to build deep empathy with customers among the team.   Before this, I used to demo to customers and try to bring the insight back to the team.  Sure, I could bring the insights back.

But what I couldn’t bring back was the deep pains, needs, and desired outcomes from the customer with any real sense of connection.

I couldn’t bring back the full feeling of embarrassment when I click on something or go to show a visual that really just doesn’t match expectations or the intended experience.

Plus, it made me the bad guy when I had to be the one to tell everybody why something wasn’t up to snuff, or really didn’t meet the quality bar, or didn’t really resonate with the customer.

But I also learned that the makers on the team weren’t showing and sharing their stuff enough.  I realized that if they build the habit of “Demo + Deliver”, then they could start to build more customer empathy.

I also found that when each individual had to demo their stuff, it completely changed their perspective.  They went from the perspective of the “producer” or the “maker” to the perspective of the “consumer” or the “user”.

And that right there was enough for each individual to catch their own mistakes and opportunities for improvement.

So I turned Thursday Demos into basically a “Show and Tell” (or really, a “Show and Share”) for the team.   Sometimes it would just be the team, when we didn’t have the customer, or when we had to do a first round of feedback on the team.

This helped everybody practice the habit of “be the customer” (one of my most important habits and practices to win in the market).

And this also gave everybody a mini stage to showcase their work.

Ultimately, this practice helped make the invisible visible and gave more people a chance for acknowledgement and appreciation, while they learned how to demo their best work better.

Pair Up (How To Keep Everybody Going and Growing Strong)

Pairing is not just for programmers 🙂

Individuals will naturally have their strengths and talents, and their weaknesses, too.

They will get stuck on things, and one person’s sticking point, is another person’s skill.

I found that by pairing up the right people, not only does it help individuals get over their sticking points, but it’s also a great, fast way to transfer skills, too.

By paring up complimentary skills and abilities, you compound your capabilities and competencies.  You help people keep their energy and momentum going and people never feel like they are out on their own.

Sometimes you will be surprised, in fact, many times you will be surprised wich pairings produce the greatest results.  Stay open to possibilities and experiment often.  Plus it’s a great way for team members to really learn about and appreciate each others.

The 3Es of Execution (Explore + Envision + Execute)

To simplify, this is my personal mental model for executing projects that has served me extremely well for more than 2 decades:

• Explore
• Envision
• Execute

I’ve used it for multi-million-dollar projects as well as small projects, for teams of more than 40, to teams as small as two.

As much as I enjoy the myriad of frameworks people throw at me (and impose on me), I find that it really helps to zoom out to the balcony view.  I can very quickly get people on the same page if we agree whether we are exploring the problem or exploring the solution.

Here are a few quick notes:

• I find the 3E Execution model really helps to explore the challenge up front to discover the right problem to solve for the right customers or client.
• This might seem like another project management hack, but I am a fan of doing a few “architectural spikes” to reduce project risk up front and to get a better sense of the tough stuff.
• I see far too many projects that go along thinking everything is fine and dandy, then start to hit the tough stuff and either abandon ship, or the project slows to a crawl, because Nobody paced or braced for the hiccups and the hurdles that can go from a tiny molehill into insurmountable mountains.
• Using this simple approach of Exploring first, really helped me Envision from a firm foundation, while reducing risk and accelerating a smoother execution.

Of course, surprises still happen and of course learning is an ongoing journey, but if you have to walk over the hot coals of Hell, it’s nice to get a break.

And you can solve all the world’s problems…just not all at once

Exploring Problems and Solutions with the “Double Diamond”

This is a simple process model that can help you reduce conflict by showing everybody where you are in the process.

It helps get everybody on the same page, and avoid hammers looking for nails (that don’t exist, so now you’re screwed).

It’s called the Double Diamond because it looks like two diamonds:

The Double Diamond helps you create clarity by having a simple mental model to guide and check:

1. Are you on the problem side or the solution side?
2. Are you expanding or contracting… diverging or converging?

An pro tip here from Dr. Roger Firestien is that the best output of the problem side is a creative question worth solving as input to the solution side.

I know this can seem a little silly, but you’d be surprised how many people and team’s fight because they don’t all know where they are with respect to each other.

You can think of this as a simple map to help get back to common ground and find your footing.

3 Key Perspectives (Human Desirability + Tech Feasibility + Business Viability)

So many projects fail because they don’t consider the right perspectives that will make them successful.  You solve challenges better when you consider multiple perspectives and take a multi-perspective view.

Otherwise you end up with science projects that you can’t sell or nobody wants.

To succeed more often, take a multi-perspective approach:

• Human Desirability
• Technical Feasibility
• Business (or Economic) Viability

Here is a simple visual of the triad to put a thumbprint in your mind:

The Innovation Sweet Spot is at the intersection point between Human Desirability + Business Viability + Tech Feasibility.

It’s a powerful place to explore possibilities because you’re in the zone where desire meets viability meets feasibility.

Persona-Based Scenarios with Goals

Long ago I remember learning a couple of crucial concepts from reading About Face: The Essentials of Interaction Design, by Alan Cooper.

The two main ideas I remember that helped me were:

1. Use persona-based scenarios with goals
2. Design for the perpetual intermediate

The whole point of personas is to help engineering teams build better empathy with the user base.

By having a persona you can reference that everybody on the team relates to, makes it easier to understand, prioritize, and drive decisions and trade-offs.

I remember trying to inspire everybody to just think in terms of “persona-based scenarios with goals” so we stay on track with helping our users resolve their pains, needs, and desired outcomes.

The point about “design for the perpetual intermediate” is the idea that people don’t stay a first-time user and that, even if you have an advanced user, eventually people end up operating back in the world of a perpetual intermediate.

This helps you avoid creating complex solutions and over-optimizing for the beginner, while everybody else drops off cliffs.

I find this practice is a bit of art and science and one of the ways I related to it was by asking, “What would 8 out of 10 people do?”

It wasn’t perfect, but it helped more people realize I was trying to find that place where more people operated from.  The infamous “typical” user.

One-Sentence Stories for Capturing and Sharing User Stories

I’ve been on projects large and small.  My larger projects were multi-million dollar projects and involved remote teams distributed around the world.

I needed to develop a very fast, very simple way, to share catalogs and backlogs of user stories.

My favorite approach has always been to user One-Sentence Stories:

As a < type of user or persona >, I want < some goal or intent> so that < some reason or benefit >.

I find that it’s very easy to manage an index or catalog of One-Sentence Stories.  It’s the Master part of the Master/Detail.  It makes it possible to do rapid reviews around an early index of One-Sentence Stories.  The details will come as we get closer to implementation, or as we walkthrough and talk through demos or storyboards.

Really, this approach to One-Sentence Stories also makes it possible to incrementally learn and render our understanding of what good looks like.

Users don’t always know, but you can start somewhere, by capturing what they want or need or trying to accomplish.  Then you can figure out the reason or intent, and this will shape the story further.  Then, when you demo or walk through a storyboard, you will gain an incredible amount of clarity, because you are making the story specific.

You can ask and answer the tough questions.

The Long Lost Art of “Architecture Spikes”

An Architectural Spike is an investigation into an architecture challenge to better understand the challenge, the risks, potential solution alternatives, and trade-offs.

It’s an “architecture” spike because it’s a thin slice of an end-to-end scenario.

Like a 3 layer cake, you are not just licking the icing.

You are cutting an actual slice of cake with the 3 layers and taking a bite.

So this might mean testing a user story where you go across the user experience, the process, and the data to learn more about potential architecture choices and trade-offs.

This is one of the best ways I’ve found to reduce risk and accelerate teams with less surprises during project execution.

Note that while you can’t turn everything into an Architecture Spike, you will get better with practice at identifying the high risk scenarios that are worth spiking.

I remember my friend Dragos Manolescu long ago explaining why my projects were lower risk even though I was working on high risk stuff.

He said I did a good job with the team of doing the Architecture Spikes up front and he pointed me to a really great read, that I no longer remember, but the point of it was Spike more to get surprised less!

The Underused Practice of Finding the Right System “Metaphor”

It’s a practice from Extreme Programming (XP), but I found the use of Metaphor to help create a shared mental model of what we are building or doing.

According to Bjorn W, Metaphor is not a well-understood practice, and, as a result, not commonly used in practice:

“Extreme Programming (XP) was designed to produce vast amounts code and deliver software quickly and timely with less cost.  To facilitate that process various practices have to be implemented, one of which is the practice of System Metaphor.  

Unfortunately, it is one of the least understood and is rarely put into practice as a result.”

What a miss!

Metaphors are words and stories to help communicate what’s being built.

Here is how Explain Agile.com puts it:

“Essentially, System Metaphor is all about communication. 

It is about using the right words, the correct labels to communicate effectively the content and the goals of the software being produced.
Some call these labels and words, stories. For them, it is about creating a story for the product.”

The next project you save or get funded might just be because you nailed the right metaphor.

Build a Shared Mental Model of your System Through Story Mapping (the “Backbone”)

One of the most important visual tools you can possibly create to build a shared understanding across the team, across stakeholders and with your user bases is the “Backbone” of your solution.

You can depict the Backbone of your solution by using Story Mapping.

Just shipping high priority User Stories doesn’t create a coherent understanding of what you are actually building.

I remember so many times early on asking the team, “Are we working on Frankenstein’s foot or his head or what?  Where are we? ”

(And a dump of User Stories sorted by priority never really told the story or created shared understanding of the full map of our solution).

When you have to make calls on what to cut and what to keep, and how to shift things around as you learn your problem and solution space better, having this shared mental model, this Backbone of your Solution, is how you stay nimble and gain extreme agility and accelerate your choices while keeping your eye on the prize.

The best description and consolidated walk through that I have seen on this is from the book More Effective Agile, by Steve McConnell.

The challenge of hundreds of stories is an incoherent view of the solution.

Steve writes:

“Because product backlogs often consist of dozens or hundreds of stories, it’s easy for priorities to get confused and the collection of items delivered at the end of each Sprint to be incoherent even if, individually, they represent the highest priority backlog items.”

The big idea of Story Mapping is a coherent and comprehensive map of your solution by organizing your stories better in a visual way.

Steve writes:

“Story mapping is a powerful technique for prioritizing the sequence in which stories are delivered while simultaneously shaping the collections of stories into coherent packages.  It also helps with elicitation, analysis, and specification of requirements, and it becomes an aid to status tracking during development.”

The approach is simple but it takes practice and persistence to build real skill.

Steve writes:

1. “Capture major chunks of functionality on sticky notes and arrange them in a prioritized line from left to right, highest priority to lowest.  Major chunks in functionality will consist of features, epics/big stories/themes, initiatives, and other large-brain requirements.  I’ll refer to these generically as epics in the rest of this discussion.”
2. “Decompose top-level epics into steps or themes.  This elaboration does not change the prioritization of the epics.”
3. “Decompose each of the steps of themes into stories captured on sticky notes.  Arrange these below each step or theme in priority order.”

This kind of clarity is rarely seen among teams and leaders.  Don’t be the bewildered one.  Be the one who lights the way.

Find the Sustainable Pace for an Energized Team, Ready for Anything

This is how you build better, more sustainable teams with a focus on wellness, wellbeing, and mental health.

It can help you certainly be more mindful too, especially as you focus on prioritizing meaningful, high value work, vs. cranking out the low value widgets nobody cares about or ever uses (this is why your skill of validating with customers, not only helps you ship better products, but saves you lots of time from building out things that nobody wants or needs.)

Sometimes I miss when the Extreme Programming practice was called 40 Hour Work Week.  Even though it was a guide, it helped people get a strong sense of the idea behind it.  The main idea was to increase productivity by using a healthy pace — not by throwing more hours at your project.

In fact, more hours often translates into less quality, more fueding, more burnout, and low energy.

But too many people took the idea of 40 hours literally and missed the idea of creating a Sustainable Pace for the team, so eventually 40 Hour Work Week was renamed to Sustainable Pace.

Given today’s context, Sustainable Pace is actually a pretty good choice of names now, so maybe more people will learn or start to practice it?

The most important lesson I learned here is that it’s not about how long I can go here.  Me putting in extreme hours or heroic effort didn’t help.  Instead, it was about finding a Sustainable Pace for the team where people could feel energized, rested, relaxed, and ready for anything.

You’re doing it right when people are feeling good about doing their great work and treating each other like fellow human beings.

Key Ideas from Agile Methodologies (XP, Scrum, Kanban)

I always appreciated when somebody would boil down the big ideas or essential concepts that matters in a simple list.

Here is a starter set you can work from:

Methodology	Practices
XP	Ideas embrace change in software process by shipping in small increments to learn and adapt to changing and evolving requirements Practices Coding Standard Collective Code Ownership Continuous Integration On-Site Customer Pair Programming Planning Game Refactoring Simple Design Small Releases Sustainable Pace System Metaphor Test-Driven Development
Scrum	Ideas embrace change in project management process by shipping in small increments to learn and adapt to changing and evolving requirements Practices Burndown Chart Daily Scrum Definition of Done Estimation Impediment Backlog Product Backlog Product Owner Retrospective Scrum Master Scrum Team Sprint Sprint Backlog Sprint Demo Sprint Planning Meeting Velocity
Kanban	Practices Limit WIP (Work in Progress) Measure the Lead Time Visualize the workflow

Stretching the Agile Boundary

You need to consider the Agile boundary in the organization you are dealing with.  If you ignore or misunderstand the boundary you can encounter misaligned expectations and other problems.

In More Effective Agile, Steve McConnell shares the idea of learning about your Agile boundary in your organization.

Steve suggests considering the following scenarios and the implications:

1. Agile software development and non-Agile regulations
2. Agile sales and non-Agile software development
3. Agile software development and no-Agile enterprise customers

Steve suggests you learn where the Agile boundary is:

“It is useful to understand where the boundary is between Agile and no-Agile part of your organization—both the current boundary and the desired boundary.”

Steve says the Agile boundary can vary depending on the organization and leaders:

“If you’re a C-level executive, the area inside the Agile boundary could include your entire organization.  If you’re the top technical leader in your organization, it could include the entire technical organization.  If you’re a lower-level leader in your organization, the area inside the Agile boundary might include your teams.”

Steve writes that many orgs don’t achieve end-to-end agility, and you need to consider whether you even need to:

“Most organizations cannot achieve end-to-end agility. Your organization might not see any benefit from Agile HR or Agile procurement.  Even if you commit to Agile for your whole organization, you might find that your customers or your suppliers are less Agile than you are.”

Do you know your Agile boundary?

Where do you want to take your Agile boundary, today?

How I Used the Delphi Technique to Get Better Answers Out of Experts

The Delphi Technique, simply put is a group decision-making and forecasting approach where you collate the judgments of experts.

The main idea is that you can use the Delphi Technique to help reduce Group Think and Mobe Mentality and get a better, unbiased decision.

Some people use this for estimating so they can get a better understanding of the range of estimates, and why one person might think the work takes much longer than another.

The Delphi Technique can help find the anomalies and the risks.

I modified my approach to work remotely and to work fast.

In my case, because I built a lot of prescriptive guidance, I used the Delphi Technique to give experts the chance to express their recommendations, their experience, and their perspectives in a safe, and less group-biased way.

My take is that this technique can help you create psychological safety in some ways, especially where identities and egos are among important decisions.  If you explore the basic concepts of Delphi, that should be enough to make you dangerous

What I Learned Building Better Dream Teams

I want to wrap this up with what I learned about building dream teams.   After all, as John Maxwell put it so well:

“It takes teamwork to make the dream work.”

Do you build a team that runs towards the problem, or that can’t wait to run away? (And inadvertently create a team of passive aggression and conflict that sucks the life force out of everyone involved)

Early in my career, at the start of each of my projects, my General Manager would ask:

”Who is the dream team you need to pull this off?”

After all, would you sail off to Kong Island without a great captain of the ship that knows the way and can find their way back?   Or Antartica (Oh, there’s a few stories).

This forced me to become a really good talent scout.   He didn’t mean just find the best at Microsoft.  He encouraged me to find “the best in the world”.

Here are some key insights:

• This exercise forced me to become really good at mapping out the domain to deeply understand the space I was heading into.  In fact, information modeling became my super skill.
• While I couldn’t always get the dream team, it helped set the stage to build the dream team and better understand the types of people I need.
• I could attract top talent including Distinguished Engineers and senior leaders to the company by working on the big kinds of “epic adventures” that change the world.

What surprised me in all this is that I was not able to simply go the board, list the roles required for the work, and get a solid sense of who that team needs to be.  For example, if I tried to design a winning baseball team, by walking through the roles of pitcher, catcher, 1st base, 2nd base, 3rd base, etc., I couldn’t do it.

That’s too abstract.

But if I instead just used a whiteboard to work through my first draft picks and list out the names of the people that I would, that was easy.  It was more concrete.  It helped me figure out figure out what specific talents, skills, and capabilities I needed, even if I used a completely different set of people.

To test if I had the right team in mind, I would test myself by asking:

“Is this a team that will run towards the problem?”

Or, with a Growth Mindset, *could* this team learn together how to run towards problems?

Whether by luck, chance, or unconscious skill, I always designed for a diverse team that was inclusive of each other.

Complex challenges, take diverse thinking to solve them (the leaders who embrace Cognitive Diversity will win the future).

And the most important attribute I wanted on the team was a foundation of vulnerability-based trust:

Nobody goes out on a limb for you if they are worried you are busy sawing off the branch!

What I also learned, is that you can build the team of greatness…even if the team does not start out great.    I learned this lesson deeply by the way John Wooden modeled building winning teams in basketball going from not so good, to amazingly great (and greatness is contagious!).

But you have to really care, and you have to really coach.

And remember to think “teams of capabilities over teams of roles” (roles can be really fuzzy and are supposed to imply a set of capabilities, but mileage varies a lot).

How I Wrote this Article Using an Agile Approach

I set a timebox for this article—I gave myself 1 hour to write what I think the most important concepts are.

You could say I gave myself a 60-Minute Sprint.

I created a quick Backlog of the most important cornerstone concepts, questions, and ideas.

To Fix Time, Flex Scope, I am focusing on a subset of the most important questions and concepts.

I am embracing change and will use feedback to iterate on my article as I learn and improve.

For now, I’ll share what I think is an MVP of good enough information to help somebody level up their Agile Project Management game.

The 10 Best Book on Agile Project Management

1. Agile Management for Software Engineering, by David Anderson – a classic in this space, learn about the “theory of constraints” and key concepts like “Drum-Buffer-Rope”.
2. Agile Project Management with Kanban (Developer Best Practices), by Eric Brechner – the definitive guide to shipping smart and shipping well while shaping software with skill, and a masterful way to lead teams through the trenches.
3. How to Run Successful Projects III: The Silver Bullet (3rd Edition), by Fergus O’Connell – this is THE book that had the most radical impact on my transformation as a program manager because of the thorough coverage of critical skills and crucial techniques and hardcore examples.   Reading this book was the first time I really understood the full power of project management.
4. Just Enough Project Management, by Curtis Book – this is an incredibly compact book, chock full of serious productivity advice and really crisp and clear management advice whether you are leading one project or many.
5. Making Things Happen: Mastering Project Management, by Scott Berkun – the essential guide to serious program management skills and really a lost tomb of know how.
6. Managing the Design Factory, by Donald Reinertsen – one of the best books on the fundamentals of product design.  Takes your product development game to a whole new level.
7. More Effective Agile, by Steve McConnell – this is how you hone in on and implement Agile with a sharp focus on the core set of Agile practices that make the difference.
8. Requirements-led Project Management: Discovering David’s Slingshot, by Suzanne Robertson and James Robertson – this is one my most ear-marked books.   The visuals and descriptions helped me really get how to build better products.
9. Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, by Ian Alexandr, Neil Maiden – this is the most hard core walkthrough of every variation and definition of types of use cases, stories, and scenarios I have ever seen.  It served me well so long ago, to really understand which tool to use when, and why.   It helped me also be clear to always consider both User Stories AND System Stories.
10. Secrets to Mastering the WBS in Real-World Projects, by Liliana Buchtik – the best guide I ever read on the art of the Work Breakdown Structure with lots of good examples and real-world advice.

That set will serve you well.   Each book is a precious chunk of knowledge to add to your library.

There is one more book I have to mention, because it’s been one of the most inspiring, enlightening and entertaining project management books on my bookshelf:

Hollywood Secrets of Project Management Success, by James Persse.

OK, OK, I need to mention just one more, and this is really the last one, and then I’m done:

Strategic Project Management Made Simple: Solution Tools for Leaders and Teams, by Terry Schmidt

Terry’s book felt like reading the one book I felt I was always missing to complete my collection.   It’s the best book I’ve ever seen on strategic project management.

And what I found is that when you understand how to operate at a strategic level, you compound what you are capable of in terms of Agile Project Management.

Now don’t say I never gave you anything — by going beyond my Top 10 books list, I just gave you an example of Scope Creep 🙂

Call to Action

1. Turn your projects into Epic Adventures and get you game on.   This is a surefire way to engage the team at a more meaningful level and make more significant impact.
2. Master the Work Breakdown Structure and User Stories frameworks so that you can break down work with skill and ship incremental value while lighting up your MVPs.
3. Learn how to do Accelerated Analysis and Design (AAD) sessions so that you can create the scaffolding for your project success and generate energy around your compelling vision and value.

P.S. – this is a note for my angel of a friend who is no longer here with us, except in our hearts and in our minds, that in addition to the goal of “grow 1,000 Principal PMs”, I managed to use the special words he wanted me to live by… Dig Deep and Go Beyond (which I sometimes think of as Grow Beyond).

You Might Also Like

What is Agile?
10 Ways to Make Agile Design More Effective
40 Hour Work Week at Microsoft
Agile Methodology in patterns & practices
Extreme Programming (XP) at a Glance
How Much Process Do You Need? (Just Enough)
Project Management Body of Knowledge (PMBOK) at a Glance
Project Plans in a Nutshell
Software Methodologies at a Glance
Waterfall to Agile