6 ms·

Agile Development: A quickstart guide to doing it right

70 points by glenngillen 16y ago

Reclix 16y ago
Great article, but what if you're a BA with a great idea and super low budget? You can either: a) Learn to develop applications on your own (potentially slowing your time to market and reducing product quality) b) Develop the requirements and hire someone else to build it (cheaply and effectively if you've got a good team in India) c) Take on a developer as a partner (diluting equity and who knows if he's the right guy for the job until you've learned more about the nature of the solution needed?) My contention is that its not worth diluting equity with an additional partner until you've put out a product yourself that tests of all your original assumptions.
- glenngillen 16y ago
  In that scenario, you're not a BA you're the customer because you want your idea developed. So hire a competent developer to make that idea come to life. The core problems with being a BA are the same, you'll skew the implementation with your own pre-conceived notions of how you think things should be done. Given you're not capable of doing the work, you really shouldn't have any input on that. I don't tell my accountant how to do their job, despite having numerous opinions on how things should be structured. She takes my input on board, and tells me what I should actually be doing. How you decide to remunerate them is an entirely different problem.
atldev 16y ago
Good stuff. I plan to share this with each development manager on my team. We've learned many of these lessons the hard way. Others, we've decided not to pursue. For example, we have found working together in a team room is extremely helpful when working through a new model design, etc. So we have a 3 days in, 2 days virtual model. Along the lines of removing technology, we've enjoyed using a mockup tool (like Peldi's Balsamiq or Mockingbird) for capturing story flows and wireframes. I know it's tech, but these tools do such a good job of removing the tech it's barely visible. And from the article, a diagram that captures the idea behind MVP fairly well: http://rubypond.com/images/scheduling-stories.png http://rubypond.com/images/scheduling-stories.png
DanielBMarkham 16y ago
Throw out the tools you’re using I'd like to underline this about a thousand times. (disclaimer: I teach agile to teams) What I see over and over again is folks picking up agile and a) getting too religious about it, and b) immediately making it 5 zillion times more complicated than it has to be. Usually with the use of tools (but creative minds have been known to create manual monstrosities) If I could eliminate people who already know everything (either pro or con) and folks who for some reason want to complicate everything? Life would be a lot easier for agile teams. I saw a guy once -- no shit -- that had created a 20-tab spreadsheet to "do" agile. Each sprint close he forced the team to sit down while he went through each item on a projector. Their backlog had 600 items in it. It was like taking a big dump truck with manure and just covering the team in it. I insisted they move to a physical storyboard, and when I checked up with them a few weeks later they had this storyboard that looked like the wiring diagram for a 57 Chevy. Colors and lines and tags and color-coded cards. Agile is easy, but it's possible to screw it up if you keep trying hard enough. Start simple and then add what you need.
- aminuit 16y ago
  (disclaimer: Agile consultants ruined the software group I work in.) Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up.
  - SkyMarshal 16y ago
    Convicting one for the sins of others?
    - aminuit 16y ago
      Ever notice that virtually all Agile success stories are written by Agile consultants and not by developers? Ever notice that nobody actually claims to have built anything from scratch with Agile? The stories all read the same. Product has already been built. Developers stuck bike shedding over some piddly detail, when lo and behold the Agile consultant arrives to cut through the Gordian knot by placing the developers on a strict regimen of myopic thinking and inattention to detail. Agile is bullshit.
projectileboy 16y ago
Some good stuff in here, but I was reminded of Paul Buchheit's classic statement: limited life experience + overgeneralization = advice
hello_moto 16y ago
The hardest part of doing Agile is to change the mindset of the people. They're used to working in an iterative/mini-waterfall schedule and used to be bounded by "processes". With Agile, suddenly there are less "processes" even though there are still some things that they should follow (TDD, Continuous Integration, always have test automation in many levels, etc).
- rmc00 16y ago
  Is this not the point of RUP? To create an iterative, agile methodology that looks like a waterfall at a high level? I think the problem you define is the exact reason that RUP becoming so popular, but I admit that I may misunderstand.
dolinsky 16y ago
The only piece that I would add to this article is the concept of a daily morning scrum. For virtual teams this can be accomplished via Campfire. For those who don't know about a daily scrum, the idea is that you take 5-15 minutes (the shorter the time the better) first thing in the morning and everybody goes through briefly 1) What they did yesterday 2) What they're working on today 3) Anyone they need to sit down with to help them become unblocked / discuss a feature with. Doing so every morning is a great way to keep everyone on the same page and provides a good balance between autonomous time and keeping everyone on the same page. Doing this meeting while standing helps to keep the meeting short and to the point, and if you find yourself engaging in discussion about a particular feature / item / issue..."take it offline". Don't use everyone's time to discuss something that should be discussed at a later time when everyone else could be in flow.
- glenngillen 16y ago
  Definitely an oversight! Cheers, I'll add it in.
- cycojesus 16y ago
  I find the daily morning scrum meeting a major "zone killer". It's completely orthogonal to how I function that I often spend a major part of the day just recovering from it. I arrive in the office ready to roll, motivated, head full of ideas that have matured during the night, breakfast and commute. I can litterally arrive, sit down and crank out code (or whatever task is on). And then it's daily morning scrum meeting, and even that 5 or 10 minutes (when done right, a thing I've never seen with my own eyes) totally kills this mental state. 99% of the time my task is self-sufficient enough that what other team members do is completely irrelevant to me and I rarely have any insight to give them either. And I don't remember nor even care what I did yesterday, it's done, forgotten, check the SVN commit logs if you want to know about it. So I zone out, then the meeting is over and I've half-forgotten what I was doing so it's time to look at the latest meme on reddit. I'd gladly settle for a daily _evening_ scrum meeting: - What did you do today? - What bothered you? - What will you do tomorrow? put that in the back of my mind and go home, I'm sure I'll have sorted things during the night to be useful tomorrow.
ams6110 16y ago
I can't endorse putting developers and customers directly together. In my experience, customers view developers as something between magicians and freaks. Many will not take seriously a developer in sandals, shorts and a a T-shirt with some kind of geeky slogan. Developers on the other hand, often lack the patience and tact to work directly with people who don't understand technology at their level. They tend to divert the conversation to the "interesting" problems that they want to work on and conveniently don't discuss the details of all the reports that the system needs to produce. When developers and customers get together, they talk past each other because they're almost speaking different languages. Or they get sidetracked on minutia and lose sight of the larger goals. There is definitely a place for a person who can be comfortable in a business suit talking to customers, understanding their needs and priorities in their terms, and then translating that into user stories (often with developer assistance) back at the office.
- geebee 16y ago
  I'd be very unhappy working in an environment like the one you described. I consider myself a developer, but I've worked directly with customers most of my career. If I were cut off from that, and had a BA standing between me and the end user/customer, I'm sure the resulting product would suffer. It's no surprise that we'd come to such different conclusions. I think that a dev who is capable of working well with customers would be so frustrated with a BA that he'd quit, or (more likely) never take the job in the first place. So it isn't random chance that you never meet these developers - they're probably avoiding the kind of organizations you work for. I'm not saying you don't work with talented programmers, I'm just saying that a BA-heavy workplace that probably filters out the kind of developer who has the patience and tact to work with customers.

70 points by glenngillen 16y ago

Great article, but what if you're a BA with a great idea and super low budget? You can either: a) Learn to develop applications on your own (potentially slowing your time to market and reducing product quality) b) Develop the requirements and hire someone else to build it (cheaply and effectively if you've got a good team in India) c) Take on a developer as a partner (diluting equity and who knows if he's the right guy for the job until you've learned more about the nature of the solution needed?) My contention is that its not worth diluting equity with an additional partner until you've put out a product yourself that tests of all your original assumptions.

glenngillen 16y ago
In that scenario, you're not a BA you're the customer because you want your idea developed. So hire a competent developer to make that idea come to life. The core problems with being a BA are the same, you'll skew the implementation with your own pre-conceived notions of how you think things should be done. Given you're not capable of doing the work, you really shouldn't have any input on that. I don't tell my accountant how to do their job, despite having numerous opinions on how things should be structured. She takes my input on board, and tells me what I should actually be doing. How you decide to remunerate them is an entirely different problem.

atldev 16y ago

Good stuff. I plan to share this with each development manager on my team. We've learned many of these lessons the hard way. Others, we've decided not to pursue. For example, we have found working together in a team room is extremely helpful when working through a new model design, etc. So we have a 3 days in, 2 days virtual model. Along the lines of removing technology, we've enjoyed using a mockup tool (like Peldi's Balsamiq or Mockingbird) for capturing story flows and wireframes. I know it's tech, but these tools do such a good job of removing the tech it's barely visible. And from the article, a diagram that captures the idea behind MVP fairly well: http://rubypond.com/images/scheduling-stories.png http://rubypond.com/images/scheduling-stories.png

DanielBMarkham 16y ago

Throw out the tools you’re using I'd like to underline this about a thousand times. (disclaimer: I teach agile to teams) What I see over and over again is folks picking up agile and a) getting too religious about it, and b) immediately making it 5 zillion times more complicated than it has to be. Usually with the use of tools (but creative minds have been known to create manual monstrosities) If I could eliminate people who already know everything (either pro or con) and folks who for some reason want to complicate everything? Life would be a lot easier for agile teams. I saw a guy once -- no shit -- that had created a 20-tab spreadsheet to "do" agile. Each sprint close he forced the team to sit down while he went through each item on a projector. Their backlog had 600 items in it. It was like taking a big dump truck with manure and just covering the team in it. I insisted they move to a physical storyboard, and when I checked up with them a few weeks later they had this storyboard that looked like the wiring diagram for a 57 Chevy. Colors and lines and tags and color-coded cards. Agile is easy, but it's possible to screw it up if you keep trying hard enough. Start simple and then add what you need.

aminuit 16y ago
(disclaimer: Agile consultants ruined the software group I work in.) Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up.
- SkyMarshal 16y ago
  Convicting one for the sins of others?
  - aminuit 16y ago
    Ever notice that virtually all Agile success stories are written by Agile consultants and not by developers? Ever notice that nobody actually claims to have built anything from scratch with Agile? The stories all read the same. Product has already been built. Developers stuck bike shedding over some piddly detail, when lo and behold the Agile consultant arrives to cut through the Gordian knot by placing the developers on a strict regimen of myopic thinking and inattention to detail. Agile is bullshit.

projectileboy 16y ago

Some good stuff in here, but I was reminded of Paul Buchheit's classic statement: limited life experience + overgeneralization = advice

hello_moto 16y ago

The hardest part of doing Agile is to change the mindset of the people. They're used to working in an iterative/mini-waterfall schedule and used to be bounded by "processes". With Agile, suddenly there are less "processes" even though there are still some things that they should follow (TDD, Continuous Integration, always have test automation in many levels, etc).

rmc00 16y ago
Is this not the point of RUP? To create an iterative, agile methodology that looks like a waterfall at a high level? I think the problem you define is the exact reason that RUP becoming so popular, but I admit that I may misunderstand.

dolinsky 16y ago

The only piece that I would add to this article is the concept of a daily morning scrum. For virtual teams this can be accomplished via Campfire. For those who don't know about a daily scrum, the idea is that you take 5-15 minutes (the shorter the time the better) first thing in the morning and everybody goes through briefly 1) What they did yesterday 2) What they're working on today 3) Anyone they need to sit down with to help them become unblocked / discuss a feature with. Doing so every morning is a great way to keep everyone on the same page and provides a good balance between autonomous time and keeping everyone on the same page. Doing this meeting while standing helps to keep the meeting short and to the point, and if you find yourself engaging in discussion about a particular feature / item / issue..."take it offline". Don't use everyone's time to discuss something that should be discussed at a later time when everyone else could be in flow.

glenngillen 16y ago
Definitely an oversight! Cheers, I'll add it in.
cycojesus 16y ago
I find the daily morning scrum meeting a major "zone killer". It's completely orthogonal to how I function that I often spend a major part of the day just recovering from it. I arrive in the office ready to roll, motivated, head full of ideas that have matured during the night, breakfast and commute. I can litterally arrive, sit down and crank out code (or whatever task is on). And then it's daily morning scrum meeting, and even that 5 or 10 minutes (when done right, a thing I've never seen with my own eyes) totally kills this mental state. 99% of the time my task is self-sufficient enough that what other team members do is completely irrelevant to me and I rarely have any insight to give them either. And I don't remember nor even care what I did yesterday, it's done, forgotten, check the SVN commit logs if you want to know about it. So I zone out, then the meeting is over and I've half-forgotten what I was doing so it's time to look at the latest meme on reddit. I'd gladly settle for a daily _evening_ scrum meeting: - What did you do today? - What bothered you? - What will you do tomorrow? put that in the back of my mind and go home, I'm sure I'll have sorted things during the night to be useful tomorrow.

ams6110 16y ago

I can't endorse putting developers and customers directly together. In my experience, customers view developers as something between magicians and freaks. Many will not take seriously a developer in sandals, shorts and a a T-shirt with some kind of geeky slogan. Developers on the other hand, often lack the patience and tact to work directly with people who don't understand technology at their level. They tend to divert the conversation to the "interesting" problems that they want to work on and conveniently don't discuss the details of all the reports that the system needs to produce. When developers and customers get together, they talk past each other because they're almost speaking different languages. Or they get sidetracked on minutia and lose sight of the larger goals. There is definitely a place for a person who can be comfortable in a business suit talking to customers, understanding their needs and priorities in their terms, and then translating that into user stories (often with developer assistance) back at the office.

geebee 16y ago
I'd be very unhappy working in an environment like the one you described. I consider myself a developer, but I've worked directly with customers most of my career. If I were cut off from that, and had a BA standing between me and the end user/customer, I'm sure the resulting product would suffer. It's no surprise that we'd come to such different conclusions. I think that a dev who is capable of working well with customers would be so frustrated with a BA that he'd quit, or (more likely) never take the job in the first place. So it isn't random chance that you never meet these developers - they're probably avoiding the kind of organizations you work for. I'm not saying you don't work with talented programmers, I'm just saying that a BA-heavy workplace that probably filters out the kind of developer who has the patience and tact to work with customers.