Project Practitioners > Why I am more afraid of too-much project management than not-enough

Why I am more afraid of too-much project management than not-enough

By Cinda Voegtli

I maintain that too much project management (or in some cases, simply the perception of too much) can be almost as harmful as not-enough. How can I say that? After all, the results of not-enough are obvious, and well-documented in nasty project failure statistics, and well-understood by many of us from ghastly personal experiences. In my opinion, the dangers of truly-too-much and perceived-too-much must be dealt with proactively! And we as PMs must be aware of how our tools are being used and perceived, shoulder responsibility for adapting and selling our toolkit to those whose time we are affecting, and make sure we can see the project forest in the midst of all the process trees.

This subject should also matter to every executive who wants consistently good project performance across the organization. What if all that great process, intended to get you great project results, is not actually delivering what you expected? And for those of you thinking you need more/better processes to help with project discipline, read on for cautionary, but also encouraging, words about how to ultimately get it right.

Here is why I am more afraid of too much project management in an organization than not-enough:

Project processes and management techniques are supposed to be inherently good. They provide a framework and tools for pacing a team through a project to meet scope, time, cost, and quality goals. Without any tools and discipline, a project is more likely to go off track from those major goals.

However, too much project management in an environment can actually undermine the benefits the process was supposed to deliver.

  • It's all too easy for teams, and even the project managers themselves, to perceive that significant time is taken up in activities that don't necessarily add materially to the project's chances of success. PMs may experience the well-meant process as simply a bunch of big documents, signoff processes, project review meetings, and status reporting requirements. Teams see time spent creating detailed schedules for work filled with uncertainty, giving status and attending meetings, as something that keeps them away from doing "the real work." An overabundance of "project mechanics" can actually affect team morale. Things are busy and stressful enough; who wants to feel like we're wasting time on work that doesn't really help the project get done?
  • When the process is full of mandated sound and fury in the form of activities and documents and boxes to check, project managers, especially less experienced ones, can lose sight of the forest for the trees. A VP at a fast-growing tech company recently said to me that some PMs were getting so lost in their data collection and paperwork generation he felt they weren't seeing the big picture, asking the right questions, sitting back and surveying the landscape and asking themselves "what smells funny."

So why did I say above that I'm more afraid of too much project management in an environment than too little?

In the "too little" case, there are usually obvious issues (and lots of attendant pain from the resulting project blow-ups) - and therefore there's typically a willingness to listen to simple new approaches and "tools" that will help fix the issues and remove the pain. (Many an organization has been put onto a much better path simply by introducing project charters and attention to scope management!)

If I'm operating in a "too little" scenario, I can pull in what truly matters, the highest-leverage documents or meetings, use influence skills to make my case as to why they're worth the time, and build some trust and belief in the goodness of some process as I go. In the too-much scenario, when PMs and teams are already in resistance mode, I feel I actually have to work a lot harder to get the right attention to truly important project management activities.

In fact, it can turn out that reactions to "too much" in an organization cause a return to "too little", with a whole lot of bad attitude and resistance heaped on top! And it can actually be harder to recover back to just-enough, than to start from scratch in a messy "too-little" situation.

How "too much project management" or the perception there-of can manifest in a range of organizations and situations:

  • I know companies whose new process efforts tanked pretty quickly because of how the process was built and introduced – lots of "what" and "how" and not enough "why", such that the recipients of the new process perceived lots of new overhead and little understanding for their daily environment.
  • I've been in situations where a project process was A-OK until a new functional group was asked to come into the fold for the betterment of their projects – and promptly ran for the hills (ignored the process pretty totally) because it had not been built with them in mind – and therefore made no sense to them. They not only ran for the hills, they bad-mouthed the process to everyone in sight and caused some new PMs in other departments, who were just learning the ropes, to start questioning and backing away from the process as well. ("Hey, if these seasoned software people think it stinks, maybe it does!")
  • I've seen new project managers struggle mightily to get up to speed when there's an established process, because they just can't figure out WHAT MATTERS. They have a lot to take in at once, new techniques to learn, people skills, influence skills and here's this big mandated set of stuff to do. I've seen reactions all the way from rote box check off from the less confident ones to seat-of-the-pants managing by the more confident ones who would rather trust their intuition than figure out a book full of rules.

It's not just me.

A PM friend reported "My last company was fairly immature in their project management practices. The use of the processes really depended on the project teams. Some would do very well with making sure they had "just enough" process to help them. Others would not worry so much about process and did anything they could to bypass the governance structure. In these cases, when they did use the process it was essentially "going through the motions" with what they performed. The intent was totally lost on them."

Another colleague told me "Our development life-cycle is template and review based, resulting in all but the most experienced and mature PM's going through the motions and filing in templates and following step actions. To me it's a perfect example of building a methodology for the lowest common denominator, which as a result forces everyone to the lowest common denominator - unless they have the experience and maturity to  use it in a flexible way AND do the important things right."

Another said: "Though everyone in my tends to follow the processes in theory, I do think teams often do not understand the value of what they are doing and why it is being done. For instance, project test plans and checklists are sometimes looked at as corporate mandates, versus part of making the product better. And at PMI meetings, I often hear PMs complain about process overload." (On this example, just this week I hit a situation where a PM in a partner organization said "yes, we did that review, we're done!" [Check that box, please.] And the rest of the team, from the client company said, "Hmm, that's funny, guess none of us were invited.. kind of hard to have a thorough review that way!")

Because of all of the above, I truly believe that too much project management (or the perception there-of) can seriously hurt a company's overall effort to get more project-mature and successful across the board – so I think this subject is worthy of examination by all of us as we keep working to improve how projects get done in our organizations.

In my opinion, the goal of any process implementation and use in a company is to achieve effective teams operating with sound (not overly short-cut) value-add project discipline but without creating unnecessary work AKA dreaded project bureaucracy (that can waste time and also cause the baby to get thrown out with the bathwater.) There is a "just enough" level of process that will bring discipline and attention to the right aspects; help the team avoid mistakes, misunderstandings, forgotten work, etc.; and help the team make use of best practices - all without taking on unnecessary overhead for their situation.

Potential signs of "too much project management" from your people

Here are some of my favorite indicators of people experiencing or perceiving "too much" project management or the perception of too much. Watch for typical statements, body language, and actions that could indicate a lack of buy-in to the process and tools the project is using. Some behaviors may be more likely to occur as an organization is introducing project management for the first time and is trying to get more good project discipline in place – but I've seen them in places where project management has officially been "the way we do things" for over more than a couple of years, too!

  • Eye-rolls or smirks or grudging information sharing from team members especially in status meetings. Those looks and behaviors that say "why are we here, when is this going to be over" when a PM requests status or covers action items or covers "management stuff" that is not seen as part of the real work. In its extreme forms, this could even result in low attendance at team meetings, because to "our meetings are a time-waster."
  • Outright resistance from one or more people, such as continuing to not complete a deliverable, continuing to not finish certain tasks or action items. This can take the form of group-wide resistance as well, such as when a key functional group thinks the process doesn't apply to them and therefore does not do the deliverables or participate in meetings or reviews.
  • People are complaining that their tasks are running late because they've been slowed down by the required review, handoff, or signoff processes.
  • There is grumbling about any management activity that is perceived to "kill our creativity to come up with a solution", or be "demanding a commitment where we can't make one."
  • There is evidence that executives have lost sight of what the process was for. Typical signs include execs signing off on things they haven't read; not asking the right questions in major project review meetings (losing sight of the forest themselves!), or not attending the meetings at all; not supporting the use of key process elements by their own groups; and any other sign that they are not honoring the process they're forcing everyone else to use.
  • Some project managers are going through the motions, skipping deliverables or reviews that really ARE needed, too easily deciding that "we don't need that" because everyone's in a hurry, or because the project manager lacks the knowledge or confidence to stand up for what's needed to team members who are resisting.
  • The process is in fairly happy use on certain kinds of projects, but on others, it's non-existent or mostly ignored. Projects running with NO process in a process-environment can also occur because the process was originally built for one major type of project, or division, then spread to others and "it doesn't apply to the projects WE do."

Even if you're in an environment that is not particularly project management/process-phobic – are you sure there aren't a least a handful of people, or even one key person on your team, exhibiting some of the signs above? One person's attitude CAN affect the rest of the team, especially in time-crunched stressful situations. And of course, one person going through the motions on their own deliverables or reviews could cause something to get missed and result in a concrete problem for the entire project. So I tend to watch out for the signs above even if I don't feel like I'm fighting process battles every day overall.

So what to do if you're experiencing any of the above in your project environment? Here are a few ideas to help you achieve "just enough" project management in everyone's eyes. They're not all quick fixes, but they all deserve consideration.

Look for things that are (rightly or wrongly) causing perceptions of too much project management

What if you're pretty sure you are truly using (as the PM) or mandating (as the PMO head or project executive) only those project management deliverables, tools, and meetings that are absolutely justified — but some are still being resisted, skipped, or skimmed over by the team or by the project manager in charge?

When I talk about achieving "just enough," I believe that it has to be perceived as just enough by everyone, not just the people who've put the management/process expectations in place or otherwise bought into its goodness. So I've learned to pay attention to how the team and others are reacting to all the elements of how I manage a project, or the process I've asked a team to follow as the project executive.

(But first I'll also say, don't assume you're totally right too quickly. Many of us have been doing this so long, we've accepted the value of certain things so thoroughly, we may need a little practice looking with fresh eyes.)

Then, with an objective mindset, look back at the bullet list above. Go through each one and ask yourself: "Am I seeing this particular sign that people are experiencing "too much" management? If so are we actually spending more time than is really needed? (Too many meetings? Too many status requests? Duplicated status reporting? Too much time in schedule tool manipulation?) Or is our process out of whack for a particular group or project type?

Objectively examine what's going on and try to see things through the most process or management-phobic people you've got. Often there's at least a grain of truth to what they're seeing – and seeing it is the first step to solving the problems. Acknowledging the validity of their view and taking any action at all will get you even further – it's amazing how much "wall" a simple acknowledgement and first step can break down.

Deal with time-wasters and remove some pain

After awareness comes action. Once any of us has accepted the responsibility of monitoring the environment for signs of "too much", we have to be willing to do something about it. And we can!

A great first step is to attack any valid time-wasters you identified above. Remove work that is taking people's time out of proportion to the value for the time spent. Here are some examples:

Typical problem-causers - places where value not perceived for the time spent

  • Action item reviews in your team meetings. Do you really need to status each one in front of the group? Review each open one line by line?
  • Round-robin status in your team meetings. What about focusing on what has changed? What critical things people need from each other in the next week? Don't spend time in verbal dumps that could be accomplished offline with much more efficiency.
  • Having to create multiple forms of status for different groups. Is it really justified? What about negotiating a common format?
  • Having to report status so often or at such a fine granularity that it seems meaningless -- AND takes up people's time to give very detailed info over and over again. Use milestones, key dependency tracking, and completion tracking as better focal points, and figure out how to reduce the task statusing load.
  • Creating documentation that no one will ever read. Examine the "whys" of every document. Or find ways to make them lighter weight. More bullets? Less boilerplate? More, shorter documents that are easier to read and update?

Those are just a few ideas. Ask your team where they think time is being wasted.

Speak up and educate people: emphasize what matters, and why

Beyond the obvious quick fixes, be ready to explain and justify. If certain management activities, project documents, reviews, etc, really are needed, that value has to be sold. We just have to accept that this is part of our job. Just because we think something is valuable, and know exactly what that value is, not everyone else automatically will.

Here are examples of emphasizing the why's to deal with some of the problems listed above:

  • Executives or others turning meetings into off-target uncomfortable wastes of time. (e.g., by not asking any questions or exerting any leadership, or by asking the wrong kinds of questions, or going off-agenda….and in all cases taking the meeting to go down time-wasting rabbit-holes).

    The main why's of management review meetings are to float and get management help on big issues and to make big decisions on moving forward on projects as more time and money are about to be spent. So speak up for that. In one situation, an executive new to overseeing a more formal process, and with a lack of confidence in his new role, simply didn't get the role he needed to play. After a couple of bad meeting experiences, he was all too happy to chat over coffee about how to get what he needed from them – and went armed the next time with his list of the top 3 questions it was his job to ask about each project. The meeting went much faster, he got the info he needed, and he felt more confident in his new role.

    In other situations, the easy and powerful action is to do a "process check" – whether it's your meeting or not. Raise your hand, say "could we do a quick process (or agenda) check here? I know we wanted to get to X by end of this meeting (the "why" of this meeting!) and we're using up a lot of time. Is there something here we should table for outside discussion or action?" If you're miserable in a meeting, everyone else probably is too – but no one has had the gumption to bring it up. Be the one who does. Sound simplistic? It's simple, but not simplistic. I personally think that project management takes more "goodness" hits from bad meetings than any other source. We have incredible personal power to get rid of this source of trouble!
  • New project managers, especially those recently "anointed" from a functional role, floundering in applying all the management tools and techniques appropriately for their project. Sometimes the too-much issue results from a newer project manager not realizing that they can customize a process for the project. So they embark on requiring everything on the list, much to the chagrin of multiple people on their team. This is a place for quick real-world education and fast "cheat sheet" generation! Techniques I've used:
    • Hold lunch sessions where experienced project managers come talk about how they've run a recent or current project, with special focus on which aspects of the organization's process they used (and ones they didn't) and why.
    • Have an experienced PM participate in a new PM's kickoff meeting or early planning meeting, as the team decides how to structure and plan their project, to help them see how to customize on the fly... and feel more confident doing so.
    • Have a senior exec with a stake in the projects and the process make bald statements that the PMs are SUPPOSED to do the common sense thing and tailor the process. In one company I had the CTO come in at the beginning of every quarterly employee orientation workshop on "how we do projects here", and make the statement live and up close. (When he was out of town, I put up a slide quoting him. And his quote was on the front sheet on the process binder and templates website.)
    • Add cheat sheets to your process. Take one or two pages and summarize key deliverables, team members, and milestones a particular type of project should do Short software project? Here's all you need. Marketing campaign? Use this subset. Etc. These simple sheets of paper cause the most amazing reactions. "Oh. THAT's all it is? Oh, OK."
  • Team members that ignore or skim over reviews or important planning work because they perceive them as wastes of time or micromanagement.

    I like to nip this in the bud at the beginning of a project. I do sneaky "just in time" process selling in my team kickoff meetings especially if I think I have a resistant or new-to-project-management group. In my kickoff meetings I typically take the group through drafting some early deliverables such as a Vision/scope document, risk list, and team roles list. I start by not even referring to it as a document; I just get on the whiteboard or flipchart paper and start writing. "Let's figure out who we should have involved, who are we forgetting already?" "Let's jot down what we're already worried about, see how risky this is going to be." Then later, as part of actions going forward, I set actions for creating a risk list from what we just did on the board, and why we're bothering to write it down. "So I can go show management they're out of their minds, and get rid of some of these ASAP, and monitor the heck out of the rest until we get those risks removed or resolved."

    Past the kickoff, ad hoc issues with process-skipping may come up here and there during the project, due to a team member perceiving he's being hit with too much project management - too much paperwork, too many meetings, etc. It's my job to go make the rounds explain why I need a certain thing for the good of the project - not say "this is the way we do it, so give it to me..." I may have to negotiate; I may have to escalate; but frankly, if I feel like I owe each person the why, and sincerely give it, and work with them, I usually get what I need. Simple as that.

Pick your battles - Don't clutter the critical with the merely good that might not be needed

Very briefly, I highly recommend that any group define a set of minimum deliverables - the good common sense practices any project should do, even if they'll be used mostly as "thinking tools" for a small team rather than also needed as communication tools to a broad audience. Charter, team list, risk list, milestone list, key reviews. Voila - we've got a framework and key checkpoints and goal-alignment tools. Any project can build from there, if they need more. But start small. (Note to those of you with "too little" project management, wanting to get to just enough: a small set of high-leverage deliverables is a GREAT WAY to start.)

When you're working with a partner, or outside firm, or major vendor, don't be afraid to negotiate minimum some minimum process with them. I put it into the contract. Status reports, joint charter, certain reviews. I don't have to shove my process down their throat. But I should stand up for key elements I KNOW will matter for keeping us all together.

And if you have a recalcitrant internal group, or one that's being brought into the process for the first time, approach your efforts as "let's negotiate for mutual benefit," not "here's this mandated this list of stuff you have to start doing right now."

If it really is broken or inappropriate for certain groups or project types, then fix it.

In some cases, what's needed is a project to overhaul the documented process or update and amend it to make it more appropriate for the current resisters. Examples:

  • A process was originally created for a hardware-plus-embedded software product development group, but then the software group was asked to use the process for all software application and infrastructure projects. The process was so cluttered with "not applicable" tasks and documents, the software people refused to use any of it. The main process had to be revised to show key software reviews and deliverables, and overlays created to help apply lightweight versions of the process to small software-only projects.
  • A process was originally created for the regulatory-centric projects in an organization, but as the business and its project portfolio branches out to other areas, the heavy-weight process was seen as overkill for the new efforts - and the new projects ran ad hoc. One project team, after the project got in trouble for running ad hoc, sat down and defined an iterative approach to using key requirements and planning deliverables and reviews from the main process. They basically made up their own light version just-in-time, then later documented it as an addendum to help other such teams going forward.

If this is your situation, the best approach is to plan a background project - treated like a real (but simple, even informal) project, with a simple charter, team, milestone list, risk list, and completion criteria - to do the necessary process updates. Involve the people who have to use it. It will then be theirs, not yours.

Keep asking them whether THEY think we're doing too much or just-enough

I like to use multiple venues during the project to flush out actual or perceived "too much" on an ongoing basis.

  • During planning work: Ask the team in every planning meeting: "Have we accounted for all the work that needs to be done on this project, without going to too much task detail?
  • During execution: "How are we tracking progress to our schedule, and is there too much overhead doing it this way? Does anyone think we're taking up too much of their time? Is there a better way to get the true progress info we need?"
  • During status presentations and other meetings: Do we believe we overall have a good handle on this project and that we're using the right tools to run it, without going overboard? What could we change to manage ourselves more effectively? Are our meetings serving a good purpose, or is there stuff we should take offline? Any ways in which we need to be running better meetings?"
  • During regular check-ins with team members and sanity checks with the full team: "What is helping us get our work done, and what seems like just so much paperwork?"

Asking everyone doesn't mean that they'll always be right and yet more management activities and deliverables will get abandoned each time you ask their opinion! But one of these things should happen:

  • The team will decide the status quo is good, working, just-enough
  • The team will decide that something truly is "too much", and come up with ideas for moving it to just-enough together
  • The project manager and others will need to sell the value of an item as truly needed to someone who perceives it as too much.

A note for those who are current introducing project management to their organization.

I hope this article gives you a few important points for how to go about creating your approach to managing projects - your processes and expectations for managers and teams.

  • Start small, focusing on the highest-leverage areas of a process. A simple framework of major chunks of work with checkpoints. Key reviews. Some tools up front to make sure the goals are clearly defined and understood. Some simple tracking to help a team stay on track. A way to identify and manage risks. At every turn, ask, what risk, typical gotcha, need for input etc. am I trying to handle with the process? Focus on those "why's."
  • Don't neglect the "why" education. It's as important as writing down the "what" each team should do. If you don't impart the why's (the purpose of the process overall and specific pieces), the what's ) the deliverables, meetings, reviews, etc.) may get ignored or skimmed.
I'll close with a word picture of the team's role in helping create "just enough" The organizations whose project management succeeds broadly is likely to have gotten across this concept of just enough to the executives, managers, and team members alike. And furthermore, gotten everyone invested in achieving just-enough on each project. Here's my description of a team who has mastered the art of just-enough project management:
  • What individual team members exhibit: "I contribute my ideas of how to best use project management and other processes and "tools" on this project to ensure we're doing the right things and buy into and support the team's ultimate approach. I keep an eye out for ineffective practices and suggest how to best achieve a goal."
  • What the team exhibits: A confident and fully-accepted use of key project management tools for their particular project. An effective, fast-moving, adaptable team that uses project paper, and their time, wisely

Everyone takes responsibility for "just enough" Good project management is "ours" not "yours". People question the mandates with common sense, make good choices, use the tools effectively.

It's actually the best way for project processes to evolve in an organization over time. And for project managers, being known as a flexible, savvy, "just-enough" project manager will not only probably save you some paperwork and meeting time; it is also a great way to win friends, influence people, and build a great career.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

This is a well written article and I couldn't agree more. There really is a balance between too much and too little. A couple of points I would add:
1. If an organization desires to move up the maturity scale of CMMI, they need to have repeatable processes, however repeatable doesn't need to be draconian. Ideally there is a core process for most work, with a lite version for more routine work.
2. Larger mission critical projects tend to have additional and sometimes "too much" process added at the PMO level to allow project executives to govern and keep senior execs informed. A well thought out and balanced PMO process that is not "too much" is needed.

Thanks for the comment, Jeff. Great added points.

While I'm at it, I should make clear that I've been on both ends of this problem Earlier in my career as an engineer and then new line manager, I was one of the eye-rollers/ "get that paper outta my face" people. I slowly over time of course, even before my first time as a full-fledged PM, started to understand what at least some of it was for. But importantly, it was very formative experience to get to build by own PM approach bottoms up at the start-up where I was a Director of Engineering. Every activity or doc I added, i KNEW WHY... because I only added it after I had hit a real need - for a thinking tool, a communication tool, a review mechanism, etc.

Come to think of it, that could be a really cool way to teach new PMs the flexibility/ adaptability/ why stuff. We should give them more opportunity or requirements to give "building their own" a try, rather than pushing the pre-fab list at them with no discussion. :-)

Really good article - I too have worked in places where I needed to develop PM processes from scratch, and others with a large apparent process, templates, docs etc but PMs who thought the point of it all was to tick the boxes, not really use it with purpose. Will never forget asking about a PIR for a project on which I'd worked as lead analyst for 2 years, to find out the review had already been held, and as a special favour I could read some of the report!

Am currently struggling to implement Scrum methodology in a BAU support team, to much eye-rolling and lack of attendance at the daily meetings. I've seen Scrum used very successfully on projects, but in a BAU environment working on lots of small fixes to multiple different systems, it's feeling very much PM overkill. However Scrum has been mandated in the company so we must struggle on. Do you have any views on Scrum at this level?

Hi, MaryAnne, thanks for commenting. And great question. I've flagged an Agile colleague I suspected would have opinions on this, and I was right :-). He said he definitely had some thoughts for you and would post a comment tonight.

Thanks for the intro, Cinda!

Well, Mary Anne, it seems that you are experiencing the dysfunction that always attends to process mandates. It doesn’t matter if it is CMMI or Scrum; when the mandate comes down from on high, the box checking begins. It is sad when this happens with Agile methods because agility is supposed to be about adaptation and doing what is most effective to meet the customer’s needs. Sigh! (Heavy Variety)

The Agile methods were created for full-up software development. While they can work for other types of work (like BAU support), using them in such a way requires adaptation! Of course making the right adaptation choices requires that you understand what Agility is about in the first place.

Given your situation, I would recommend this sort of approach.

1) Get what I refer to as “Indoctrination” training for the BAU team (and possibly others as needed). This type of training, while it talks about the mechanics of the method you are using, is more focused on **WHY** we do those things. The value statements of the Agile Manifesto, the net results of the 12 Agile Principles, and other philosophical underpinnings are the main thing we want attendees to come away with!

2) If your BAU team is not doing a retrospective at the end of each Sprint, start doing this. (This is a “required” part of Scrum, so making it happen shouldn’t be too much of a stretch.)

3) Use the Retrospectives to start drilling into the things that make eyes roll. Why is this feeling like a waste of time? Is there a better way to achieve the Agile purpose of that activity? And most importantly, how shall we adapt that Agile practice to better serve the customer of this BAU team?

4) Start adapting Scrum for the needs of the BAU team. Try out an idea or two in each Sprint, then during the retrospective at its end, ask how they worked and if those adaptations should be kept. It won’t take too many Sprints before the most counter-productive Scrum practices have been tweaked into a form that works for this team.

If you have process police watching over your Scrum implementation, you will have to involve them in the process. And if they learn about adaptation along the way, that will be a very good thing!

If you want to explore this with me, you can contact me through my company website

Thanks Alan! MaryAnne, another of our contributors who has a lot of real-world Agile experience will be posting his thoughts tonight as well.

If anyone else out there reading this has thoughts, recommendations, or follow-on questions, hope you'll post!

Hi MaryAnne,
Many in the Scrum community like to proclaim that Scrum is not a project management approach, but actually a product development approach that was not intended for the finite end nature of projects. (I'm not saying I agree with that assessment, but I know it is a commonly held belief). With that in mind, there are some definite parallels between a product development environment where there is a Product Backlog with a dynamic list of features (as the team completes some features each Sprint, the Product Owner adds new ones) and your situation.

In your case, the Product Backlog is the list of fixes. You of course need to establish someone in the Product Owner role to make priority decisions about which fixes you work in each Sprint. Since you are working on multiple systems you may have to go with an approach where the individual owners of each system provides input into a designated decision maker (the de facto Product Owner) who balances business necessity (which fixes have the biggest impact on the business) along with technical effectiveness, such as grouping fixes for the same system into the same Sprint so that you have fewer releases to production.

I find your comment about implementing Scrum feeling like PM overkill interesting, as I have found Scrum to be one of the least intrusive methodologies out there. If you feel that following Scrum “by the book” (one of Ken Schwaber's)is too overbearing, I would suggest understanding what is the bare minimum is required to meet the mandate and then strive for that level. For example do the process police absolutely require that you have Daily Scrums? If not, you may chat with the team about the need to synch up daily. It may very well be the case that the nature of the work does not require a great deal of coordination between team members and you could meet every other day, or twice a week. Hopefully you are able to adapt the practices to suit your situation. If not, the folks mandating Scrum so strictly are doing your organization a disservice.

Many thanks for your comments Alan and Kent. Yes we have a list of fixes we used to call our Pipeline but renamed Product Backlog, and we've run Scrum training courses, and have rotated some of the team through full project teams using Scrum under experienced Scrum Masters. We have 4 business channels who prioritise their own work first, then we prioritise together for each release, and group work according to system where we can (theoretically we support only one system, but over the years various new interfaces in different technologies have been stuck on top so now a change to one can affect up to 8 others as well). I run retrospectives too but these are treated with some cynicism as the same issues come up each time, most outside our team's control e.g. resources allocated by their manager across too many pieces of work, unstable environments, requirements handed over by analysts who disappear onto other work, requests that are really too big for BAU stream but the owners don't want to pay the overhead of a PM from the PMO. I pass these up the chain but so far the silence has been quite deafening!

Our developers are all 20-30 year veterans, and have seen a lot of ideas come and go. They like to get a piece of work and be left to get on with it. Testers are much younger with different ideas though and the team dynamics can be rather 'interesting'.

I guess I can look at this as Scrum highlighting the process problems, as it's meant to do. One thing that surprised me though was team members seeming to think because we were having daily scrums, they didn't need to talk at other times. We're spread across 4 cities so communication is already more difficult. Several have complained that they don't get enough time to discuss issues during the daily meeting, and want a weekly meeting without the 3 questions.

Thanks again for your ideas, and the encouragement to try some adaptations. It's great to get some feedback.

I have a simular problem. In an BAU environment - enterprise system with lots of tech debt we are running scrum and fixing bugs. The problem is when it comes to planning and finishing the work. In more cases the defect will not be developed and tested within a sprint. We tend to do 3 week dev, 3 week test. Where we can break down we do but we find that there is more work involved in breaking down and deploying than sending time doing the work. The other issue is that in planning; that until the devs go through the code they are unsure on realistic points as they simply do not know. using past experinces is also difficult as they system is so convoluted. Any ideas

Hi Garry,
There are a couple of things I would suggest. One is to consider the duration of your iterations. If you find that it seems counter-productive to break your work down into say 2 or 3 week chunks, you could look at 4 - 6 week time boxes, if that provides your delivery team sufficient time to deliver things of value (in your case reduced technical debt) and that is not too long of a time for your stakeholders to wait for changes.

Another alternative is to consider trying a different approach. There is an approach inspired by lean thinking, known as Kanban, which may provide a more appropriate means for your delivery team to manage its work. The Kanban approach treats work as a continuous flow instead of trying to group work in iteration based groupings.

The key thing is to find an approach that works for your particular situation, not stick an approach because it is the in thing. I hope your organization adopted Scrum in search of specific benefits instead of applying Scrum so that you can say you are applying Scrum. Think about what those benefits should be (clearing up your technical debt as effectively and efficiently as possible may very well be your focus)and find an approach that will help you realize those benefits.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.