Too Much Meeting and Discussion, Not Enough Coding

Hey Mike,
I just finished enjoying the excellent webinar that you hosted today.
My team has been tasked with being the first team to go through our company’s transition to 100% Scrum environment and have been through our first two sprints. So far, my experience has been that we seem to spend way more time in meetings/discussion than in the past and even though we now break our projects down into smaller tasks, we don’t seem to be doing as much coding as before so I am doubting the ability of this environment to actually meet our company’s intended goal of speeding up software development.
Is this just because we are starting out and learning the ropes or is this typical for those transitioning from a waterfall development cycle to Scrum?

Thank you for taking the time to respond as I will be sharing your answer with our entire team.

Thank you for the kind words and interesting topic. I will attempt to be helpful while avoiding a direct answer that may be based on false assumptions.

Too Much Discussion

Does the team feel the discussions have been pointless quibbling, or overdue productive dialogue?

Does the team feel there is a teamwork issue at the core of this? According to Bruce Tuckman and others, teams go through stages of “forming, storming, norming, and performing.” Some managers try too hard to prevent or mediate conflict, preventing the team from moving through the necessary storming.  The Sprint Retrospective Meeting is one opportunity for the team to address this.  I like going to a different location for the Sprint Retrospective.  Try some of the techniques in Agile Retrospectives such as starting with a few minutes of silent writing.

If a team wants help reducing off-topic discussions, try a big visible countdown timer to remind everyone about the meeting timeboxes. (I travel with a Kagan MegaTimer, but the UI’s a bit annoying. A mechanical kitchen timer would probably be better.) I give participants squeaky rats to make it clear it’s everyone’s responsibility to interrupt sidebars. The ScrumMaster or someone else can write a list of sidebar topics on the markerboard for whoever’s interested in staying for those discussions.

Not Enough Coding

As you may know, the measurement Scrum/XP teams typically use is “velocity” — the rate of delivering done/done/done potentially-shippable (properly tested) PBIs, considering their size. Another flavor of velocity is Ron Jeffries’ “Running Tested Features”, based on the idea we should break all features down small enough to ignore size differences.

Velocity has a complicated relationship to time spent coding (and source lines of code). While there’s no velocity without enough time coding, coding without collaboration can lower velocity (today, or next year). Untested code, and code that’s not aligned with Sprint Goals, is the kind of inventory we’re typically trying to reduce.

Jerry Weinberg, the ultimate software effectiveness coach, tells a story about a manager who told Jerry he had discovered a way to tell which programmers were any good:  The manager watched programmers through the window to see which ones stayed at their terminals, and which ones got up to talk to other people. Jerry was impressed with the manager’s wisdom until he realized the manager thought the ones who didn’t collaborate were the good ones!

Here’s a Scrum team that collaborates the way I expect: .  (The tall guy is their coach, Tobias Mayer.)  While they’re typing code less than 100% of the time, my experience with this manner of work gives me the impression the code they do write is well crafted, and aligned with their Sprint Goals.

Agile approaches should increase velocity, but the main benefit is the ability to steer along the way, in the face of changing requirements and unpredictable technology risks.

So the reduced amount of coding could be good, or it could be bad, and this is a great question to ask the team.

I hope some part of this response has been helpful even though I didn’t answer your question. As I said in the webinar, if we’re not impressed by the Scrum team after 3-4 Sprints there’s likely to be something wrong with the way we set things up.


Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
4 comments on “Too Much Meeting and Discussion, Not Enough Coding
  1. Chuck van der Linden says:

    I’m my experience “less talking more coding” gives only the illusion of more productivity and speed. The illusion is usually shattered when the produced code meets the acceptance tests (or the costumer) and you find out you’ve not built the right thing and the acceptance tests don’t pass, or the customer is dissatisfied with what you’ve produced.

    The result ends up being a lot of wasted effort and re-work meaning lots of that time spend coding was simply lost end the end.

    What you need is enough focussed discussion to ensure that you are doing the right thing, that assumptions are correct etc..

    I’d also challenge the idea that a primary goal of implementing scrum is to develop software faster. If that’s your primary focus I think you are overlooking a lot of the other reasons to use scrum (greater agility, ability to learn and improve (the process and the product) via feedback, delivering the highest value features first, and a bunch of other reasons that would take several entire blog posts (or say a good book on scrum) to elaborate.

    I think the key takeaway for the letter writer ought to be that delivering the wrong thing fast, is ultimately not faster than taking a bit more time to make sure you build the right thing in the first place.

  2. Jussi Mononen says:

    I agree with Chuck that the Scrum process is not aimed at maximizing the teams output, but to minimize waste. We don’t want to spend time supporting code that does not benefit the customer or does not create revenue. 20% of the features bring in 80% of the profit. Weed out the unnecessary features, focus on customers problem domain and stay steer toward the customer needs as they big picture gets clearer.

  3. Victor Szalvay says:

    I’m in agreement with Michael and Chuck. Another way to think about it is from a “lean-thinking” perspective: optimize the whole, and don’t worry about any particular activity (the coding part).

    I’ve seen organizations where the technical group was divorced from the business/marketing side. The technical group produced a bunch of stuff, but it wasn’t really focused on the company’s business goals. One of the huge benefits of Scrum is bringing business and technical together to create valuable technical products.

    If you end up coding less and meeting more, sobeit. In my experience, the “meeting more” part will start to get less and less as you get used to working in this fashion. But I’d view the increased collaboration as a huge positive.

    Aside: I disagree a bit with Jussi in that (imo) Scrum isn’t about reducing waste. It’s about optimizing around over-arching business goals, rather than local considerations like coding, architecture, or similar in-process artifacts.

    Great discussion.

  4. Jussi Mononen says:

    I meant that one aspect of Scrum is to eliminate waste as an opposite of maximizing output. It’s about different things than just getting more things “done”. By eliminating waste you reduce future work, create smaller things that still are sufficient for their purpose. Eliminating waste forces you to think the ways you work.

    Scrum as a whole is of course much broader approach towards the whole process of making things better.

Leave a Reply

Your email address will not be published. Required fields are marked *