Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Nov 20, 2009 — Enterprise Agile Planning expert

Too Much Meeting and Discussion, Not Enough Coding

Enterprise Agile Planning

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.


More from the Blog

View more
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us