"Pragmatic Agile"

prag·mat·ic/pragˈmatik/

I've never been one you could call academic.  I'd like to think that I've always had my feet firmly planted in the real world, however you define it.  My focus has always been on delivering value rather than adhering to some theoretical principles.

For example, when I first learned about Extreme Programming in 2000, I didn't read Kent Beck's Extreme Programming Explained first, but rather Extreme Programming Installed by Ron Jeffries, Chet Hendrickson and Ann Anderson.  While both books described XP, the former wandered more into the theory while the latter was more along the lines of, "This is XP and here's how we implemented it."  That approach of applied theory appealed to me, and I was able to apply it myself shortly thereafter.

I'm a huge fan of the Pragmatic Programmers, Dave Thomas and Andy Hunt.  Their first book, The Pragmatic Programmer, is a must-read for anyone entering into the software development profession (and a should-read for most who are already developing software professionally!).  Again, their real world approach appealed to me, and they have turned the whole Pragmatic thing into a franchise of its own.  The books that they publish for other authors all have that feeling of providing concrete advice that you can use immediately.

However, I do have to admit that I cringe every time I hear the word pragmatic.  While Mssrs. Thomas and Hunt have what I believe the right approach to pragmatism, time and again I see that word abused.

Cherry Picking
I can't begin to count the number of times that, as a coach, I've heard programmers, testers, business analysts, line managers, product managers, directors, executives, and probably even the cleaning staff say that they couldn't possibly use some Agile practice.  Instead, they would insist on continuing to do what they had always done.  After all, we have to be pragmatic in how we apply Agile, right?  Well, yes... and no.

This notion of taking what you like from Agile methods such as Scrum, XP and Kanban is known as cherry picking, and in my experience it leads to serious problems almost 100% of the time.

Agile Values and Principles
I'm OK with people substituting practices.  I honestly believe that there are many ways to accomplish a task.  However, if you don't link the practices back to the Principles and Values of Agile, then you are going to experience difficulty.

For example, consider the 6th Agile principle:

Working software is the primary measure of progress.

What that means is... well, I think it's pretty clean what it means.  It does not mean a colourful Gantt chart generated by MS Project by someone who attends the standup meetings and tracks each task by each person down to the hour.  Even if that is done in a spreadsheet, completion of tasks and even the completion of Stories or Backlog Items simply represents activity.  True progress is shown when software is working and in the hands of those intended to consume it such that you can receive concrete feedback on that software's suitability to the business task.

The use of Velocity - Story Points or some other measure of the size of items completed over time - as a means of measuring progress can be (and is often) easily abused.  Despite that, I've always loved that the original XP team chose that term.  Speed is a simple scalar value, denoting distance over time, whereas Velocity is a vector, which has a directional component.  If you aren't receiving feedback on whether what you're building is actually what is supposed to be built, you could be going in completely the wrong direction.  In other words, you aren't measuring Velocity, you're measuring Speed!

The use of the term working also means that the teams don't simply hack together some spaghetti code in order to get the current stories completed.  That leads to the 8th principle:

Continuous attention to technical excellence and good design enhances agility.

I love asking groups of developers to whom I'm speaking if anyone there is a crappy developer.  Of course, there's always one or two who put their hands up and we all have a chuckle.  I then put up some of their code that I had asked for prior to the talk, and start to talk about all the Code Smells in it.  The excuses then absolutely pour in:

• That was written by the people in (any site but theirs)!
• We had to get that done before the release!
• I wanted to clean that up, but my manager said I didn't have time!

Sorry, but a 3,000-line function with a Cyclomatic Complexity of 500 that grew to that size over 10 years is inexcusable.  Apparently, though, it isn't uncommon whether you're working in the procedural or the object-oriented world.

I see developers constantly taking shortcuts in the name of expediency, being pragmatic, about meeting a deadline vs. creating solid, maintainable code.  The ironic result is that rush to meet the deadline creates defects and opaque code that causes them to miss the deadlines even in the short term!

The same applies to automated testing of code.  I agree fully that it's neither practical nor necessary to ensure that you are hitting 100% code coverage in your low-level tests.  That's especially the case when you are applying tests to existing legacy code - you need to evaluate the risks associated with the work you're doing, and test appropriately.  However, for greenfield work it's relatively simple to start testing immediately and maintain those tests over time.  That applies to languages from C to Ruby, Java to Python, and almost everything in between.

Regardless of whether you're dealing with a legacy Big Ball of Mud or working from a clean slate, making the investment in automated tests will make you go faster.  That is the pragmatic approach!

So, if you are choosing to change or omit some practices from Scrum or XP, you need to ask yourself if you can still satisfy the Agile Principles that are part of the foundations for those practices.  If you can, then you are probably being truly pragmatic in your approach.  If not, then you need to look deeper at what needs to be done in order to improve how you work.

Stay tuned - more on pragmatism within the context of the Agile Principles in a later post!