Encouraging Agile Discipline
Motivating developers to follow agile practices




     This work is released under the term...
The Business Problem
The Business Problem

You have have to upgrade your legacy software to
keep your competitive advantage
The Business Problem

You have have to upgrade your legacy software to
keep your competitive advantage
Upgrading your lega...
The Business Problem

You have have to upgrade your legacy software to
keep your competitive advantage
Upgrading your lega...
The Business Problem

You have have to upgrade your legacy software to
keep your competitive advantage
Upgrading your lega...
The Business Problem
Some Technical Solutions
Some Technical Solutions

Move to a more powerful language
  Python, Ruby, Erlang, Smalltalk
Some Technical Solutions

Move to a more powerful language
  Python, Ruby, Erlang, Smalltalk
Create a more flexible archite...
Some Technical Solutions

Move to a more powerful language
  Python, Ruby, Erlang, Smalltalk
Create a more flexible archite...
Some Technical Solutions
Our Example Problem
Our Example Problem
We want our HTML web app available as a web
service...
Our Example Problem
We want our HTML web app available as a web
service...
...but half of our business logic is in the Jav...
Our Example Problem
We want our HTML web app available as a web
service...
...but half of our business logic is in the Jav...
Our Example Problem
We want our HTML web app available as a web
service...
...but half of our business logic is in the Jav...
Our Example Problem
We want our HTML web app available as a web
service...
...but half of our business logic is in the Jav...
The Underlying Problem
The Underlying Problem
 Software technologies don’t make you follow good
 practices, they just remove obstacles to them
The Underlying Problem
 Software technologies don’t make you follow good
 practices, they just remove obstacles to them
 Y...
The Underlying Problem
 Software technologies don’t make you follow good
 practices, they just remove obstacles to them
 Y...
The Underlying Problem
 Software technologies don’t make you follow good
 practices, they just remove obstacles to them
 Y...
The Underlying Problem
 Software technologies don’t make you follow good
 practices, they just remove obstacles to them
 Y...
The Underlying Problem
 Software technologies don’t make you follow good
 practices, they just remove obstacles to them
 Y...
The Underlying Problem
Our Example Problem ctnd.
Our Example Problem ctnd.
...we were left needing to refactor our code
Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test s...
Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test s...
Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test s...
Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test s...
Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test s...
Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test s...
Our Example Problem ctnd.
...we were left needing to refactor our code
In order to refactor we need a comprehensive test s...
A Field Guide to
Post-Legacy Developers
A Field Guide to
Post-Legacy Developers
Enthusiastic
  “The last project was slow and painful. I was here deploying at 2am...
A Field Guide to
Post-Legacy Developers
Enthusiastic
  “The last project was slow and painful. I was here deploying at 2am...
A Field Guide to
Post-Legacy Developers
Enthusiastic
  “The last project was slow and painful. I was here deploying at 2am...
A Field Guide to
Post-Legacy Developers
Stick vs Carrot
Stick vs Carrot

 Are the members of your team enthusiastic, neutral, or
 lazy?
Stick vs Carrot

 Are the members of your team enthusiastic, neutral, or
 lazy?
 Will they try not to break the continuous...
Stick vs Carrot

 Are the members of your team enthusiastic, neutral, or
 lazy?
 Will they try not to break the continuous...
Stick vs Carrot

 Are the members of your team enthusiastic, neutral, or
 lazy?
 Will they try not to break the continuous...
Stick vs Carrot
Skill vs Discipline
Skill vs Discipline
                         Technical skill
                       Low             High

              Po...
Skill vs Discipline
                                   Technical skill
                               Low                 ...
Skill vs Discipline
                                   Technical skill
                               Low                 ...
Skill vs Discipline


                      Or do you
                      just need
                      more
         ...
Skill vs Discipline
Agile Practices
(not an exhaustive list)
Agile Practices
(not an exhaustive list)


  Acceptance tests         Automated deployments
  Unit tests               Con...
Agile Practices
(not an exhaustive list)
Agile needs...
Agile needs...
                                  Technical skill
                            Low                          ...
Agile needs...
                                          Technical skill
                                    Low          ...
Agile needs...
The Underlying Solution
The Underlying Solution

 A highly-disciplined bunch of über-geeks
The Underlying Solution

 A highly-disciplined bunch of über-geeks
   If you are willing to pay 50k+ a head
The Underlying Solution

 A highly-disciplined bunch of über-geeks
   If you are willing to pay 50k+ a head
   Maybe
The Underlying Solution

 A highly-disciplined bunch of über-geeks
   If you are willing to pay 50k+ a head
   Maybe
   Ma...
The Underlying Solution

 A highly-disciplined bunch of über-geeks
   If you are willing to pay 50k+ a head
   Maybe
   Ma...
The Underlying Solution
Upcoming SlideShare
Loading in …5
×

Encouraging Agile Discipline

865 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
865
On SlideShare
0
From Embeds
0
Number of Embeds
106
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Introduce self. This is my first talk/led discussion. If I speak to fast, or too quietly, please stop me as soon as possible. I’ve prepared 12 slides to introduce the subject.


    To begin with, let’s look at the typical business situation that highlights the need for a technological improvement.
  • AT END:

    The most concrete part of this is the programming language. Expressing business logic in Ruby is easier than expressing it in Java. Building a fault-tolerant media server is easier in Erlang than in C++.

    A more abstract part of the solution is to define the boundaries of your app and build a service-oriented solution. Now your billing and site admin code can be in Ruby, and your video processing code can be in Erlang. The inspiration for this talk was Marc Johnson’s huddle at the previous Sheffield GeekUp, “Laying Your Legacy to REST”. The key idea being that creating a service-oriented suite of web-services will produce more powerful software quicker.

    Of course, you can’t just go rewriting random bits of you app in a new language, and you can’t just go slicing pieces from your legacy code and turning them into services.

    To do either of these you will need to follow agile practices. I will present a sample of these layer, but for now I want to give a specific example of a problem they could help solve.
  • AT END:

    The most concrete part of this is the programming language. Expressing business logic in Ruby is easier than expressing it in Java. Building a fault-tolerant media server is easier in Erlang than in C++.

    A more abstract part of the solution is to define the boundaries of your app and build a service-oriented solution. Now your billing and site admin code can be in Ruby, and your video processing code can be in Erlang. The inspiration for this talk was Marc Johnson’s huddle at the previous Sheffield GeekUp, “Laying Your Legacy to REST”. The key idea being that creating a service-oriented suite of web-services will produce more powerful software quicker.

    Of course, you can’t just go rewriting random bits of you app in a new language, and you can’t just go slicing pieces from your legacy code and turning them into services.

    To do either of these you will need to follow agile practices. I will present a sample of these layer, but for now I want to give a specific example of a problem they could help solve.
  • AT END:

    The most concrete part of this is the programming language. Expressing business logic in Ruby is easier than expressing it in Java. Building a fault-tolerant media server is easier in Erlang than in C++.

    A more abstract part of the solution is to define the boundaries of your app and build a service-oriented solution. Now your billing and site admin code can be in Ruby, and your video processing code can be in Erlang. The inspiration for this talk was Marc Johnson’s huddle at the previous Sheffield GeekUp, “Laying Your Legacy to REST”. The key idea being that creating a service-oriented suite of web-services will produce more powerful software quicker.

    Of course, you can’t just go rewriting random bits of you app in a new language, and you can’t just go slicing pieces from your legacy code and turning them into services.

    To do either of these you will need to follow agile practices. I will present a sample of these layer, but for now I want to give a specific example of a problem they could help solve.
  • AT END:

    The most concrete part of this is the programming language. Expressing business logic in Ruby is easier than expressing it in Java. Building a fault-tolerant media server is easier in Erlang than in C++.

    A more abstract part of the solution is to define the boundaries of your app and build a service-oriented solution. Now your billing and site admin code can be in Ruby, and your video processing code can be in Erlang. The inspiration for this talk was Marc Johnson’s huddle at the previous Sheffield GeekUp, “Laying Your Legacy to REST”. The key idea being that creating a service-oriented suite of web-services will produce more powerful software quicker.

    Of course, you can’t just go rewriting random bits of you app in a new language, and you can’t just go slicing pieces from your legacy code and turning them into services.

    To do either of these you will need to follow agile practices. I will present a sample of these layer, but for now I want to give a specific example of a problem they could help solve.
  • AFTER 2: And who knows which half of the business logic is in the front end? Probably nobody...

    AFTER 4: And not just broken something once, but turned development into a game of whack-a-mole. Every time we deploy, some random part of the app breaks. And worse, some parts we fix break again later. In short, creating a web service version of our app could put us out of action for weeks if it goes live with serious bugs.
  • AFTER 2: And who knows which half of the business logic is in the front end? Probably nobody...

    AFTER 4: And not just broken something once, but turned development into a game of whack-a-mole. Every time we deploy, some random part of the app breaks. And worse, some parts we fix break again later. In short, creating a web service version of our app could put us out of action for weeks if it goes live with serious bugs.
  • AFTER 2: And who knows which half of the business logic is in the front end? Probably nobody...

    AFTER 4: And not just broken something once, but turned development into a game of whack-a-mole. Every time we deploy, some random part of the app breaks. And worse, some parts we fix break again later. In short, creating a web service version of our app could put us out of action for weeks if it goes live with serious bugs.
  • AFTER 2: And who knows which half of the business logic is in the front end? Probably nobody...

    AFTER 4: And not just broken something once, but turned development into a game of whack-a-mole. Every time we deploy, some random part of the app breaks. And worse, some parts we fix break again later. In short, creating a web service version of our app could put us out of action for weeks if it goes live with serious bugs.
  • AFTER 2: And who knows which half of the business logic is in the front end? Probably nobody...

    AFTER 4: And not just broken something once, but turned development into a game of whack-a-mole. Every time we deploy, some random part of the app breaks. And worse, some parts we fix break again later. In short, creating a web service version of our app could put us out of action for weeks if it goes live with serious bugs.
  • AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.

    AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.

    AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
  • AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.

    AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.

    AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
  • AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.

    AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.

    AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
  • AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.

    AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.

    AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
  • AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.

    AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.

    AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
  • AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.

    AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.

    AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
  • AFTER 1: The Ruby community is probably the most test-obsessed, especially since RSpec was released. The quality of good RSpec code is far higher than most JUnit and NUnit tests I’ve seen because RSpec is a more powerful library (in part because it sits on a more powerful language). But even still, I’m fairly sure most Ruby code is poorly tested, or not tested at all.

    AFTER 2: Fred Brooks had neither RSpec nor JUnit, and he still automated tests. They certainly weren’t of the quality we can achieve today (now that object-oriented design theory has been embraced), but they were still valuable.

    AFTER 3, before 3b: Service-oriented architecture was meant to help create good software design. But the idea of single-responsibility, which is very similar, was already a good design principle before SoA. And that didn’t help before, because not all developers followed it.
  • AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.

    AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!

    AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.

    AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.

    AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
  • AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.

    AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!

    AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.

    AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.

    AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
  • AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.

    AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!

    AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.

    AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.

    AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
  • AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.

    AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!

    AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.

    AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.

    AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
  • AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.

    AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!

    AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.

    AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.

    AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
  • AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.

    AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!

    AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.

    AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.

    AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
  • AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.

    AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!

    AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.

    AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.

    AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
  • AFTER “Need unapparent?”: it might be that the code is old, or the app started out simple, and at the time nobody realised how essential it would be in the long run.

    AFTER “Perceived lack of time?”: maybe somebody thought that writing tests would take too long. That’s fine, because time spent fixing bugs in live code is really cheap. The decision not to pay overtime was ingenious!

    AFTER “Apathy?”: probably the strongest force in human nature: things are the way they are because nobody could be bothered to change them. A successful team can’t afford to be apathetic. A team that turns apathetic will stagnate.

    AFTER “Oh shit, it’s too late”: The previous three attitudes have dug you into a hole.

    AT END: I’m going to assume that we have no major technical or political obstacles to going agile. That means it’s up to our team to implement agile. Let’s look at some of the attitudes developers can have.
  • AFTER 1:
    Please raise your hands if your team is, or your past teams have been:
    • Largely enthusiastic
    • Largely neutral
    • Largely lazy

    AT END: IS IT REALLY THAT SIMPLE?
  • AFTER 1:
    Please raise your hands if your team is, or your past teams have been:
    • Largely enthusiastic
    • Largely neutral
    • Largely lazy

    AT END: IS IT REALLY THAT SIMPLE?
  • AFTER 1:
    Please raise your hands if your team is, or your past teams have been:
    • Largely enthusiastic
    • Largely neutral
    • Largely lazy

    AT END: IS IT REALLY THAT SIMPLE?
  • AFTER 1:
    Please raise your hands if your team is, or your past teams have been:
    • Largely enthusiastic
    • Largely neutral
    • Largely lazy

    AT END: IS IT REALLY THAT SIMPLE?
  • AFTER 1:
    Please raise your hands if your team is, or your past teams have been:
    • Largely enthusiastic
    • Largely neutral
    • Largely lazy

    AT END: IS IT REALLY THAT SIMPLE?
  • This is a story I found on the net
    "Some years ago I was looking for a job and did a lot of online résumé form filling,"
    "One of those many sites had a form that took about a second to uppercase my name when I hit Tab, before putting the focus on the next field.
    "That puzzled me. One second to uppercase a single-lined string?!
    "The javascript was something like this:
  • This is a story I found on the net
    "Some years ago I was looking for a job and did a lot of online résumé form filling,"
    "One of those many sites had a form that took about a second to uppercase my name when I hit Tab, before putting the focus on the next field.
    "That puzzled me. One second to uppercase a single-lined string?!
    "The javascript was something like this:
  • BEFORE SHOWING CHART: On the other hand

    AFTER CHART:

    Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.

    Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.

    N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.

    Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
  • BEFORE SHOWING CHART: On the other hand

    AFTER CHART:

    Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.

    Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.

    N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.

    Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
  • BEFORE SHOWING CHART: On the other hand

    AFTER CHART:

    Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.

    Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.

    N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.

    Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
  • BEFORE SHOWING CHART: On the other hand

    AFTER CHART:

    Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.

    Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.

    N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.

    Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
  • BEFORE SHOWING CHART: On the other hand

    AFTER CHART:

    Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.

    Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.

    N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.

    Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
  • BEFORE SHOWING CHART: On the other hand

    AFTER CHART:

    Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.

    Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.

    N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.

    Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
  • BEFORE SHOWING CHART: On the other hand

    AFTER CHART:

    Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.

    Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.

    N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.

    Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
  • BEFORE SHOWING CHART: On the other hand

    AFTER CHART:

    Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.

    Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.

    N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.

    Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
  • BEFORE SHOWING CHART: On the other hand

    AFTER CHART:

    Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.

    Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.

    N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.

    Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
  • BEFORE SHOWING CHART: On the other hand

    AFTER CHART:

    Daily WTF: If his own code isn’t bad enough, he’ll probably try to fix yours.

    Nerd: Good news - rewrote the slowest part of you app in a day and now you only need 5% of your server farm; Bad news - he patched it live and left the code on a USB stick, at home.

    N00b: Can’t fix the problems your Nerd solves in his sleep, but keeps everything running smoothly.

    Rockstar developer: Rebuilt your whole app last week. Comes in Monday and presses one button that runs every acceptance test, deploys to the live servers, mails the output to the client and makes everyone a brew.
  • ALLOW A FEW SECONDS TO ABSORB THE CATEGORISATIONS

    AFTER CHART:
    Most of the practices lie in the good-discipline band, not in the high-skill band.

    This does NOT mean that using agile practices reduces your need for technical skill. It does NOT mean that having highly-skilled developers is not a big advantage. It DOES mean that a disciplined team of mediocre programmers has more chance of going agile than an errant bunch of über-geeks.
  • ALLOW A FEW SECONDS TO ABSORB THE CATEGORISATIONS

    AFTER CHART:
    Most of the practices lie in the good-discipline band, not in the high-skill band.

    This does NOT mean that using agile practices reduces your need for technical skill. It does NOT mean that having highly-skilled developers is not a big advantage. It DOES mean that a disciplined team of mediocre programmers has more chance of going agile than an errant bunch of über-geeks.
  • ALLOW A FEW SECONDS TO ABSORB THE CATEGORISATIONS

    AFTER CHART:
    Most of the practices lie in the good-discipline band, not in the high-skill band.

    This does NOT mean that using agile practices reduces your need for technical skill. It does NOT mean that having highly-skilled developers is not a big advantage. It DOES mean that a disciplined team of mediocre programmers has more chance of going agile than an errant bunch of über-geeks.
  • ALLOW A FEW SECONDS TO ABSORB THE CATEGORISATIONS

    AFTER CHART:
    Most of the practices lie in the good-discipline band, not in the high-skill band.

    This does NOT mean that using agile practices reduces your need for technical skill. It does NOT mean that having highly-skilled developers is not a big advantage. It DOES mean that a disciplined team of mediocre programmers has more chance of going agile than an errant bunch of über-geeks.
  • Encouraging Agile Discipline

    1. 1. Encouraging Agile Discipline Motivating developers to follow agile practices This work is released under the terms of the Ashley Moran Creative Commons Attribution-Share Alike licence PatchSpace Ltd
    2. 2. The Business Problem
    3. 3. The Business Problem You have have to upgrade your legacy software to keep your competitive advantage
    4. 4. The Business Problem You have have to upgrade your legacy software to keep your competitive advantage Upgrading your legacy software is taking too long - you’re falling behind and wasting money
    5. 5. The Business Problem You have have to upgrade your legacy software to keep your competitive advantage Upgrading your legacy software is taking too long - you’re falling behind and wasting money Software is a technical endeavour, so there’s a technical solution to your business problem
    6. 6. The Business Problem You have have to upgrade your legacy software to keep your competitive advantage Upgrading your legacy software is taking too long - you’re falling behind and wasting money Software is a technical endeavour, so there’s a technical solution to your business problem Right?
    7. 7. The Business Problem
    8. 8. Some Technical Solutions
    9. 9. Some Technical Solutions Move to a more powerful language Python, Ruby, Erlang, Smalltalk
    10. 10. Some Technical Solutions Move to a more powerful language Python, Ruby, Erlang, Smalltalk Create a more flexible architecture Marc Johnson: Laying Your Legacy to REST
    11. 11. Some Technical Solutions Move to a more powerful language Python, Ruby, Erlang, Smalltalk Create a more flexible architecture Marc Johnson: Laying Your Legacy to REST Go “Agile”
    12. 12. Some Technical Solutions
    13. 13. Our Example Problem
    14. 14. Our Example Problem We want our HTML web app available as a web service...
    15. 15. Our Example Problem We want our HTML web app available as a web service... ...but half of our business logic is in the JavaScript and half is on the server.
    16. 16. Our Example Problem We want our HTML web app available as a web service... ...but half of our business logic is in the JavaScript and half is on the server. We need to refactor our code
    17. 17. Our Example Problem We want our HTML web app available as a web service... ...but half of our business logic is in the JavaScript and half is on the server. We need to refactor our code We’re scared to refactor because previous attempts have broken other parts of our app
    18. 18. Our Example Problem We want our HTML web app available as a web service... ...but half of our business logic is in the JavaScript and half is on the server. We need to refactor our code We’re scared to refactor because previous attempts have broken other parts of our app to be continued...
    19. 19. The Underlying Problem
    20. 20. The Underlying Problem Software technologies don’t make you follow good practices, they just remove obstacles to them
    21. 21. The Underlying Problem Software technologies don’t make you follow good practices, they just remove obstacles to them You could have followed good practices with your old technologies
    22. 22. The Underlying Problem Software technologies don’t make you follow good practices, they just remove obstacles to them You could have followed good practices with your old technologies Fred Brooks wrote automated tests in the 1970s
    23. 23. The Underlying Problem Software technologies don’t make you follow good practices, they just remove obstacles to them You could have followed good practices with your old technologies Fred Brooks wrote automated tests in the 1970s You still have the same team of developers for the new application that you had for the old one
    24. 24. The Underlying Problem Software technologies don’t make you follow good practices, they just remove obstacles to them You could have followed good practices with your old technologies Fred Brooks wrote automated tests in the 1970s You still have the same team of developers for the new application that you had for the old one Some of them see the need to improve the process
    25. 25. The Underlying Problem Software technologies don’t make you follow good practices, they just remove obstacles to them You could have followed good practices with your old technologies Fred Brooks wrote automated tests in the 1970s You still have the same team of developers for the new application that you had for the old one Some of them see the need to improve the process Some of them don’t
    26. 26. The Underlying Problem
    27. 27. Our Example Problem ctnd.
    28. 28. Our Example Problem ctnd. ...we were left needing to refactor our code
    29. 29. Our Example Problem ctnd. ...we were left needing to refactor our code In order to refactor we need a comprehensive test suite
    30. 30. Our Example Problem ctnd. ...we were left needing to refactor our code In order to refactor we need a comprehensive test suite Why don’t we have one?
    31. 31. Our Example Problem ctnd. ...we were left needing to refactor our code In order to refactor we need a comprehensive test suite Why don’t we have one? Need unapparent?
    32. 32. Our Example Problem ctnd. ...we were left needing to refactor our code In order to refactor we need a comprehensive test suite Why don’t we have one? Need unapparent? Perceived lack of time?
    33. 33. Our Example Problem ctnd. ...we were left needing to refactor our code In order to refactor we need a comprehensive test suite Why don’t we have one? Need unapparent? Perceived lack of time? Apathy?
    34. 34. Our Example Problem ctnd. ...we were left needing to refactor our code In order to refactor we need a comprehensive test suite Why don’t we have one? Need unapparent? Perceived lack of time? Apathy? Oh shit, it’s too late
    35. 35. Our Example Problem ctnd. ...we were left needing to refactor our code In order to refactor we need a comprehensive test suite Why don’t we have one? Need unapparent? Perceived lack of time? Apathy? Oh shit, it’s too late If we tried to create one, would we be successful?
    36. 36. A Field Guide to Post-Legacy Developers
    37. 37. A Field Guide to Post-Legacy Developers Enthusiastic “The last project was slow and painful. I was here deploying at 2am on Friday night and we spent days firefighting the week after. I want to learn how to release software smoothly like the successful agile teams.”
    38. 38. A Field Guide to Post-Legacy Developers Enthusiastic “The last project was slow and painful. I was here deploying at 2am on Friday night and we spent days firefighting the week after. I want to learn how to release software smoothly like the successful agile teams.” Neutral “This agile thing sounds like it could work, but I’m not convinced. It seems like a lot of work for me. We already know our software works, why should we spend time refactoring and testing it?”
    39. 39. A Field Guide to Post-Legacy Developers Enthusiastic “The last project was slow and painful. I was here deploying at 2am on Friday night and we spent days firefighting the week after. I want to learn how to release software smoothly like the successful agile teams.” Neutral “This agile thing sounds like it could work, but I’m not convinced. It seems like a lot of work for me. We already know our software works, why should we spend time refactoring and testing it?” Lazy “Why should I learn agile? I’ve been programming the same way for years and I’m not going to change now.” “By the way it’s 5.30pm, I’m off home. Have fun with the deploy.”
    40. 40. A Field Guide to Post-Legacy Developers
    41. 41. Stick vs Carrot
    42. 42. Stick vs Carrot Are the members of your team enthusiastic, neutral, or lazy?
    43. 43. Stick vs Carrot Are the members of your team enthusiastic, neutral, or lazy? Will they try not to break the continuous integration server...
    44. 44. Stick vs Carrot Are the members of your team enthusiastic, neutral, or lazy? Will they try not to break the continuous integration server... because they want to to keep the code deployable?
    45. 45. Stick vs Carrot Are the members of your team enthusiastic, neutral, or lazy? Will they try not to break the continuous integration server... because they want to to keep the code deployable? or because they get shouted at?
    46. 46. Stick vs Carrot
    47. 47. Skill vs Discipline
    48. 48. Skill vs Discipline Technical skill Low High Poor Daily WTF Nerd Discipline Rockstar Good N00b developer
    49. 49. Skill vs Discipline Technical skill Low High Poor Daily WTF Nerd Discipline Rockstar Good N00b developer Do you need to move the team in this direction?
    50. 50. Skill vs Discipline Technical skill Low High Or do you Poor Daily WTF Nerd Discipline just need more nerds? Rockstar Good N00b developer Do you need to move the team in this direction?
    51. 51. Skill vs Discipline Or do you just need more nerds?
    52. 52. Skill vs Discipline
    53. 53. Agile Practices (not an exhaustive list)
    54. 54. Agile Practices (not an exhaustive list) Acceptance tests Automated deployments Unit tests Continuous integration Refactoring Simplicity / elegance Source control Collective ownership Knowledge sharing Coding standards
    55. 55. Agile Practices (not an exhaustive list)
    56. 56. Agile needs...
    57. 57. Agile needs... Technical skill Low High Poor Simplicity / elegance Discipline Continuous integration Source control Test-driven development Collective ownership Refactoring Good Coding standards Building deployment scripts Basic testing Building CI environments Using deployment scripts
    58. 58. Agile needs... Technical skill Low High Poor Simplicity / elegance Discipline Continuous integration Source control Test-driven development Collective ownership Refactoring Good Coding standards Building deployment scripts Basic testing Building CI environments Using deployment scripts Discipline is your initial bottle-neck to becoming agile
    59. 59. Agile needs...
    60. 60. The Underlying Solution
    61. 61. The Underlying Solution A highly-disciplined bunch of über-geeks
    62. 62. The Underlying Solution A highly-disciplined bunch of über-geeks If you are willing to pay 50k+ a head
    63. 63. The Underlying Solution A highly-disciplined bunch of über-geeks If you are willing to pay 50k+ a head Maybe
    64. 64. The Underlying Solution A highly-disciplined bunch of über-geeks If you are willing to pay 50k+ a head Maybe Maybe not
    65. 65. The Underlying Solution A highly-disciplined bunch of über-geeks If you are willing to pay 50k+ a head Maybe Maybe not To upgrade your code from legacy to agile, upgrade your team from legacy to agile
    66. 66. The Underlying Solution

    ×