Managing Product Development

Wednesday, July 8, 2009

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?)

Tweet This Post

11 Comments so far
Leave a comment

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.”

Did I answer your question now? Or am I still confusing??

But Johanna, I don’t want to plunge in. The water might be really cold. Surely you can placate a bit and let me just dip in my toes??? Pretty please???? ;-)

Sigh.

I listened to podcast recently that discussed how to introduce change into your organisation or any aspect of your life actually. (http://www.se-radio.net/podcast/2009-06/episode-139-fearless-change-linda-rising)

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.)

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.

[...] I love it when my readers challenge what I’m saying, as in Plunge In or Dip Your Toe? (for Projects). [...]

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.

[...] Rothman recently wrote a great post that is related to this topic: “One of the questions people have is: Can we do [...]

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.

[...] 在最近的2篇博文《对于项目，全情投入》和《小步前进很好，但要小心如何起名》中，Johanna认为人们在项目层面上应该采用所有方法来运用敏捷。实质上，她立场坚定地指出：采用基于时间盒的迭代或者持续集成，很可能对你遇到的情况很有帮助，但这不意味着你“敏捷”了。进一步说，如果你把这叫做敏捷，你会自寻失败。 …如果你把某些东西称为敏捷，请你真正地把它做得敏捷。如果你只是小心地初体验，那你就还没有做任何承诺。如果你觉得自己无法完成时间盒中的工作，然后就调整时间盒的长度，那就不是敏捷，而是增量开发。你可以这么说：“我们正在尝试增量开发。我们选取不同长度的时间盒，这样就能确保完成所有的工作。可能经过一段时间这样的实践，我们将会固定下来时间盒长度，再来看运行得怎么样。” [...]

[...] 2 últimos posts, Plunge In (For Projects) e Small Steps Are Good, Be Careful What You Call Them, Johanna postula que as pessoas precisam [...]

RSS feed for comments on this post. TrackBack URI

Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Wednesday, July 8, 2009

Plunge In or Dip Your Toe? (for Projects)

Search

Links

Twitter Updates

Blogroll

Categories:

Archives