Mother of all engineering practices (Part - II of 'Are you BEING agile or just USING agile?' )

In the part - I of this post, I listed out a whole lot of engineering practices. But didn't elaborate-

Which one of that in the list is most important or all of them are important?

How can you adopt them? All at a time or one at a time?

If one at a time, which one is that?

Is there any dependency between them so that one practice becomes predecessor to another practice?

Most of the time, correct answer for such questions is 'It depends'.  Since each project is, each customer is, each environment is unique often you cannot give a definite answer to such questions. But even then I thought of a few practices stand apart from others in terms of criticality, dependency, business value and logical starting points.  In my view, the one thing that stands out in the crowd is 'automated unit tests'. Why is it so important?

It's a logical starting point, without which you cannot implement many of the other practices. In terms of the amount of business value, no other single practice brings this much value as the automated unit tests.

It 'increases quality to the market' by making the defects obvious in the development cycle itself;

It 'reduces time-to-market' by catching the bugs early in the development cycle;

It 'reduces the Total Cost Ownership (TCO)' by helping the developer to figure out potential bugs even before code check-in; (bug detection after code check-in is always costlier);

It 'reduces the TCO' by reducing the regression test cycle;

It 'increases the life time of the product' by improving the maintainability

What more you need? Further, many of the other practices cannot be implemented without having automated unit tests

Continuous integration that runs all the unit tests before doing the real 'integration';

Test Driven Development depends on automated unit tests for high quality implementation;

Collective Code Ownership expects the automated unit tests to point out early bugs when somebody not familiar with the code base is tasked with changing the code;

Simple Design and Refactoring depends on automated unit tests to catch problems early when the structure is progressively changed without changing the behavior or functionality;

So if you are catching up with agile engineering practices and looking for a starting point, the choice is obvious: Start with automated unit tests, teach them, coach them, give some time for them to catch up before it becomes a habit and reaping benefits

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.