6 ms·

I still think it ironic that when looking at the actual Agile manifesto at http://agilemanifesto.org/ http://agilemanifesto.org/ (which is short and uncomplicat

I still think it ironic that when looking at the actual Agile manifesto at http://agilemanifesto.org/ http://agilemanifesto.org/ (which is short and uncomplicated), that the first line is "Individuals and interactions over processes and tools" and these days practicing agile, at least in a big-house corporate environment feels like anything but.

philbarr 9y ago
Absolutely - some people hear, "people before process", think it sounds great, then immediately go looking for a process to implement it and find Scrum.
- crdoconnor 9y ago
  I think that's largely the fault of the manifesto. It is entirely unclear about what putting "individuals before process" actually means. One way I've seen it used was as a way to justify organizing meetings as a means to solve an increase in defect regressions rather than allocating extra work on automated tests. The former was "individuals and interactions" and the latter was tools and processes. I thought it was a reasonable interpretation and also wrong.
ionforce 9y ago
Maybe people are ultimately imperfect and others are looking to process to smooth over those imperfections.
jt2190 9y ago
The Agile Manifesto suffers from "the curse of knowledge": The signatories are all very experienced, and deeply understand all of the differences between projects and people and when to be flexible and when to be rigid, and they know that it's important to not specify a method for every situation. But there are many, many people entering the software industry who don't have their years of experience, and who need very clear, basic instructions as a starting point, and hence Scrum steps in to fill the gap. What's unfortunate is that scrum isn't a program for developing software managers from rigid, by-the-book managers into experienced, agile managers: Instead it encourages newbie practices for everyone, forever.
- tootie 9y ago
  Exactly. I look at it as following the Dreyfus Model. If you don't know what agile delivery looks like or how to approach it, you start with Scrum and follow it religiously. Once you get the feel and the team is accustomed, you can modify it to suit your needs or just wing it and keep the goals in mind.
  - stephenhuey 9y ago
    Hear hear! Scrum predates Agile. It welcomes mixing in other tools as needed, e.g. XP, Agile, etc. After 15 years of professional software development, I just picked up a scrum master certificate a couple days ago after my employer paid for the class. I'd rather see teams using scrum than just winging it unless they are provably experienced or extraordinarily competent. Individuals can be good at their work but it's often difficult to get everything in sync on a team, or even if the team is super amazing the complexity of getting things done in a corporate environment with lots of moving parts and dependencies is usually aided by using tools such as scrum. Even when a complex corporate environment commits to trying to follow it, it's still a struggle to get the basic elements of scrum adhered to (enough time with product owner, enough time figuring out dependencies, any time at all spent identifying ways the team could do better in the future and reduce friction, impediments, or needless work). Take a look at the Scrum Guide - I'd be satisfied if just the few events in the minimal scrum framework could be fit in, but often not even that happens. * edit: provably
  - lowbloodsugar 9y ago
    Unfortunately, what teams do religiously is the process, contrary to the manifesto. So they put a Scrum Master pin on someone, they do Sprints and burndowns. They cargo cult. I did my first CSM course with Ken Schwaber. I did another recently with someone else. The recent course was all process. Ken's course was mostly "why". Jeff Sutherland said there are three things that must be true for a team to be a Scrum team: 1. It must be self-governing. 2. The team members must be on the team 100% 3. The team members must stay for the duration. With the exception of start-ups, I've seen maybe one team which met these criteria. But they all had sprints. And of course, they were all held to their commitment. Scrum is now a tool for management to death march people. Think of all these metrics that management measures scrum teams on. Can you imagine any of these teams turning around and saying, "We're going to measure how many of your bullshit wishlist items meet the definition of an actionable story when presented in sprint planning, and how many hours are wasted?" Of course not. Management can't abide a team that meets rule 1. "I'm a manager! I must manage! What is my job if my teams are self managing?!" Scrum, as Ken Schwaber describes it, is a fantastic way to develop product. Unfortunately, if you are in an organization that would truly let you do Scrum, then you probably don't need it. You are already qualified, experienced and empowered. If its a hundred twenty-year-olds being told to "do scrum", it probably ain't Scrum.
rileymat2 9y ago
> That is, while there is value in the items on the right, we value the items on the left more.
weego 9y ago
I worked at a large consultancy in the UK where the platform team were 'agile' in that they had 2 week sprints, but those 2 week sprint goals were fixed for months ahead. If you needed a small API addition or specific bug fix in one of your apps (elearning courses) to launch a product on the platform and you hadn't foreseen this 2 months+ in advance then you were out of luck (unless you had leverage on one of the platform team higher ups of course). That was my first introduction to uppercase A for Agile. Ultimately the wider business never changes in terms of it wants predictable delivery and deadline forecasts, but internally they have to then wedge some version of lowercase a for agile into that because the benefits day to day are there so you have this clunky enterprise friendly version that poorly tries to get best of both.
- sorokod 9y ago
  In my experience this kind of Agile inevitably emerges when the desire to be agile is limited to a (small) subset of the organisation.
wnevets 9y ago
Trying to explain this to people who are "certified" is exhausting.
dlezama 9y ago
Well, nobody makes money by pointing at the manifesto. But a whole business can be built around "certification" and all that.
chris11 9y ago
On another note, what metrics could be commonly used to judge individual dev productivity, and should they be used? I'm wondering because I have had places bring up metrics like average story points completed per sprint in performance reviews. Which kind of confused me when numbers for our team seemed to be doing fine, and it seemed like my work was going well based off of previous conversations with management.
- mangodrunk 9y ago
  In my experience, using story points to judge performance is typically not useful. It is a very simplistic view. It doesn't include the quality of the code. And who knows if the estimation was accurate. And then you can have story point inflation. Also, someone may figure out an easier less complicated solution for a problem, and so that would have a smaller story point, which is better. I would be curious in hearing how people judge dev productivity as well, it's something that I don't like to just use a number, though there may be some benefit in having that being a small part of the judgement.

philbarr 9y ago

Absolutely - some people hear, "people before process", think it sounds great, then immediately go looking for a process to implement it and find Scrum.

crdoconnor 9y ago
I think that's largely the fault of the manifesto. It is entirely unclear about what putting "individuals before process" actually means. One way I've seen it used was as a way to justify organizing meetings as a means to solve an increase in defect regressions rather than allocating extra work on automated tests. The former was "individuals and interactions" and the latter was tools and processes. I thought it was a reasonable interpretation and also wrong.

ionforce 9y ago

Maybe people are ultimately imperfect and others are looking to process to smooth over those imperfections.

jt2190 9y ago

The Agile Manifesto suffers from "the curse of knowledge": The signatories are all very experienced, and deeply understand all of the differences between projects and people and when to be flexible and when to be rigid, and they know that it's important to not specify a method for every situation. But there are many, many people entering the software industry who don't have their years of experience, and who need very clear, basic instructions as a starting point, and hence Scrum steps in to fill the gap. What's unfortunate is that scrum isn't a program for developing software managers from rigid, by-the-book managers into experienced, agile managers: Instead it encourages newbie practices for everyone, forever.

tootie 9y ago
Exactly. I look at it as following the Dreyfus Model. If you don't know what agile delivery looks like or how to approach it, you start with Scrum and follow it religiously. Once you get the feel and the team is accustomed, you can modify it to suit your needs or just wing it and keep the goals in mind.
- stephenhuey 9y ago
  Hear hear! Scrum predates Agile. It welcomes mixing in other tools as needed, e.g. XP, Agile, etc. After 15 years of professional software development, I just picked up a scrum master certificate a couple days ago after my employer paid for the class. I'd rather see teams using scrum than just winging it unless they are provably experienced or extraordinarily competent. Individuals can be good at their work but it's often difficult to get everything in sync on a team, or even if the team is super amazing the complexity of getting things done in a corporate environment with lots of moving parts and dependencies is usually aided by using tools such as scrum. Even when a complex corporate environment commits to trying to follow it, it's still a struggle to get the basic elements of scrum adhered to (enough time with product owner, enough time figuring out dependencies, any time at all spent identifying ways the team could do better in the future and reduce friction, impediments, or needless work). Take a look at the Scrum Guide - I'd be satisfied if just the few events in the minimal scrum framework could be fit in, but often not even that happens. * edit: provably
- lowbloodsugar 9y ago
  Unfortunately, what teams do religiously is the process, contrary to the manifesto. So they put a Scrum Master pin on someone, they do Sprints and burndowns. They cargo cult. I did my first CSM course with Ken Schwaber. I did another recently with someone else. The recent course was all process. Ken's course was mostly "why". Jeff Sutherland said there are three things that must be true for a team to be a Scrum team: 1. It must be self-governing. 2. The team members must be on the team 100% 3. The team members must stay for the duration. With the exception of start-ups, I've seen maybe one team which met these criteria. But they all had sprints. And of course, they were all held to their commitment. Scrum is now a tool for management to death march people. Think of all these metrics that management measures scrum teams on. Can you imagine any of these teams turning around and saying, "We're going to measure how many of your bullshit wishlist items meet the definition of an actionable story when presented in sprint planning, and how many hours are wasted?" Of course not. Management can't abide a team that meets rule 1. "I'm a manager! I must manage! What is my job if my teams are self managing?!" Scrum, as Ken Schwaber describes it, is a fantastic way to develop product. Unfortunately, if you are in an organization that would truly let you do Scrum, then you probably don't need it. You are already qualified, experienced and empowered. If its a hundred twenty-year-olds being told to "do scrum", it probably ain't Scrum.

rileymat2 9y ago

> That is, while there is value in the items on the right, we value the items on the left more.

weego 9y ago

I worked at a large consultancy in the UK where the platform team were 'agile' in that they had 2 week sprints, but those 2 week sprint goals were fixed for months ahead. If you needed a small API addition or specific bug fix in one of your apps (elearning courses) to launch a product on the platform and you hadn't foreseen this 2 months+ in advance then you were out of luck (unless you had leverage on one of the platform team higher ups of course). That was my first introduction to uppercase A for Agile. Ultimately the wider business never changes in terms of it wants predictable delivery and deadline forecasts, but internally they have to then wedge some version of lowercase a for agile into that because the benefits day to day are there so you have this clunky enterprise friendly version that poorly tries to get best of both.

sorokod 9y ago
In my experience this kind of Agile inevitably emerges when the desire to be agile is limited to a (small) subset of the organisation.

wnevets 9y ago

Trying to explain this to people who are "certified" is exhausting.

dlezama 9y ago

Well, nobody makes money by pointing at the manifesto. But a whole business can be built around "certification" and all that.

chris11 9y ago

On another note, what metrics could be commonly used to judge individual dev productivity, and should they be used? I'm wondering because I have had places bring up metrics like average story points completed per sprint in performance reviews. Which kind of confused me when numbers for our team seemed to be doing fine, and it seemed like my work was going well based off of previous conversations with management.

mangodrunk 9y ago
In my experience, using story points to judge performance is typically not useful. It is a very simplistic view. It doesn't include the quality of the code. And who knows if the estimation was accurate. And then you can have story point inflation. Also, someone may figure out an easier less complicated solution for a problem, and so that would have a smaller story point, which is better. I would be curious in hearing how people judge dev productivity as well, it's something that I don't like to just use a number, though there may be some benefit in having that being a small part of the judgement.