Plunge In or Dip Your Toe? (for Projects)

I've been teaching a variety of workshops recently, some of which are Scrum. One of the questions people have is: Can we do this partway?

No, not Scrum or any other agile lifecycle. You either do it all or you're not doing agile.

You can work in timeboxed iterations. But if you haven't gotten to done at the end of the timebox, it's not agile. If you don't do retrospectives, you're not doing agile  (I don't see how you can improve for the next iteration if you don't look back at this most recent iteration). If you have to have an entire iteration (or two or three) of just architecture, with no working product, it's not agile.

Timeboxes are helpful to people. But just timeboxes don't make a lifecycle Scrum (or any other agile lifecycle). One group asked me “What if we keep the requirements and architecture phases? Then move into timeboxes where we get to done? Is that Scrum?” No, it's quite a useful incremental lifecycle. But it's not agile.

I understand why people would prefer to dip their toes instead of plunge in. If you've got an organization set up to do phased development and everyone is judged on their ability to meet their phase deliverables, it's pretty darn scary. Especially if you don't have automated tests and you have a legacy product. How can you tell you're done at the end of a timebox?

The problem is that agile won't solve these problems unless you put them on the product backlog or remove them as obstacles. Agile makes them visible.

For a project team, plunge in. Or, decide not yet. But don't dip your toe and not commit to really being agile. You're setting yourself up for complaining later.

(Added later because Joe was confused) Plunge in all the way. Go to agile. Commit to it. Or, commit to an incremental lifecycle. Commit to something. And, call it what it is. Don't call it agile if it's not, and then complain later that it doesn't work. Don't call it incremental if you don't finish features, as in done-done-done. Know what you want to do, commit to it, and then evaluate your progress or success. (Is that better, Joe?)

12 thoughts on “Plunge In or Dip Your Toe? (for Projects)”

  1. You say

    “Is that Scrum?” No, it’s quite a useful incremental lifecycle

    and then

    Don’t dip your toe and not commit to really being agile.

    So, which is it? “Quite useful” or something that shouldn’t be done?

    I personally vote for the former, and would say: “If you’re only sorta-agile and encounter problems, it’s unfair to blame the process you partly-implemented.”

  2. I listened to podcast recently that discussed how to introduce change into your organisation or any aspect of your life actually. (

    Amongst other things, introducing Agile was discussed. Linda Rising would apparently disagree somewhat with what you’ve written here in that it can help to introduce Agile, using Agile.

    That is take a few small steps, assess how it went, go around again. I can’t agree that it has to be all or nothing, just to be called Agile, when Agile is not really defined strictly enough to necessarily even know when you’ve properly taken the plunge.

    In fact I don’t think you can ever say you’ve completely taken the plunge because you should always be assessing and changing, iteratively.

    (Thanks for the blog, nice work.)

  3. Please allow me explain myself better.

    I read both your blogs (as well as your articles elsewhere). I have read three of your books and will be buying “Manage Your Project Portfolio” when it is published.

    I am not someone here to troll or nay-say; I am here to learn and I think it was fair of me to ask for clarification.

    That said, my point is this:

    A lot of XP, Agile, SCRUM, etc. folks seem to broadcast the message “it’s all or nothing” and I think this discourages new people from adopting their good practices.

    If, for example, some mid-level programmer wants to improve their company’s sub-par development process and proposes “Hey, guys, let’s try daily stand-up meetings,” I think we should praise and encourage them and not be overly concerned that it’s not “real” SCRUM nor (ATTN: Dwayne) mock them as cowards.

  4. Pingback: سیاره مدیریت پروژه فارسی » Blog Archive » Small Steps Are Good; Be Careful What You Call Those Steps

  5. I have slightly mixed feelings about this post, but I DO believe there are definitely parts of agile that – if done in isolation – can actualy work against what we’re trying to do with agile.

    I’m so sorry to pick on your example, Joe, but Daily standups are actually a great example of a practice that can turn out very badly if done without some of the other key agile things like working against a prioritized backlog and having the team work together in a self-organized fashion.

    But, meetings look easy to managers so I’ve been on multiple non-agile projects where – after being asked to get more agile – the manager has reluctantly agreed “okay, we’ll try these daily standup things to start with.”

    The problem is that trying to have a 15 minute meeting where the team checks in with one another on their commitments is next to impossible when it really isn’t quite clear WHAT people should be working on (just the next most urgent thing!) and when the team isn’t even necessarily working TOGETHER (just each off fighting their own fire).

    A couple problems occur – first, if they’re not working together, nobody really cares about anyone else’s updates because they’re too busy with their own problems so it’s not clear who – beyond the manager – is gaining anything from the meeting. Second, the meetings stretch out way more than 15 minutes when their aren’t clear tasks to report against and I’ve seen this turn into daily 1 hour long status meetings which are the most painful things in the world – make the team less effective (huge waste of time) and give them a very poor view of agile, pretty much guaranteeing they will fight further attempts at it tooth & nail.

  6. Pingback: The Rules For The Rules Of Engagement — Project Shrink

  7. Ed Richardson

    I agree with the premise of your post.

    It’s either Scrum or it’s not, you either fully commit to a methodology or you don’t.

    What I’m not so sure about is the possible alienation if you don’t fully commit.

    I don’t see any issue with taking elements of any methodology and working them into your bespoke project delivery process, perhaps on a project by project case.

    The aim of all project methodologies is to assist with the delivery of successful projects.

    Project success is usually graded on delivering a project on time and to budget, meeting the specifications defined by both client/sponsor and project team.

    If in order to achieve this result the project manager decides it’s appropriate to use elements of one methodology and other self devised elements, then so be it, as long as it helps achieve the final goal.

    There is currently an obsession with classification, whether it be music or project methodology.

    What everyone should be focusing on instead is the quality/effectiveness of the delivery and end the product.

    After moving from the IT industry (now obsessed with classification) to the Digital Media industry I am alarmed at the number of agencies that are stating they always deliver using Prince2 methodologies.

    Firstly I am not sure that Prince2 is the best methodology to deliver flexible products to 3rd parties such as websites and on-line campaigns.

    Secondly I fear half of this is just to reassure clients who need to hear a classification of a methodology, without really understanding what that means. It’s a blind faith reassurance. Misguided and inappropriate.

    All methodologies have their place and work well when used appropriately. But if you want to use elements from one and decide other elements to use yourself, then do so.

    Don’t call it Scrum or Agile, you can call it what you like, call it Ed’s methodology if you like.

    But ensure you keep the process transparent, define your objectives and keep your targets realistic and achievable.

    Let’s not obsess with names so much, instead lets focus on delivery.

    I’m going to write some more about this sometime soon when I find some down time!

    Thanks for the post.

  8. Pingback: 随机记事 » 敏捷实施:项目级别照单全收,组织级别循序渐进

  9. Pingback: ADSystems – Agile Development Blog » Adoção Ágil: os Projetos Deveriam Mergulhar Nela, as Organizações Deveriam Prestar mais Cautela

  10. Pingback: The Rules For The Rules Of Engagement | Project Shrink

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: