Understanding Agile at a Deeper Level

One of the criticisms I’ve heard often about Agile/Scrum is that people do it “mechanically” – sometimes, they rigidly and dogmatically implement Scrum “by the book”. That’s very ironic because it’s the opposite of what was intended by the Agile Manifesto (remember “Individuals and interactions over processes and tools”). That shouldn’t be surprising – you can get a Certified Scrum Master (CSM) certificate by sitting through a two-day course and many people never go beyond that level of training.

In my opinion, to develop a high-performance Agile/Scrum approach that is dynamic and adaptable to a broad range of situations, you have to go beyond doing it “mechanically by the book” and understand the principles and values behind it at a deeper level. This becomes particularly important when you try to scale Agile/Scrum to larger and more complex enterprise-level projects.

I’ve developed a new online training course to help fill this need and I’m offering this course at a discounted price of $10 for anyone who wants to take it during the month of June. Here’s a brief video summary of this new online training course:

Understanding Agile at a Deeper Level Video Summary

You can find more information on this course plus the discount coupon code on this blog site training page:

Understanding Agile at a Deeper Level Course Information

If you’re interested in certification, this course should be excellent preparation for the Professional Scrum Master (PSM) certification. I think the PSM certification is more rigorous than CSM and it recognizes that training and development should be an ongoing process beyond simply sitting through a one-time, two-day training course.

Agile Contracts

A lot of people may think that it is inconsistent to impose constraints that the project needs to be completed within a certain expected cost and schedule on an Agile project. It is difficult, but it definitely can be done – one of the areas where that becomes essential is Agile contracts. For example, I once managed a large federal government project that had all the typical government contracting requirements for cost and schedule milestones; but, at the same time, the government customer wanted some level of flexibility to work out detailed requirements as the project progresses.

Does that sound inconsistent? It might be depending on the relationship you have with the customer. Obviously, this will only work if there is a spirit of trust and partnership with the customer to collaboratively agree to work out any tradeoffs between the scope of the requirements and the cost and schedule of the contract as it progresses. If there is more of a typical “arms-length” contracting relationship or some kind of adversarial relationship, it’s not going to work at all.

Doing this requires a hybrid Agile approach that blends an Agile development approach with a plan-driven “shell”. The plan-driven shell provides some level of predictability and control over the overall scope, cost, and schedule of the project while the Agile development approach operates within that shell to provide some level of flexibility and adaptivity in the detailed requirements. That approach is described in more detail in my article on the “Managed Agile Development Framework“.

Jeff Sutherland has created a very nice model for this called “Money for Nothing, Change for Free”. Jeff’s approach is based on two primary clauses in an Agile contract:

  • “Change for Free”

    The “Change for Free” clause is based on the idea that the customer can make any change they want provided that the total contract work is not changed. This allows new features to be added provided that lower priority items are removed from the project. I have documented a case study in my book on how General Dynamics, UK successfully used this approach on a large government contract in the UK.

  • “Money for Nothing”

    The “Money for Nothing” clause is interesting. It recognizes the fact that in many projects, the customer always asks for everything that they could possibly need but if you prioritize those items and deliver the highest priority items first, at some point you will reach a point of diminishing returns where the cost of developing incremental features exceeds the value that those features provide. This clause allows the customer to cancel the contract at that point and save 80% of the cost that would have been spent to complete the remaining items; however the contractor receives a fee of 20% of the cost for early cancellation which makes it a win/win for both the customer and the supplier.

This concept is not limited to fixed-price contracts – that’s only the extreme case. It can be applied to almost any Agile project where there is a need for some level of predictability and control over the costs and schedule of the project. Very few people get a “blank check” to do an Agile project without any expectations of what will be delivered and what the estimated cost and schedule of the project are likely to be.

More on Agile versus Waterfall

I previously wrote a post on “Agile versus Waterfall” that a number of people seemed to like:

https://managedagile.wordpress.com/2013/08/02/agile-versus-waterfall/

The essence of that post was that when people use the term “Waterfall”, the use of the terminology “Waterfall” is typically somewhat sloppy. The real definition of the word “Waterfall” can be traced back to Winston Royce’s paper that was written in 1970 (a copy is available here):

Click to access waterfall.pdf

(Thanks and acknowledgement to Wayne Mack for providing this reference and inspiring me to write this post)

Here’s an example of this from an invitation to attend a presentation I received that is actually being given this week in the Boston area:

“It would be so easy if everyone at our companies just used Scrum — or at least Agile. No one would lean on the team for dates and deadlines, and everyone would know that change is a good thing. It’d be one great big happy project management family. But let’s face it — an all-Agile organization isn’t always possible. Maybe you have a Project Management Office (PMO). Maybe you work for a government contractor. Maybe you have regulatory requirements. Maybe you’re the first Scrum/Agile project at your company. Maybe your company simply *likes* it this way. Whatever the reason, Agile teams frequently report into Waterfall organizations.”

What do they mean by a “Waterfall organization”? This is a perfect example of sloppy use of terminology. In this particular case, there is an implication that a “Waterfall Organization” is one that plans and manages projects with some kind of schedule and there is also an implication that that sort of planning and management of schedule expectations should never be done in an “All Agile” organization.

When people use the word “Waterfall” like this, I’m tempted to ask, “Which aspect of ‘Waterfall’ are you referring to?”

  • Are you referring to the phase gate approach where a project is broken up into phases and there is a phase gate for approval to transition between phases? I don’t think that approach has been widely practiced for years for software development projects and, as this paper indicates, Winston Royce himself had reservations about it. Long before Agile became widely used people began using an iterative approach to projects using RUP or variations on RUP.
  • Are you referring to an over-reliance on documentation? That is a more legitimate comparison because Winston Royce did come out very strongly in support of a lot of documentation, but that shouldn’t imply that an Agile project has no documentation whatsoever.
  • Are you referring to the tendency to plan an entire project upfront before starting the project and then manage changes to the project requirements through change control? That also might be a legitimate comparison, but it also shouldn’t be meant to imply that an Agile project shouldn’t do any planning upfront.
  • Are you referring to the practice of using loosely-coupled teams from different organizations (such as engineering, test, operations, etc.) to perform a project instead of well-integrated teams? That also might be a legitimate comparison, but that is not really an attribute of the “Waterfall” methodology itself at all, it is more of a characteristic of how organizations have typically been managed.

In many cases, when people use the word “Waterfall”, its not very precise and people are using the term “Waterfall” loosely to refer to any kind of bad software development practices. This has also created the notion that there is an all-or-nothing decision between practicing Agile and practicing “Waterfall” – in other words, Agile equals Scrum (but only when it is done “by the book”) and Scrum is good; everything else is “Waterfall” or not really Agile and is bad. Don’t get me wrong, I’m very passionate about Agile and believe in it strongly, but I think this kind of simplistic thinking is what has caused so much polarization between proponents of Agile principles and practices and proponents of more traditional project management principles and practices.

This kind of simplistic comparison causes people to think that there is an “All Agile” approach at one extreme where there is no planning and no documentation whatsoever and a totally rigidly planned and controlled approach at the other extreme called “Waterfall” and nothing in between those two extremes. That is the notion that I’ve tried to dispel in my two books on this subject.