Agile 101

Project Management, Digital Publishing and Agile Software Development

Posts Tagged ‘Software Project Management’

The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictures!)

Posted by Tara Hamilton-Whitaker on September 8, 2009

Here’s a VERY simple overview of the main differences between Waterfall DevelopmentIterative Waterfall Development, Scrum/Agile Development and Lean.

Waterfall Development

‘Waterfall Development’ is another name for the more traditional approach to software development.

It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).

In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time!

This approach is highly risky, often more costly and generally less efficient than more Agile approaches.

The main issues with this approach include:

  • You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development)
  • You leave the testing until the end, which means you’re leaving issue discovery until late in the day
  • You don’t seek approval from the stakeholders until late in the day – their requirements might have changed
  • You’re heavily reliant upon a plan, which you can/will often follow to the detriment of the end result
  • You’re heavily reliant upon a project manager driving the way – the power of one

Iterative Waterfall Development

This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches.

The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features.

The most commonly occurring issue in this type of scenario (in my experience) is bottle necking.

For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing.

Another common symptom of this type of approach is over-commitment.  It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way. 

You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined.

For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases.

It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

Scrum Development

This approach carries far less risk than Waterfall approaches.

We focus on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature.

With that said, we still plan our work in iterations and we will still release at the end of each iteration.

Lean Development

Lean is very similar to Scrum in the sense that we focus on features as opposed to groups of features – however Lean takes this one step further again.

In Lean Development, you select, plan develop, test and deploy one feature (in its simplest form) before you select, plan, develop, test and deploy the next feature. By doing this, you further isolate risk to a feature-level.

In these environments, you aim to eliminate ‘waste’ wherever possible – you therefore do nothing until you know it’s necessary or relevant.

//

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

the-difference-between-waterfall-iterative-waterfall-scrum-and-lean

Advertisements

Posted in Featured, Project Management | Tagged: , , , | 16 Comments »

Agile Project Management – Self-Organisation: The Secret Sauce for Improving your Scrum Team

Posted by Tara Hamilton-Whitaker on September 7, 2009

A ‘must watch’ Google Tech Talk by Jeff Sutherland, one of the founders of Scrum, about the ‘secret’ ways to achieve ‘hyper-productivity’ in an Agile Project Mangement environment.

In this seminar, Jeff talks about the following topics:

  • Introduction to the ‘Scrum But…’ (!)
  • How to monetise improved team performance
  • Shock therapy as a strategy for booting up teams.
  • The Cosmic Stopping Problem, otherwise known as the choice uncertainty principle.
  • Punctuated equilibrium – how software systems evolve

Google Tech Talks
September 4, 2008

ABSTRACT

High performance depends on the self-organizing capability of teams. Understanding how this works and how to avoid destroying self-organization is a challenge. Until you understand complex adaptive systems and how Toyota works it is difficult to improve team velocity.

Jeff will discuss three core topics:

  1. Shock therapy as a strategy for booting up teams.
  2. The Cosmic Stopping Problem, otherwise known as the choice uncertainty principle.
  3. Punctuated equilibrium – how software systems evolve

Take advantage of these concepts and you may find a way to achieve the ultimate potential of a team. This session will be a “Deep Agile” presentation keying off topics presented to engineers at MIT.

Speaker: Jeff Sutherland
Dr. Jeff Sutherland is one of the co-creators of the Scrum software development process. He and Ken Schwaber invented Scrum in 1993. Since then he has worked with many software companies and IT organizations to extend and enhance this process.

Watch more videos from Agile101

//

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

Posted in Project Management, Video | Tagged: , , | 1 Comment »

What does 'Done' mean in Agile Software Development?

Posted by Tara Hamilton-Whitaker on September 4, 2009

what-does-done-mean-for-an-agile-software-development-team

In Agile Software Development environments, we aim to deliver ‘[potentially] shippable code’ at the end of each iteration.

In actual fact, we often settle for delivering a chunk of value at the end of each iteration.  This ‘value’ may or may not be directly attached to a piece of shippable code. 

We also aim to close each iteration with no leftovers, no dependencies – everything must be ‘done’.

I recently watched a Google Tech Talk by Jeff Sutherland where he discusses ‘Done’ (Scrum Tuning: Lessons Learned at Google). 

Jeff explained that ‘Done’ at Patient Keeper, his company, is a piece of code live to the public having received no complaints within an hour of release.  

This got me thinking.

  • So, what is ‘Done’?… 
  • Does ‘Done’ HAVE to be ‘live with no complaints within an hour of release’?…
  • Does ‘Done’ HAVE to be potentially shippable code?
  • What does ‘potentially shippable’ mean?
  • Does ‘Done’ HAVE to relate to the delivery of code?
  • Can ‘Done’ change one a case by case basis? …

In traditional, Waterfall, environments, we follow a series of consecutive steps running between project inception and completion – we understand that we are ‘done’ when all of the steps are complete, the product is released, we disassemble the project team etc.  This is a relatively simple concept to get your head around.

In an Agile environment, however,  we follow these steps each iteration… in fact, we probably follow these steps a number of times per day.

Of course we’re interested in being ‘done’ with the project, but we’re more interested in being ‘done’ with each task, each story and ultimately each deliverable that will in turn deliver value.

So, now we need to define ‘value’! Is value *only* delivered by shipped code? Probably not.

For example, the objective of a Spike is to get a clear idea on where to go next.  ‘Done’ in this situation might be a working prototype that might end up being released – if you’re lucky.

On the other hand, the task(s) could be to deliver a series of findings that inform a decision – ‘Done’ might be a firm decision one way or another e.g. completion of the Planning and Analysis stages.. (see inset image)

As mentioned above, you may decide not to release at the end of each iteration. You may schedule releases around Minimum Marketable Features or Epics that span multiple sprints. In these cases ‘Done’ may relate to the delivery of ‘potentially shippable’ code, which has been fully-tested, acceptance tested and performance optimised (as much as possible).

So, it becomes clear that the definition of ‘Done’ may indeed neeed to vary on a case by case basis.

With that said, regardless of what your definition of ‘Done’ is, the definition must be understood by everyone involved.

//

Subscribe to the Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

Posted in Featured, Project Management | Tagged: , , | 3 Comments »