Disciplined Agile Applied

I just thought I would kick off this blog with a traditional "Hello, World!" posting describing my vision.  My goal is to share agile and lean strategies, concepts, and ideas for people working in enterprise-class settings.  There's a lot written about agile and lean for small startup organizations, which is great, but I never get to work in those sorts of situations.  I tend to work for large, establish organizations that have existing cultures, existing ways of working (WoW), and legacy systems galore.  The challenging environments that most of you are working in too.

Luckily there is a wealth of material in the Disciplined Agile (DA) toolkit to draw from and it's constantly evolving.  Sometimes I will write about fundamentals, my next blog posting will be a brief overview of DA, sometimes I will write about how to apply existing techniques in an agile or lean manner, and sometimes I'll write about techniques that are brand new to you.

I'd like to share my philosophies regarding process so that you have a better understanding of my overall approach:

1. There are no best practices.  Every practice or technique is contextual in nature.  They have strengths and weaknesses, they work well in some situations and they don't work well in others.  For over thirty years now I have been actively searching for a best practice and have yet to find one.  I've run into a lot things marketed as "best practices" but have never found one that works well in all situations nor one that doesn't have some drawbacks to it.  But I will continue looking.
2. You need to experiment.  Just because a strategy worked well for someone else in a similar situation to yours doesn't guarantee that it will work for you.  You still need to try it in your environment, observe the effects, and then act accordingly. 
3. Theory is great, but experience is better. Don't get me wrong, I'm a firm believer in theory and read avidly.  But I strive to see strategies applied in practice, and better yet to apply those strategies myself. I'm constantly looking for new ways of working (WoW) to share with others, but to do so usefully I want to first understand the practicalities of a given technique.
4. When someone tells you something can't be done, what they're really saying is they don't know how to do it.  I often run into people who say "Agile is great, but it won't in my situation."  I've never actually run into a situation where agile wouldn't work, and I've been doing this for a long time in a wide range of environments.  I have run into situations where a traditional (sometimes called predictive, see my next point) strategy makes more sense than an agile approach.  Fair enough.  Traditional strategies have their strengths and weaknesses too. Our advice is always to do the best that you can in the situation that you face, so if a traditional strategy is the best fit for your situation go for it. 
5. "Predictive strategies" generally aren't.  This statement will likely get me into trouble, but that's arguably my natural state.  The fifth value of the Disciplined Agile Manifesto is "Transparency over (false) predictability." The basic idea is that it's more important to provide transparency into what is happening and to provide realistic projections based on actuals. Yes, you'll often be asked to provide cost and schedule estimates, and even make good guesses around the scope of your effort so that senior management can make fundamental investment decisions.  And there's a range of techniques to do these very things that we cover in the Disciplined Agile toolkit. But we need to remember that agile/lean operates under a different mindset than traditional. We've found that in most situations it's better to focus on investing wisely, on getting good value, rather than focusing on coming in on or under budget.  We've found that in most situations it's better to focus on delivering something when it's needed and ready rather than focusing on coming in on schedule.  We've found that in most situations it's far more important to allow requirements to evolve than it is to build to spec.  Notice how I've used the term "in most situations" a lot?  Remember, there are no best practices.  So you may be in  a situation where one or more of coming in on budget, coming in on time, or building to spec are actually critical.  Those situations are rare in practice, assuming you're in an environment where you're allowed and able to have honest conversations about such issues, but they do occur.  Discipline Agilists prefer to focus on transparency because it enables better governance and better decision making.  But this is a pretty big concept which I will share in coming blog postings (and I'll back up my assertions with industry data too).
6. Failing fast is fine, succeeding fast is better. There's a lot of rhetoric in the agile community about failing fast, which is clearly better than failing slowly and expensively.  But we'd rather succeed fast.  You can do this by leveraging the knowledge in the DA toolkit to identify techniques to experiment with that are most likely going to work in the situation that you face.  This is a technique we call Guided Continuous Improvement (GCI).
7. I'm still learning too. One of the things that impresses me about PMI and our membership is the wealth of knowledge and experience people have. I'm looking forward to great conversations. 
8. Please bring me hard problems. Given point #4, I would love to hear about situations where you think agile strategies won't work.  Those are always interesting conversations for me, I hope that I'll be able to help you, and I suspect the conversation will provide great fodder for a blog posting.  Let's see how it plays out!

It's going to be a fun and interesting ride.  So hello world!