Are you BEING agile or just USING agile?

Ken Schwaber, one of the creators of Scrum, was visibly upset when somebody described Scrum as a 'software development methodology' at the end of a Scrum training program. So what's the problem here? Why was he upset?

It's because Scrum is a framework, that  means it's incomplete, It's only a foundation, it's only a starting point and with Scrum alone you don't become agile.  Most people think that if they develop the software in increments and short iterations and showing the product to the customer every fortnight or so they become agile. When you think deeply about Scrum, you will understand that it's a set of best practices for managing the project tight. By managing a project tightly, sure you can keep some of the project objectives under your firm control, but what's the guarantee that the product delivers business value to the customer? What's the guarantee that the product quality is ensured? Do you think there is a missing piece here?   

The fact that 'Scrum is incomplete' is by design;  it's so for a reason; it's deliberate;

It's a software development process framework that gives you a heads-up and a flying start but you reach the destination only by  filling in the gaps with right mix of engineering practices.

Expectation is that each Scrum team will think about the business objectives highly valued by their customer; 

Each Scrum team will consider the constraints and quality issues faced by the business and the team;

And the team will come out with their own set of practices for meeting the business values or to work around the constraints.

With the right amount of engineering practices and automation  coupled with Scrum, you attain the process NIRVANA. Some of the practices (most of them are XP practices) you will consider to reach that stage are-

Simple, just enough design

Continuous code refactoring

Pair programming

Automated unit tests

Automated functional tests

Test driven requirements (TDR)

Test driven development (TDD)

Static code analysis

Frequent code integration

Check-in quality gate

Agile estimation

Collective code ownership

Architectural and technical spikes

If you are having a lot of integration bugs, then you will probably adopt automated unit testing

If the customer is NOT deriving the expected business values, then you will probably adopt test driven requirements (TDR)

If one or 2 resources are becoming bottlenecks, then you will probably consider collective code ownership and pair programming

And so on…

It's very important that the team understands the business values and constraints and adopt XP practices as needed and improvise the process for the unique project environment,  performing organization culture, customer org culture and the customer's unique values

If you are not practicing any of the above probably you are NOT agile, despite the fact that you are using Scrum. There is a hell lot of difference between BEING agile and USING agile. Probably you are USING agile, but not BEING agile.