• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

"Better than not doing it" results

 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Learning Agile" uses the phrase "better than not doing it" a lot. I think a lot of "agile" teams are stuck there. Doing some agile practices, thinking they are doing agile and not getting the full benefits.

This seems like a good discussion topic - how do you recognize such a team? How do you improve things?
 
Author
Posts: 81
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm actually really interested to hear from people who are getting what we call "better-than-not-doing-it" results. Here's how we describe it in Learning Agile:

It’s not uncommon for team members, and especially team leads, to feel ... a little disappointed after their first attempt at agile adoption. The blogs and books they’ve read and the training they’ve attended talked about “astonishing results” and “hyper-productive teams.” This team feels like the jukebox project is an improvement on their previous projects, but they definitely don’t feel “hyper- productive,” and nobody’s really been astonished at the results.
There’s a general feeling that the project has gone from dysfunctional to functional, and that’s very good. They’ve gotten what we like to call better-than-not-doing-it results. But is this really all there is to agile?



Jenny and I interviewed many developers, team members, managers, etc., over the years, and we've found that a lot of people feel this way -- that their adoption of Scrum, XP, or another agile method or methodology is somehow a little "empty", like they're going through the motions. It's worth doing, and they're getting results, but it doesn't seem worth the hype.

There's so much more to agile than better-than-not-doing-it results, and a lot of the book (and a lot of what we focus on in our own careers) is about how to get there.

Is this a familiar feeling to people here?

Andrew
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Andrew Stellman wrote:Is this a familiar feeling to people here?


Abso-tootin'-lutely.

The question is, how do you respond? Do you shrug and keep going about your business or step up your efforts and keep striving to get better?

There are many things that influence the answer to this, some internal and some external to each team member and to the team as a whole. The things that you can control both as a team and individually are discipline, commitment, and hard work - how much of these you put in helps determine how much you'll get out of it.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another thing too is that many teams whose agile practice has stagnated or plateaued seem to have "settled in" to their new way of doing things. They'll often see Agile as the collection of practices rather than as the attitude, mindset, and way of being that is supported and enabled by the practices. The Agile mindset is eager to learn, always looking for ways to get better, and open to new possibilities. When you make Storming, Forming, and Norming linear then there's a risk of Stagnating. You have to shake things up a bit once in a while so that the team can find new ways to grow and improve.

Great question, BTW; deserves a cow.
 
Andrew Stellman
Author
Posts: 81
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We spend a lot of the book on this, helping people balance practices, principles, mindset, and attitude in the real world. One thing we've seen over and over again is that team members cab learn a lot about how to improve their mindset by looking at the practices that they skip or half-ass. I saw a question about skipping code reviews posted. This is a big indication that the poster is on a team where the attitude or mindset is probably not compatible with doing code reviews -- the people on the team don't really believe that they're valuable. A lot of programmers feel that way about anything that isn't code. This attitude leads to an adoption that gets some results, but still feels "empty" -- what we call better-than-not-doing-it results.

Luckily, agile has an answer: the Agile Manifesto, its principles, and the values and principles of methodologies like Scrum and XP. They help your team get into the right mindset. They also tend to get skipped by people who are rushing right to the practices. There's a lot to them, though, and we spend a lot of tome on thin in our book because they can make the difference between an empty, better-than-not-doing-it result and a truly astonishing one
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Andrew Stellman wrote:One thing we've seen over and over again is that team members cab learn a lot about how to improve their mindset by looking at the practices that they skip or half-ass.


There can be a Catch-22 situation there though: since they skip or half-ass these practices, they probably don't really care about these as much so there's less chance that they'll look at them. One thing that I used to see a lot was the so-called Agile Spider Chart -- not sure if it's still popular but I thought it was quite useful in getting teams to realize when there were still things in their practice that they could improve.
 
reply
    Bookmark Topic Watch Topic
  • New Topic