Great points, thanks for adding to the discussion.

this post is rather old. Still I would like to make some comments.

You describe the feeling of the time ticking and the backlog that has to be worked off.

Sure, this is somewhat true. However, the team decides on what goes into the backlog
and, hence, has a great influence on what they can achieve during the sprint. At the beginning of a new team starting out this might not be very accurate. This might result in stress if the team pulled too much into the sprint. Over time however, prediction gets better and the team
gets more confident.

Not having time to refactor is a problem the team has to take care of. It should be able to articulate the problem of not doing needed refactorings to the product owner (PO). In the end
refactorings should be put into the sprint as usual work and should be done regularly. For the PO the result of not having refactorings should be pretty clear as it will surely result in decreased pace.

To avoid having no playtime at all some companies go for the concept of slack. Whenever there is some time that you wait or have nothing to do, use it to learn and explore. This time can also be directly subtracted from the capacity for a fixed amount of slack each sprint.

Cheers,
Sebastian

I also think Big Up Front Design is a horrible idea, (Architecture up front, not so horrible), but I’ve also seen Agile teams devolve into “lawyering your customers to death” as you put it in another blog post (or at least lawyering your Product Owner and your own teammates to death).

“We need to take this User Story, and break it up into 3 separate user stories and reconvene the team to give estimates for each of them.” When the User Story in question already has ample detail to just get the work done.

Although cross-communication is good and silos are bad, too much emphasis on shared code ownership, such as when each developer always draws the next highest priority work item off of the backlog, can sometimes kill my personal sense of accomplishment, as compared to when team member are allowed to at least partially stay focused on specific areas.

I’ve found pair programming to be about as effective as running a three-legged race, and if not being allowed to focus on a code area diminishes one’s sense of accomplishment, pair programming kills it utterly. Also, I feel that pairing might help reduce foolish defects when working on simple-to-medium challenging features, but that I’m completely unable to devise solutions to really tough problems … until immediately after the pairing session ends.

And if you don’t have any idea what you’ll be working on in the future, and you’re not allowed to focus on even a medium-term feature to work on for more than a few days, why not bounce to some other job the moment the urge strikes you?

But even the heavily Waterfally team realized that we were far better off to get our software out in front of stakeholders regularly, to get their feedback.

If I were choosing, I would definitely prefer a hybrid approach.

With the non-Agile freedom I have enjoyed over the years, I have been able to undertake proper R&D and create not only good technical solutions, but add features to applications that greatly enhanced the end-user experience. This could never happen in an Agile world.

Although Agile development is efficient, there is more to life that efficiences. An individual, organization, or country requires creativity to grow. Innovation does not happen in an Agile world, just the constant drum of widgets being produced.

Whether you enjoy Agile development depends on the programmer. The more creative ones likely shy away from Agile, whereas those who prefer stability tend to Agile development. The problem is that many shops have both types of programmers, and in fact need both types. So, how to keep both happy.

I advocate a combination of both Agile and non-Agile development. We can call Agile development ‘bread and butter’ development, that pays the bills. Non-Agile development makes me want to go to work each day. This is the same concept with artists and scientists. Artists must create sellable ‘art’ which is not overly creative, to pay the bills and allow them to truly experiment. Science is the same. Scientists must perform the research necessary to crank out papers, to keep the funding coming. Outside of their ‘bread and butter’ research they often work on their more interesting research.

Sometimes we need a little bit of ‘bread and butter’ to go along with our creativity.

had exactly the same thing in my last agile run project.
the biggest drain was the continual pair programming which wouldnt let you do your little breaks like checking out reddit and so on.

Good point, Bruce. That makes sense. I imagine developer would feel more free and less restricted if they are selecting the backlogs and the pressure of committing to a time period is absolved. In my next post, I plan on talking about an idea of using bidding to allow developers to bid on items they would like to get done, so that they have more part in determining what gets worked on.