10 ms·

When I took over development of a extremely dysfunctional engeering team at an established startup with 100 people, the first thing I did (after watching for a

When I took over development of a extremely dysfunctional engeering team at an established startup with 100 people, the first thing I did (after watching for a bit to learn) was put in scrum. It worked. And it worked really, really well. 2 years later, it didn't work anymore. The team had matured, the organization itself had adapted to the leaner processes and mindset and, in time, the actual scrum process was too much. It was time to change again... And that is something I think most agile advocates don't realize. Agile should be viewed as an organizational tool that has prescripted and prescribed rules that work in general, but maybe don't work in the specific. It is great if you need something forceful with books or documentation in the beginning, but in time, the organization should mature to the point where agile/scrum/whatever is actually too much. One last thought. I highly recommend people look at agile for the times when you need a drop in process....but there is absolutely no subsitute for hiring quality people capable of making good decisions. Agile will get more out of bad developers, IMO, but having nothing and good developers you trust is always going to be more productive.

m_st 14y ago
I fully agree with your post. But do mind sharing what process you changed to then? Did it and does it still work?
sandGorgon 14y ago
That was an excellent observation. I like to explain the phenomenon you observed using queuing theory - As time went on, each of you (and you yourself) were able to estimate tasks very, very accurately. I'd like to think that this was a period of low attrition.. but even if it was not, you were able to model the behavior of a 100 employees (a large enough set) to come up with good estimates. An agile/scrum process is designed to work with tasks of inaccurate estimates - the whole business of story points is designed around that fact. Since your underlying phenomenon changed, the process was no longer optimal. I'm not sure if you experimented with your own "lean" inventions beyond agile - single queues, multiple queues, queues with an artificial stop signal to reduce variance, etc. - but it would have been interesting.
debacle 14y ago
I think your last point is key. You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one.
- brazzy 14y ago
  That's cowboy programmer bullshit., the kind of thing mediocre but cocky programmers tell themselves to justify primadonna behaviour "having nothing and good developers you trust" is either a recipe for disaster, or a short prelude to those good developers coming up with a minimal ad hoc process that fits the project and most likely is remarkably similar to one established Agile methodology or another.
  - debacle 14y ago
    I completely disagree [1]. There's a difference between a cowboy programmer and a programmer that can go more than a day or two without checking in with his superior. In my personal opinion, based on the level of intelligence required to do good programming, the best programmers are self-managing. As a corollary to that, it's too expensive to hire development managers (in the traditional "management" sense) that can actually add value. Good programmers are that good. [1] I've fired every cowboy coder that ever worked for me except one.
    - brazzy 14y ago
      Actually, you completely agree with me. A Scrum Team very explicitly is self-managing. Agile processes ARE frameworks for coordinating self-management at the team level, and which have been found to work repeatably. That doesn't mean a given one will work everywhere. Specifically, Scrum is probably not ideal for startups doing something truly new, since it assumes there is someone who can prioritize features by their business value.
      - oinksoft 14y ago
        Why would you tell somebody that they completely agree with you when they just said that they disagreed? That's so rude. You say "That's cowboy programmer bullshit", he says "I completely disagree." Do you really think there's a chance he secretly agrees that his view is "cowboy programmer bullshit"?
boomzilla 14y ago
Agreed. When you don't have collective excellence anymore, you are left with process.
shaunxcode 14y ago
Agile should also be subject to Agile. I like to think of it in terms of the Viable System Model in which the system has the potential to change itself based upon feedback. Put another way - make sure your implementation of Agile/Scrum supports tail call optimization and macro expansion or face the reality of being stuck in BlubScrum.
- gutnor 14y ago
  Agile is a toolbox of best practices and tricks. You need to use the ones that make sense. That is formalised in methodologies like SCRUM by doing a retrospective after each sprint. For inexperimented teams, it is a good idea to start with out-of-the-box scrum and remove/replace bits that are not working out for team after a while. For experimented teams, you just start with just a daily scrum end of day and add bits as you go along. (effectively start with 1 day iteration)
- adrianhoward 14y ago
  Agile should also be subject to Agile It is (or should be). For example: * XP folk very explicitly state that you shouldn't be "doing XP" N months down the road. You should be optimising your process * The Kanban/Lean folks whole method is about having a process for process improvement * Scrum very explicitly has Sprint retrospective and reviews aimed at looking what happened and changing the process to improve results next time. * Crystal is all about aligning the amount of process you do to the working context you're in. Of all the agile processes Scrum is really the only one that says you must do certain things in a certain way - and even there it's a very light framework of five events and three artefacts) that gives you a space to figure out your own process in.
shanemhansen 14y ago
Respectfully, I think that an established startup with 100 people is a bit of an oxymoron. I know that no company ever wants to think of itself as "big and established", in fact my previous company had been around for 13 years, had hundreds of millions in revenue and almost 1k employees and they still liked to pretend they were a disruptive startup.

m_st 14y ago

I fully agree with your post. But do mind sharing what process you changed to then? Did it and does it still work?

sandGorgon 14y ago

That was an excellent observation. I like to explain the phenomenon you observed using queuing theory - As time went on, each of you (and you yourself) were able to estimate tasks very, very accurately. I'd like to think that this was a period of low attrition.. but even if it was not, you were able to model the behavior of a 100 employees (a large enough set) to come up with good estimates. An agile/scrum process is designed to work with tasks of inaccurate estimates - the whole business of story points is designed around that fact. Since your underlying phenomenon changed, the process was no longer optimal. I'm not sure if you experimented with your own "lean" inventions beyond agile - single queues, multiple queues, queues with an artificial stop signal to reduce variance, etc. - but it would have been interesting.

debacle 14y ago

I think your last point is key. You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one.

brazzy 14y ago
That's cowboy programmer bullshit., the kind of thing mediocre but cocky programmers tell themselves to justify primadonna behaviour "having nothing and good developers you trust" is either a recipe for disaster, or a short prelude to those good developers coming up with a minimal ad hoc process that fits the project and most likely is remarkably similar to one established Agile methodology or another.
- debacle 14y ago
  I completely disagree [1]. There's a difference between a cowboy programmer and a programmer that can go more than a day or two without checking in with his superior. In my personal opinion, based on the level of intelligence required to do good programming, the best programmers are self-managing. As a corollary to that, it's too expensive to hire development managers (in the traditional "management" sense) that can actually add value. Good programmers are that good. [1] I've fired every cowboy coder that ever worked for me except one.
  - brazzy 14y ago
    Actually, you completely agree with me. A Scrum Team very explicitly is self-managing. Agile processes ARE frameworks for coordinating self-management at the team level, and which have been found to work repeatably. That doesn't mean a given one will work everywhere. Specifically, Scrum is probably not ideal for startups doing something truly new, since it assumes there is someone who can prioritize features by their business value.
    - oinksoft 14y ago
      Why would you tell somebody that they completely agree with you when they just said that they disagreed? That's so rude. You say "That's cowboy programmer bullshit", he says "I completely disagree." Do you really think there's a chance he secretly agrees that his view is "cowboy programmer bullshit"?

boomzilla 14y ago

Agreed. When you don't have collective excellence anymore, you are left with process.

shaunxcode 14y ago

Agile should also be subject to Agile. I like to think of it in terms of the Viable System Model in which the system has the potential to change itself based upon feedback. Put another way - make sure your implementation of Agile/Scrum supports tail call optimization and macro expansion or face the reality of being stuck in BlubScrum.

gutnor 14y ago
Agile is a toolbox of best practices and tricks. You need to use the ones that make sense. That is formalised in methodologies like SCRUM by doing a retrospective after each sprint. For inexperimented teams, it is a good idea to start with out-of-the-box scrum and remove/replace bits that are not working out for team after a while. For experimented teams, you just start with just a daily scrum end of day and add bits as you go along. (effectively start with 1 day iteration)
adrianhoward 14y ago
Agile should also be subject to Agile It is (or should be). For example: * XP folk very explicitly state that you shouldn't be "doing XP" N months down the road. You should be optimising your process * The Kanban/Lean folks whole method is about having a process for process improvement * Scrum very explicitly has Sprint retrospective and reviews aimed at looking what happened and changing the process to improve results next time. * Crystal is all about aligning the amount of process you do to the working context you're in. Of all the agile processes Scrum is really the only one that says you must do certain things in a certain way - and even there it's a very light framework of five events and three artefacts) that gives you a space to figure out your own process in.

shanemhansen 14y ago

Respectfully, I think that an established startup with 100 people is a bit of an oxymoron. I know that no company ever wants to think of itself as "big and established", in fact my previous company had been around for 13 years, had hundreds of millions in revenue and almost 1k employees and they still liked to pretend they were a disruptive startup.