Embrace Pain

Agile is about surfacing pain. It’s not about roses, perfume, and happy candlelight dinners together. Traditional project management methodologies made it easy to sweep the pain under the carpet, lying about how you were doing up until the end of the project, when you hoped everything would just go away emerged to haunt or kill you. Traditional project management methodologies are all about denial. Why do predictive methodology plans fail so often? The release plan correctly goes out of alignment with the reality. A task overruns, a task underruns, a dependency holds up delivery. Sometimes people re-plan, but the effort mean most just ignore it, burying technical debt to stay on track, ignoring opportunities to take on more work, lying to their stakeholders about where they really are. Agile uses an adaptive approach, because that allows you to surface the truth about when and where things are failing, or where there are opportunites that could be exploited.

Being agile hurts. It exposes you before your peers with all your insecurities, wounds, failures and weaknesses. But accepting those problems lets you take steps to fix them.

So if you think you are an agile project and you are not constantly surfacing nasty, miserable pain, then you might not be doing it right.

What are generally called agile development processes are best practices for fixing the pain that agile can surface, without creating more pain in turn. Now Scrum  gets a lot of ragging for not including engineering processes. But I think that the point here though is that heart of Agile is about the surfacing of those problems, not the fixing of them. We want to fix them, and you may want to go to your XP, Crystal or Scrum library and pull out remedies for your pain from those cupboards. You might even want to vaccinate your project from them. These engineering processes are in important part of your methodology, but they are a response to the pain that agile surfaces. You do continuous integration because you don’t want the pain of integrating code streams after days of effort, or taking several days to do the build.

The key to agile is that you are bringing down the pain. Because then you can deal with it.

I suspect that the reason a lot of Scrum implementations seem to be failing is because the attitude of those using them is to hide the pain, not to surface it. That is self-defeating, but emerges because the stakeholders of the organization become scared when they see so much pain early in a project’s lifecycle. They are not used to that level of honesty. So they think something must be wrong. In fact something is terribly right. However,  you have to set expectations to understand that you intend to bring down the pain so that you won’t be finding it all when its too late or too expensive to do anything about it.

Everything always done , every sprint always 100%, no defects? These are often lies we tell ourselves to defer the day of reckoning. Maybe you’re getting it right, but don’t lie to make it look like success, because it isn’t.

About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group. http://www.dnug.org.uk
This entry was posted in Agile, SCRUM, XP. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.symptomspanicattacks.com symptoms panic attack

    I really liked your blog! You have some great content. Check out my blog and give me some feedback Please come visit my site cure panic attacks when you got time.

  • http://www.plasticsurgerybefore.com hemolytic uremic syndrome

    It is very interesting article and quite impressive and more informative and looking forward to read such article. Please come visit my site atypical hemolytic uremic syndrome when you got time.

  • http://www.managementweight.com weight loss management

    I usually don’t leave comments!!! Trust me! But I liked your blog…especially this post! Would you mind terribly if I put up a backlink from my site to your site? I would love some feedback on my site weight loss programs when you got time.

  • http://www.piercingtattooing.com body piercing

    Wow! Thank you! I always wanted to write in my site something like that. Can I take part of your post to my blog? Please come visit my site when you got time.

  • http://xsrizoau.com/ Nuoevcpi


  • http://tpwaflkq.com/ Fblictmz


  • http://curycrob.com/ Amuhbijm


  • http://www.homescarenursing.com nursing homes

    You may have not intended to do so, but I think you have managed to express the state of mind that a lot of people are in. The sense of wanting to help, but not knowing how or where, is something a lot of us are going through. Please come visit my site skilled nursing facility and give me any valuable feedbacks.

  • http://www.patrolsecurityguard.com security companies

    I was thinking of looking up some of them newspaper websites, but am glad I came here instead. Although glad is not quite the right word… let me just say I needed this after the incessant chatter in the media, and am grateful to you for articulating something many of us are feeling – even from distant shores. Please come visit my site private investigators when you got time.

  • http://fyeoacgs.com/ Ravrmyvi


  • http://codebetter.com/members/Ian-Cooper/default.aspx Ian Cooper

    @Gal I don’t think that is a feature of agile. Scott Bellware has a good post on the misunderstanding around Big Design Up Front on his blog (http://blog.scottbellware.com/2009/07/problem-with-big-design-up-front-is-big.html)

    Agile enginerring processes tend to want to do ‘design all the time’. It is why we have whole team meetings in iteration planning to discuss engineering tasks, because we are doing planning. It is why tackling a story tends to be often start with a whiteboard or CRC card session. It is why teams support automated tests to enable incremental re-architecture.

    If you are not seeing design changes happening within an iteration, and you are building up technical debt then that pain is something you should work on. But its not a feature of agile processes.

  • http://galratner.com Gal

    The biggest drawback as far as development is concerned with agile is the fact that code design and implementation is almost never properly planned beyond two or three iterations. Sure, you can put on paper your entire system for the sake of planning iterations, however, chances are that business requirements will sometimes slightly change during the development lifetime, and this will most likely require some refactoring. Since in agile, refactoring is always kept to a minimum, patches are usually applied to mask the real design problems. This causes problems to accumulate as a result of near sighting from developers and architects.
    If you take the time to stop and think about a system’s design DURING development, and not just before you start, you can allow some time for refactoring. Your system will look and operate better and your team’s life will be much easier, especially, when revisiting the system in the future. Your pain will all but disappear if you just think of the big picture as well as the details in your daily meetings.

  • http://twitter.com/lamapper lamapper

    As a Manager I never cut off the heads of my direct reports when a problem occurred or a mistake was made; thus they could safely make mistakes, learn from them and move on. I often learn more from my mistakes than from my successes. They frequently shared the same thoughts with me.

    Sadly there are still people out there that should NOT be managers who are put in charge for all the wrong reasons: money, power, control. Perhaps it is the fear of having their head loped off, fired, terminated; especially in this economy, that causes developers to attempt to hide (in vain if the manager is competent) mistakes and problems.

    It is always better to let the problems become exposed for the benefit of the developers, the products and the company. But only if as a developer you feel it is okay to make a mistake.

    With Agile, mistakes and problems are uncovered early in the development and corrections can be made, huge plus for Agile over traditional methods of project / product management.

    Pain is fine, but continual pain, I do not agree with that. That would imply to me that an unnecessary amount of pressure is being applied for the wrong reasons. Perhaps your velocity is too aggressive and you are expecting too much out of each iteration. If your velocity is too high, your burn-out rate will be also.

    The same Mgmt shortcomings that led to more work being planned than can be accomplished do not magically go away when you move to an Agile/Scrum methodology. Most companies do not look at “turn-over” as a measure of a successful manager, they should.

    Remember you want a sustainable velocity!

    Sustainable for a working father or mother who has a life outside of the office. Even single workers need a life outside of the office to be considered well rounded and functional human beings.

    Burned out workers can not ultimately succeed no matter what processes you follow, traditional RUP/Waterfall, Extreme Programming or Agile/Scrum.

  • http://www.ZedBuildsAndBugs.com/ Mr. Hericus

    Bringing down the pain :-) I like that way of putting it. Of course it could have two meanings, but I’ll take the better of the two.

    Continuous Integration _is_ about reducing the pain of that end-of-the-week build that takes so long it bleeds into the following week. Build managers everywhere are loving the approach and getting more productive things done than chasing down build errors.

    Thanks for the post!

    Mr. Hericus