How to make Agile work?

This talk was given at the CSI lab in November 2018.

Slides

• http://agilemanifesto.org/
• https://martinfowler.com/bliki/FlaccidScrum.html
• https://www.google.com/search?q=Extreme+Programming&tbm=isch
• https://www.google.com/search?q=TDD&tbm=isch
• https://www.scrum.org/about

Notes

How to make Agile work?

What is the promise of Agile in the first place?

The agile manifesto has several sections that we can study one by one and all together.

• An introduction
• A section often called “the values”
• A general insight about those values
• A second page listing 12 principles

It is in the second page that the promise of Agile is actually disclosed.

You might argue that the first page is full of promises. I simply find some elements in the second page way easier to measure, assess, or implement.

Out of the 12 principles, the first 3 are focusing on customer satisfaction, early and frequent deliveries, being very clear that by frequent we mean a pace between a couple of weeks and a couple of months.

So, from a customer point of view, the promise of Agile is crystal clear: Agile means that the customer can expect an agile team to deliver a valuable working software every couple of months, at at least a stable price. It is a fair expectation for any customer / client / Product Owner to have, after reading this manifesto, from a team / company pretending to be agile.

The target is set.

This target is very intimidating. Think about it seriously. Monday morning you start the clock and in a couple of months later you and your team will deliver a valuable working software to your customer, and, if relevant, you will keep the pace of adding at least one valuable feature after another couple of months, and so on… And this couple-of-months is said to be the minimal pace… And take working and valuable software for what it is: software deployed in production and used by someone.

So, how does a team deliver such promise?

The agile manifesto is actually full of advice about how to make that happen.

Some are straightforward.

Business people and developers must work together daily throughout the project.  

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly 

I choose to point out those because their format does not leave room for debate. The active form of the verbs is used and it is not a matter of “should” or “could”, but “must”, “is”, “reflects”, “tunes”, “adjusts”. As if the authors had made their mind around all this a long time ago.

And actually, this is what they pretend. In the introduction, on the first page of the manifesto, we find the root of their certainties.

We are uncovering better ways of developing software by doing it and helping others do it.  

Notice the present progressive form, which suggests that they acknowledge that their journey towards better ways of developing software is not over.

They root their certainties into their experience in the field. The authors who wrote the Agile manifesto did not write it right out of university. Some had already made a career in the IT industry. And it was not one or two friends speaking as one brain neither, but distinct professionals with different opinions about what people should focus on. And after writing the manifesto, they continued to challenge each other. As an evidence of this, consider the letter that Martin Fowler wrote in 2009 about flaccid Scrum which led Ken Schwaber to create scrum.org.

In this letter, Martin emphasizes the need for good technical practices and Extreme Programming as a relevant starting point.

This is where we find Test-Driven development (TDD), in the first circle.

How does TDD help with delivering the promise of Agile?

One key I believe is the sustainable pace practice, from the second circle. One team could rely on manual testing during one iteration or two, but what happens after 15 iterations, after 42 iterations? What if the manual regression testing eats all the time? You end up with a dead product that you can not extend anymore. If you are able to create automated tests that run fast, then you can avoid this dead end. And as you might know, TDD is actually not about testing, and will usually call for a rethink of the tools, libraries, and architecture that you build and use. Answering the call is up to you.

Test-Driven Development usually comes with automated tests. So when you write your tests first, your regression test harness comes for free. Test-Driven development has been described a lot and you might find several versions of it. Usually you will find at least 3 steps: Test, Code, Refactor.

Common questions: until when do I refactor? When do I stop refactoring?

When I write a test, I’m identifying what I need from that software. In real life, I might have to collaborate with a customer (!) to identify what we need to build. The customers might be very unclear about what they need. When we know in our brain what we need, we identify maybe a list of tests, we write a test, designing at the same time the architecture that we need.

When I make the code pass, I’m “authorized” to write any code I need to green the test (yes even copy/paste code).

When I refactor I make the code ready so that the next test is easy to write. In real life, I might not even know what the next test will be. Ideally, I refactor to be ready to welcome… anything! Responding to change change “even late in the development” should remind you something. Refactor until you are ready to welcome change, until you trust that your velocity will stay stable.

You probably act more like a Professional during the Test and Refactor steps than in the Code step.

What if software developers were hired for their ability to write tests and refactor code, rather then for their ability to write code?

Professional athletes practice their sport every day, in order to be better during the next competition. Your favorite hockey team continues to practice even when competition happens every day, fine tuning anything that could help them to be better.

How often do you practice your software development skills and let the competition aside for a moment?