Skip to content

State of Agile

October 9, 2009 by Jack Milunsky

Introduction

Seems like there's lots going on in the agile world right now. Lots of talk about Lean and it's impact on Agile. Lots of attacks going on at the CSM certification. Kanban is all over the news these days. And just last week, I read about a new Agile methodology called Stride.

So how do we make sense of this all?

My opinion is that there is value in each of the methodologies (for the purposes of this blog I'll refer to them all as methodologies even though some of you might not think of them as such). It's real important to read about them all so that you are armed with enough knowledge to know what's out there. I see this as a toolset from which you can choose for your specific situation.

In order to illustrate ....

Scrum is a methodology and process that provides the mechanisms for teams to learn and adapt. Scrum however doesn't say much about the meaning of DONE and how to accomplish that. That's where XP comes in. XP has great practices around engineering discipline. It teaches us all about craftsmanship and producing quality work. I personally cannot see anyone practicing Scrum without at least some elements of the XP toolset. Be it pair programming, TDD, ruthless refactoring, emergent architectures etc.

Lean on the other hand is way more philosophical, but they have great teachings. For example, recognizing that work-in-progress is a liability is huge. If you start to think like this, you're going to minimize work-in-progress and as a result you will improve overall cycle time. With Lean, people come first. What effect does this have on your organization? Well happy teams make happy customers, better quality software, improved work culture.

And Kanban? Well Kanban helps teams with flow (i.e. cycle time, throughput etc) and almost eliminates the need for traditional sprints which I won't get into here (subject for another discussion). So many teams are using kanban boards for controlling the workflow of tasks or stories, or both.

Scrum has also been said to have problems with scalability and cross site development shops. Well Stride in it's infancy (not even sure you can call it an accepted methodology yet) has adapted Scrum to provide capabilities for better handling these sort of situations.

So what do you do?

Well in my opinion Scrum provides the best overall process or mechanism to manage agile project. It's a good base to start with and I would definitely start with Scrum. But you can't go it alone with Scrum. You have to pick and pack from other methodologies till you get what works for you.

I think Agile is evolving and most likely wont stop. And why should it. I want us to get better at it. And there's so many smart people thinking about how to make software development better. I can't wait to see what it will be like in 5 years from now.

About the Author: As COO and Scrum Master, Jack Milunsky heads software development at Brightspark. Jack is an early adopter of Scrum and has a great passion for early stage startups. Jack is co-creator of Agilebuddy, a next generation Scrum Application SaaS. Jack combines over 18 years of experience managing software development teams both large and small. You can follow Jack for great tips on Agile at http://twitter.com/agilebuddy

Comments

Scrum and DONE

October 14, 2009 by Graeme Matthew (not verified), 16 weeks 6 days ago
Comment id: 3862

"Scrum however doesn't say much about the meaning of DONE and how to accomplish that"

Jack scrum does say a lot about done, DONE in scrum is that it is potentially shippable, has been coded, works, has been tested and has been accepted, very simple....

XP is the sound engineering practices used within scrum to reach done ...

Regards

Graeme

Done'ness

October 22, 2009 by Jack Milunsky (not verified), 15 weeks 5 days ago
Comment id: 3953

Hi Graeme,

It does talk about Done - agreed, about potentially shippable, yes.... BUT it doesn't spell it out like XP does in terms of how to do it so that your definition Done is serious enough to produce high quality output.

I recall on my CSM training that we were taught that prior to the sprint teams must agree on their definition of done which would suggest that it's open to interpretation. I think Quality should be king and there should be no discussion about Done'ness

My 2 cents

Interesting Summary

November 5, 2009 by Tom Freeman (not verified), 13 weeks 5 days ago
Comment id: 4041

Hi,

Thanks for the insight into the use of different agile methodologies. We recently used Scrum for a rss web project and there's certainly a lot to be said for developing software in this manner. In the end I think it all comes down to the individual situations we find ourselves in, but an understanding of the principles involved certainly arms developers well in dealing with managing projects successfully. One thing I'm particularly interested in is the documentation side of agile development. Can you point me in the direction to learn more about this perhaps?

Thanks,
Tom

Documentation

November 6, 2009 by jackMilunsky, 13 weeks 4 days ago
Comment id: 4046

Well what can I say about documentation except to say that if you look at one of the 4 Agile Manifestos ...

Agile'ists value Working software over comprehensive documentation

So the focus should be more about getting the software done than worrying about documentation.

Never the less documentation is required in may cases, sometimes it's required by compliance regulations etc

In cases where it is compulsary, do the minimum required to get the compliance.

It's important however that code is properly documented, this is just standard good engineering practice.

You need to treat documentation on an as needed basis.

Lean folks keep documentation small via A3 reporting and root cause analysis documents. You can find a link to a good article on this here ... http://www.docstoc.com/docs/12765203/Cause-effect-diagrams

Jack

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters (without spaces) shown in the image.

Best of AgileSoftwareDevelopment.com