Cargo Cult Agile (2008)(jamesshore.com)
jamesshore.com
Cargo Cult Agile (2008)
http://www.jamesshore.com/Blog/Cargo-Cult-Agile.html
111 comments
This matches my experience, although I was lucky that I stopped doing "Agile transitions" gigs early enough. My question is: how do you discuss this with a customer?
At one point I had a talk with a director of a smaller bank, and he was enthusiastic to bring me on board, even wanted to pay me just to spend my workday in the office doing nothing specifically. I declined, because it was a lost cause: their team was too fragmented, their processes were too convoluted, their estimate for a very minor change added up to several months...
Yet, I felt bad about it, because I wanted to help them, but in that environment, I was not able to do anything. How do you approach such situations?
At one point I had a talk with a director of a smaller bank, and he was enthusiastic to bring me on board, even wanted to pay me just to spend my workday in the office doing nothing specifically. I declined, because it was a lost cause: their team was too fragmented, their processes were too convoluted, their estimate for a very minor change added up to several months...
Yet, I felt bad about it, because I wanted to help them, but in that environment, I was not able to do anything. How do you approach such situations?
Well, this is very hard. It is more frustrating with bigger companies.
In one occasion, where they officially brought me in as an agile coach, I tried to at least achieve some local optimum with the team, because some big improvements were plain impossible. I occasionally talked to managers about all the walls we were constantly hitting, but the answer was always "we can never change that in this company". This did not stop me from mentioning the problems, though.
Most company actually hire me as a technical coach or as a developer. There it is easier: When changing the way the team works is not officially my responsibility, I will still mention things that could be done better. But when the company does not listen to me, it is easier to let go: Then I'll just focus again on helping the team dealing with their legacy code monster (or whatever else I was hired to do).
So, in short, my strategy of dealing with it: Never give up mentioning problems and trying to establish a culture of continuous improvement with small experiments. But don't get too frustrated when they don't listen.
Also, often they do listen, and things get a little bit better ;)
How do you deal with those situations? Do you have a different strategy? What could I try to do differently?
In one occasion, where they officially brought me in as an agile coach, I tried to at least achieve some local optimum with the team, because some big improvements were plain impossible. I occasionally talked to managers about all the walls we were constantly hitting, but the answer was always "we can never change that in this company". This did not stop me from mentioning the problems, though.
Most company actually hire me as a technical coach or as a developer. There it is easier: When changing the way the team works is not officially my responsibility, I will still mention things that could be done better. But when the company does not listen to me, it is easier to let go: Then I'll just focus again on helping the team dealing with their legacy code monster (or whatever else I was hired to do).
So, in short, my strategy of dealing with it: Never give up mentioning problems and trying to establish a culture of continuous improvement with small experiments. But don't get too frustrated when they don't listen.
Also, often they do listen, and things get a little bit better ;)
How do you deal with those situations? Do you have a different strategy? What could I try to do differently?
> Never give up mentioning problems
I've tried this strategy, but it just comes off as whining. People's reactions tend to be "we all know that's a problem, but what's the fix? None of us have any power to apply any fixes."
The essential strategy to make a company more agile is to a) spend some time at the bottom, to understand how daily processes aren't agile and are broken up by the organization's silos, b) explain how the organization isn't agile to executives, until finally c) you and the executives talk to middle management together and start to take on the middle-management fiefdoms.
The very good reason why Agile requires C-level support is because it often involves reorganization or firings at the middle-management level. You're never going to get anywhere complaining to people on lower levels, or to middle management, which is typically against changes to organizational structure. If the executives aren't on board ("we can never change that in this company"), leave and find another company.
I've tried this strategy, but it just comes off as whining. People's reactions tend to be "we all know that's a problem, but what's the fix? None of us have any power to apply any fixes."
The essential strategy to make a company more agile is to a) spend some time at the bottom, to understand how daily processes aren't agile and are broken up by the organization's silos, b) explain how the organization isn't agile to executives, until finally c) you and the executives talk to middle management together and start to take on the middle-management fiefdoms.
The very good reason why Agile requires C-level support is because it often involves reorganization or firings at the middle-management level. You're never going to get anywhere complaining to people on lower levels, or to middle management, which is typically against changes to organizational structure. If the executives aren't on board ("we can never change that in this company"), leave and find another company.
Thanks for your insightful reply!
b) works only when you are even allowed to talk to the exectuives ;) That's why I said it's more frustrating in larger companies...
b) works only when you are even allowed to talk to the exectuives ;) That's why I said it's more frustrating in larger companies...
I always talk to everybody. But then, I've only ever been an employee, not a consultant, and I picked my employers accordingly.
> I've tried this strategy, but it just comes off as whining.
It helps to deliver some good results first. People take you and your opinions more seriously after.
It helps to deliver some good results first. People take you and your opinions more seriously after.
I used to work at a megacorp that pretended having stand up meeting seated was working agile.
I just nodded, cashed the paycheck and still did great work. some battles I won, like moving a whole team to continuous integration or removing most of the manual busywork in testing, sometimes I just let bad stuff go because you can't always win and instead aimed for the second best option: dodge.
I just nodded, cashed the paycheck and still did great work. some battles I won, like moving a whole team to continuous integration or removing most of the manual busywork in testing, sometimes I just let bad stuff go because you can't always win and instead aimed for the second best option: dodge.
> establish a culture of continuous improvement
This is the thing in agile/technical coaching. Too many people focus on the process and dogma when what's really missing is an organizational habit around continuous improvement.
This is the thing in agile/technical coaching. Too many people focus on the process and dogma when what's really missing is an organizational habit around continuous improvement.
> their estimate for a very minor change added up to several months...
It sounds like they had an issue with technical debt (and that had led to a lack of trust from the rest of the company) and thought they could fix it with a process, correct? I don't think you can help someone that won't recognise the root cause.
It sounds like they had an issue with technical debt (and that had led to a lack of trust from the rest of the company) and thought they could fix it with a process, correct? I don't think you can help someone that won't recognise the root cause.
The reason for technical debt is the process. If you have a very waterfall like process like at a lot of large companies, everything has to go through change control.
Every change has to have business case, and becomes very bureaucratic. As a result no one proposes any changes to fix technical debt.
You can do it under the radar by attaching it to existing tasks, but these companies tend to be so project manager driven that any slippage in your delivery dates means you will get pressure applied to you. So you just do the bare minimum.
Result: Technical debt never gets fixed. Refactoring and trying to write good code is career limiting. Company wonders why they are so shit software, blames developers.
The elephant in the room is that companies follow the fixed scope, fixed budget model which basically fails every time.
Every change has to have business case, and becomes very bureaucratic. As a result no one proposes any changes to fix technical debt.
You can do it under the radar by attaching it to existing tasks, but these companies tend to be so project manager driven that any slippage in your delivery dates means you will get pressure applied to you. So you just do the bare minimum.
Result: Technical debt never gets fixed. Refactoring and trying to write good code is career limiting. Company wonders why they are so shit software, blames developers.
The elephant in the room is that companies follow the fixed scope, fixed budget model which basically fails every time.
Add to that putting projects into 'maintenance' mode once they are 'delivered'. Ie no manpower to do any improvements, and even barely an bugfixes---even though lots of new downstream projects depend on it.
I really don't think the process is responsible for technical debt. If anything waterfall is better because you can do larger scale refactorings. But at the end of the day, time needs to be assigned to address that debt and no process will give you that time.
Well agile techniques recommend you don't fix scope, and budget at the same time. Allowing you to go back fix your code that has turned out to be wrong. You're allowed to learn and to adjust your plan as you go a long.
Waterfall people have to meet a deadline and a defined scope, so when being told that you have to refactor some code, the response is to ignore it to meet the deadline. In order to meet deadlines and a defined scope the plan MUST NOT change, otherwise the deadline or scope has to be changed as well.
That is until you reach the deadline and find it doesn't work the way the customer wanted anyway because you refused to change the plan.
For agile techniques the measure of progress is working software, not meeting set deadline and scope.
Waterfall people have to meet a deadline and a defined scope, so when being told that you have to refactor some code, the response is to ignore it to meet the deadline. In order to meet deadlines and a defined scope the plan MUST NOT change, otherwise the deadline or scope has to be changed as well.
That is until you reach the deadline and find it doesn't work the way the customer wanted anyway because you refused to change the plan.
For agile techniques the measure of progress is working software, not meeting set deadline and scope.
Don't be so sure. Layers of middle management, all with their own (often selfish) priorities between you and other teams working on systems you need to collaborate with will destroy any possibility of agility.
Actually (and I do this for a living as a management consultant) we are pushing all of our clients to an Agile operating model. There are many reasons for this, but the primary one being that consumers now expect to interact with all companies like CPGs.
Agile lends itself very well to a top-down brands-and-products hierarchy. You build the core of the products in a shared engineering group (again, just like most CPGs) then apply localized branding and product focus as needed.
And here's the thing: adopting Agile in the corporate world is less about "reacting quickly" (though that is one of the benefits, at least in comparison to the legacy methods) but really more about cost control. Agile is simply cheaper because you're not building shit that nobody wants. If you can build an Agile culture of "if it's not in the backlog that was approved by product and reviewed every couple weeks, you don't build it" you cut down on a lot of pet projects, deprecated features and duplication of effort.
Is there still duplication? Sure; but often times companies will have 5 groups build the same thing and they just choose the one that gets the most internal traction. That's actually a viable strategy when you don't know the product you need to build, but you need it to work. It also tends to help find the right "home" within the organization politically (i.e. the people who really need said functionality will build it, use it, make it popular, and then get the money to maintain it while fringe users lose funding and migrate to the shared platform).
The key thing is that the engineers aren't in control. And with good reason; engineers are paid to build products, product managers are paid to design products and brand managers are paid to build portfolios of interrelated products. You cannot run a large company without this kind of P&L discipline.
Agile lends itself very well to a top-down brands-and-products hierarchy. You build the core of the products in a shared engineering group (again, just like most CPGs) then apply localized branding and product focus as needed.
And here's the thing: adopting Agile in the corporate world is less about "reacting quickly" (though that is one of the benefits, at least in comparison to the legacy methods) but really more about cost control. Agile is simply cheaper because you're not building shit that nobody wants. If you can build an Agile culture of "if it's not in the backlog that was approved by product and reviewed every couple weeks, you don't build it" you cut down on a lot of pet projects, deprecated features and duplication of effort.
Is there still duplication? Sure; but often times companies will have 5 groups build the same thing and they just choose the one that gets the most internal traction. That's actually a viable strategy when you don't know the product you need to build, but you need it to work. It also tends to help find the right "home" within the organization politically (i.e. the people who really need said functionality will build it, use it, make it popular, and then get the money to maintain it while fringe users lose funding and migrate to the shared platform).
The key thing is that the engineers aren't in control. And with good reason; engineers are paid to build products, product managers are paid to design products and brand managers are paid to build portfolios of interrelated products. You cannot run a large company without this kind of P&L discipline.
> Many C-level executives want "true business agility" for their company: They want to be able to react quickly when circumstances change.
True, and this isn't a bad goal in and of itself, but what they don't realise is that these 'quick reactions' (aka fundamental low level changes in the product) may require orders of magnitude more work than said executives expect (and in fact, probably the work required is at least linear in the age of the company).
> (they do not have a war chest yet, so those that were not able to react quickly do not exist anymore)
I'd argue that having a 'war chest' is actually detrimental to agility (if you're thinking of agility as 'the ability to perform at our current level in a different field'). Small new companies can pivot extremely fast because even if it means throwing away their whole codebase, they've only lost a few months' work.
True, and this isn't a bad goal in and of itself, but what they don't realise is that these 'quick reactions' (aka fundamental low level changes in the product) may require orders of magnitude more work than said executives expect (and in fact, probably the work required is at least linear in the age of the company).
> (they do not have a war chest yet, so those that were not able to react quickly do not exist anymore)
I'd argue that having a 'war chest' is actually detrimental to agility (if you're thinking of agility as 'the ability to perform at our current level in a different field'). Small new companies can pivot extremely fast because even if it means throwing away their whole codebase, they've only lost a few months' work.
> I'd argue that having a 'war chest' is actually detrimental to agility [...]
I believe that's what the parent is saying as well. I read it as saying that larger companies with a 'war chest' are able to weather the problems caused by reacting more slowly, and so agility is not as highly prioritized, while smaller, newer companies have to react quickly or die.
I believe that's what the parent is saying as well. I read it as saying that larger companies with a 'war chest' are able to weather the problems caused by reacting more slowly, and so agility is not as highly prioritized, while smaller, newer companies have to react quickly or die.
To be fair, many "low level" technical decisions also cost orders of magnitude more than was originally intended.
Not coincidentally, there is rarely strong strategic technical direction at the organization level. Rarely is there accountability (especially for middle management) in making sure that cobol is actually deprecated, those Windows XP boxes are actually powered down, and that gnarly business logic is cleaned up and well-tested.
It's worth noting that typically there's collusion from all levels to create one of those problems. That being said, there's not much an individual contributor can do about massive strategic mistakes other than move to another org. A magical org with great engineers and no major technical debt.
Not coincidentally, there is rarely strong strategic technical direction at the organization level. Rarely is there accountability (especially for middle management) in making sure that cobol is actually deprecated, those Windows XP boxes are actually powered down, and that gnarly business logic is cleaned up and well-tested.
It's worth noting that typically there's collusion from all levels to create one of those problems. That being said, there's not much an individual contributor can do about massive strategic mistakes other than move to another org. A magical org with great engineers and no major technical debt.
"War chest" kind of implies liquid assets of some kind. Code is a highly illiquid asset and even a liability if you have to maintain its existing functionality.
Most of the small companies that are able to pivot easily do have reasonably large war chests in the form of VC funding. If they don't have that kind of funding they won't be able to pivot as easily because they need to worry about maintaining cash flow just to keep the lights on.
Most of the small companies that are able to pivot easily do have reasonably large war chests in the form of VC funding. If they don't have that kind of funding they won't be able to pivot as easily because they need to worry about maintaining cash flow just to keep the lights on.
Agile coach here. You nailed it.
One way of looking at these companies is that they're organisms adapted to their environment. If there are weak selection pressures around agility and software delivery in their market "environment" then you can expect that they're well adapted to other pressures (i.e. credit risk, or buying labor at one price and selling it at another).
Often times these businesses might see reasons for agility, opportunities they could take advantage of, still they really aren't feeling selection pressures so there's no real need to change. How they deliver software with really bad agile is "good enough". Well it will be until it isn't and then it might be too late.
So you have all the structures and processes that make one organism good at being a bottom feeder and it's like pushing water up a hill to make them change when they REALLY DONT HAVE TOO.
Every once in a while I have a client where this stuff actually matters to them and we have a lot of fun and make amazing stuff.
One way of looking at these companies is that they're organisms adapted to their environment. If there are weak selection pressures around agility and software delivery in their market "environment" then you can expect that they're well adapted to other pressures (i.e. credit risk, or buying labor at one price and selling it at another).
Often times these businesses might see reasons for agility, opportunities they could take advantage of, still they really aren't feeling selection pressures so there's no real need to change. How they deliver software with really bad agile is "good enough". Well it will be until it isn't and then it might be too late.
So you have all the structures and processes that make one organism good at being a bottom feeder and it's like pushing water up a hill to make them change when they REALLY DONT HAVE TOO.
Every once in a while I have a client where this stuff actually matters to them and we have a lot of fun and make amazing stuff.
Awesome explanation! I have to think about this organism / selection idea a bit more.
It's amazing how much I have learned and how many different perspectives people have told me since I first gave that talk...
It's amazing how much I have learned and how many different perspectives people have told me since I first gave that talk...
I could wax lyrical about Agile all day long. If you google 'Agile Bullshit', a comment I wrote on HN a few years ago is usually in the top three results, and because of that I get an email once a month from someone driven to despair by said 'Agile Bullshit' who feels compelled to get in touch with me and vent a little. I enjoy the emails, and I think they've given me a much broader perspective on agile than my own experience alone could offer.
I've been writing an article about Agile for years now, that I can never finish. But here's what I consider to the be the two biggest problems with Agile.
1. Agile can never work in an agency, where the client has control over budgets, deadlines, and features. There is simply no incentive for the client to compromise when your agency has made some pretty ridiculous promises and put themselves on the hook to deliver.
2. There are some teams that deliver well under agile (as per the metrics that the business has defined), and some that don't. In my experience, the ones that deliver well produce the worst work because they won't push back on a design or a feature that's incomplete, nonsensical, or plain impossible. They do what they're told and add no value to the overall output. This is especially true of offshore development teams.
The teams that produce the better software do push back, but the Agile process as implemented everywhere on earth does not support them. Instead, animosity grows between the developers who push back, and the product-owners|BA's|designers who can't or wont understand the problems with their own work.
But! Some process is better than no process. And I've worked in some companies that take Agile very seriously and are willing to put in the hard work to make it work. And I suppose that' the secret sauce that's missing from most organisations that are "Agile", they think it's a trick, a hack, a cheat, a short cut.
It's not. Like everything else worth doing, it's hard work.
I've been writing an article about Agile for years now, that I can never finish. But here's what I consider to the be the two biggest problems with Agile.
1. Agile can never work in an agency, where the client has control over budgets, deadlines, and features. There is simply no incentive for the client to compromise when your agency has made some pretty ridiculous promises and put themselves on the hook to deliver.
2. There are some teams that deliver well under agile (as per the metrics that the business has defined), and some that don't. In my experience, the ones that deliver well produce the worst work because they won't push back on a design or a feature that's incomplete, nonsensical, or plain impossible. They do what they're told and add no value to the overall output. This is especially true of offshore development teams.
The teams that produce the better software do push back, but the Agile process as implemented everywhere on earth does not support them. Instead, animosity grows between the developers who push back, and the product-owners|BA's|designers who can't or wont understand the problems with their own work.
But! Some process is better than no process. And I've worked in some companies that take Agile very seriously and are willing to put in the hard work to make it work. And I suppose that' the secret sauce that's missing from most organisations that are "Agile", they think it's a trick, a hack, a cheat, a short cut.
It's not. Like everything else worth doing, it's hard work.
> Agile can never work in an agency, where the client has control over budgets, deadlines, and features. There is simply no incentive for the client to compromise when your agency has made some pretty ridiculous promises and put themselves on the hook to deliver.
There's an interesting triad that I've been talking to people about a lot recently.
1. Authority (the ability to make decisions of importance)
2. Accountability (a way of telling if you are doing better or worse)
3. Responsibility (pride and reward proportional to the results you deliver)
Essentially when you lack any of those three, you cannot operate effectively.
Without accountability, you have no way of knowing what success is. Without authority, you have no power to recruit help or make the necessary changes to be successful, and without responsibility, no amount of accountability or authority matters.
This is especially true in asymmetrical relationships like customer-vendor and employee-employer.
There's an interesting triad that I've been talking to people about a lot recently.
1. Authority (the ability to make decisions of importance)
2. Accountability (a way of telling if you are doing better or worse)
3. Responsibility (pride and reward proportional to the results you deliver)
Essentially when you lack any of those three, you cannot operate effectively.
Without accountability, you have no way of knowing what success is. Without authority, you have no power to recruit help or make the necessary changes to be successful, and without responsibility, no amount of accountability or authority matters.
This is especially true in asymmetrical relationships like customer-vendor and employee-employer.
I'd change the labels a little, since I think those terms are overloaded:
I think 'authority' is 'agency', or 'self-determination',
'accountability' is 'direction'/'awareness'/'sensitivity'/'comprehension',
'Responsibility' is actually 'motivation': It also might matter if this is 'pride', or 'avoiding blame', and to what degree it is 'reactive' and 'proactive'. Obviously, knowing what you are responsible for, and having every are have a point of responsibility is important too; 'accountability' seems similar to this to me.
I think 'authority' is 'agency', or 'self-determination',
'accountability' is 'direction'/'awareness'/'sensitivity'/'comprehension',
'Responsibility' is actually 'motivation': It also might matter if this is 'pride', or 'avoiding blame', and to what degree it is 'reactive' and 'proactive'. Obviously, knowing what you are responsible for, and having every are have a point of responsibility is important too; 'accountability' seems similar to this to me.
I wouldn't change those labels, actually, the responsibility-accountability-authority triad is pretty well known if you google. It's just not familiar to most folks in programming I guess.
You just invented Semantic-Agile.
> 1. Agile can never work in an agency, where the client has control over budgets, deadlines, and features. There is simply no incentive for the client to compromise when your agency has made some pretty ridiculous promises and put themselves on the hook to deliver.
Yes, I've worked at places where they'd accept fixed budget and short timescale projects while also preaching about the benefits of agile to the client. This meant there was minimal upfront design and the customer was given a chance to change their mind often. This lead to crunch time and having to make changes that could have easily been predicted if planning had been done from the start. If you suggested the latter advice though, you'd be accused of being a "waterfall" practitioner and ignored so it felt very cargo cult.
My view is that projects with short time scales where it's predictable early on what all the functionality should be, you should plan out as much as you can from the start and get the client to OK as much as you can early on (e.g. with mockups, interactive prototypes). Agile is more suitable for larger projects with flexible budgets where there are so many unknowns that planning ahead isn't productive.
Yes, I've worked at places where they'd accept fixed budget and short timescale projects while also preaching about the benefits of agile to the client. This meant there was minimal upfront design and the customer was given a chance to change their mind often. This lead to crunch time and having to make changes that could have easily been predicted if planning had been done from the start. If you suggested the latter advice though, you'd be accused of being a "waterfall" practitioner and ignored so it felt very cargo cult.
My view is that projects with short time scales where it's predictable early on what all the functionality should be, you should plan out as much as you can from the start and get the client to OK as much as you can early on (e.g. with mockups, interactive prototypes). Agile is more suitable for larger projects with flexible budgets where there are so many unknowns that planning ahead isn't productive.
I'd go a step further and say that agencies can never work, at least past the small project or website level. The customer is oblivious to the maintenance required for a software project (even if it's just maintaining developer familiarity with the code base) and the agency can only ever get them to pay for features.
For #1, I'd say a dedication to Agile requires significant business commitment on the contractual side to ensuring there basically ARE no commitments beyond the backlog/stories. Needless to say, some clients can't handle this and you need to to turn business away.
There are agencies that act this way like Tribalscale or Pivotal Labs, both of which are pretty dedicated XP shops but also with significant design and product capabilities.
There are agencies that act this way like Tribalscale or Pivotal Labs, both of which are pretty dedicated XP shops but also with significant design and product capabilities.
I have definitely lived through #1. I started out at a "web agency for marketing agencies". Most of the time the actual client never knew we existed. Budget and features were set up front and the deadline was immovable as other forms of media would be directing to our apps/webpages starting on a specific date.
Despite all of that we called ourselves agile. This amounted to pretending to be agile for 90% of the project and then as the deadline approached just staying up late/working weekends to make sure it was complete and out the door. Naturally it was worse when we had competing deadlines between different projects. And when do different clients ever have deadlines that fit nicely in between other clients?
Being at a "product company", it is much easier to be agile about stuff where features and/or deadlines can be shifted
Despite all of that we called ourselves agile. This amounted to pretending to be agile for 90% of the project and then as the deadline approached just staying up late/working weekends to make sure it was complete and out the door. Naturally it was worse when we had competing deadlines between different projects. And when do different clients ever have deadlines that fit nicely in between other clients?
Being at a "product company", it is much easier to be agile about stuff where features and/or deadlines can be shifted
Well said. The funny thing about point 1. is that the Agile Manifesto implies already that it could never work: "Customer collaboration over contract negotiation"
Nevertheless it doesn't stop many agencies from claiming that their fixed price projects are agile.
Nevertheless it doesn't stop many agencies from claiming that their fixed price projects are agile.
Agile is the only word I know that inverts its meaning when you capitalise it.
The team I work in is fairly agile, in that we communicate well, react to changing priorities very quickly, and ship things regularly. We're not perfect by any means, but whenever we consider adding more of the typical "Agile" process we always realise it would slow us down, and we see other companies with more set "Agile" processes being much slower.
The team I work in is fairly agile, in that we communicate well, react to changing priorities very quickly, and ship things regularly. We're not perfect by any means, but whenever we consider adding more of the typical "Agile" process we always realise it would slow us down, and we see other companies with more set "Agile" processes being much slower.
Yes. The funny thing is that at a company I worked for in the 90ies, we were very agile, before that became a thing, and it was GREAT. Empowering, fun, engineering-driven, effective, efficient. The things we did with our tiny team were amazing.
When I read about XP, what I read very much resonated with what we were doing, without ever having a name for it other than "what we do and like that works well".
However, whenever I've seen Agile applied at other companies, it was horrible. And yet they refer to the same words. Someone recently told me "Agile/XP/etc. sound like slaves trying to figure out better ways to please their masters". And when I take that frame of reference, yep, that is exactly what it sounds like.
So something weird is going on with those words.
When I read about XP, what I read very much resonated with what we were doing, without ever having a name for it other than "what we do and like that works well".
However, whenever I've seen Agile applied at other companies, it was horrible. And yet they refer to the same words. Someone recently told me "Agile/XP/etc. sound like slaves trying to figure out better ways to please their masters". And when I take that frame of reference, yep, that is exactly what it sounds like.
So something weird is going on with those words.
The issue is that "agile" was a descriptive word, used relatively loosely. Then some people tried to capture its essence and artificially engineer it into their process, and it became prescriptive.
Some things are better left to occur organically. If you want to be "agile," then reevaluate your corporate culture and create an environment where it might occur. It needs to be you, you can't fake it, much to the chagrin of some of the more uncharismatic business types.
Some things are better left to occur organically. If you want to be "agile," then reevaluate your corporate culture and create an environment where it might occur. It needs to be you, you can't fake it, much to the chagrin of some of the more uncharismatic business types.
I enjoyed your comment. The rush to formally define and implement "agile" is pretty hysterical on a fundamental level.
I typically find the same about Software Architect vs software architect - eg the Job Title vs the activity that decent developers do.
I'd argue stand up meetings are the opposite of agile, the insistence on them is literally breaking the first rule of the agile manifesto:
> Individuals and interactions over processes and tools
Probably breaking the fourth too:
> Responding to change over following a plan
How many companies have done a retrospective on whether the daily recitation of Kanban board movements is providing any value?
> Individuals and interactions over processes and tools
Probably breaking the fourth too:
> Responding to change over following a plan
How many companies have done a retrospective on whether the daily recitation of Kanban board movements is providing any value?
To me, a lot of Agile breaks the first rule. A Certified SCRUM Master comes in and overhauls your processes. That is, in effect, processes and tools straight up, from the minute that scrum master goes on a course.
It wouldn't be much of a course if it didn't teach some process for implementing SCRUM.
It wouldn't be much of a consultation if the consultant tells you to go speak to your customers and find out what is really bothering them and how you can deliver working software quickly to alleviate that.
So you have daily standup a, weekly retrospectives, a designated master, product owner, a process for estimation, a n-week sprint. Those are must haves. That's all process.
It wouldn't be much of a course if it didn't teach some process for implementing SCRUM.
It wouldn't be much of a consultation if the consultant tells you to go speak to your customers and find out what is really bothering them and how you can deliver working software quickly to alleviate that.
So you have daily standup a, weekly retrospectives, a designated master, product owner, a process for estimation, a n-week sprint. Those are must haves. That's all process.
I think you have the same misconception about the first rule that many people do (forgive me if I'm wrong).
> Individuals and interactions over processes and tools
This does not mean that you minimise process and tools. This means that individuals and interactions trump processes and tools. So if you have a process that doesn't fit the people on your team, then you change the process, not the team. Similarly, you try to encourage interactions through as many avenues as you can. You don't say, "You must use this tool and only this tool to communicate".
But it's a mistake to think that you want to remove process. That's not "agile". That's "ad hoc". There is nothing particularly wrong with ad hoc processes if you are successful, but the "we'll just use common sense" approach that many teams attempt is usually anything but successful.
Process is there to support individuals. When I am coaching a team, I never go in with the idea of introducing any particular process. Of course, I am more skilled with some processes than others, but imposing my skill on a team I am coaching is not going to be successful. Instead, I watch what people are doing and write it down. That is the process. At that point I start looking at problems that we can solve. I look for places where the process is not consistent, or where people are struggling because they don't know what to do. Then I try to extend the existing processes so that it is consistent across the team. Finally, I start introducing things that I'm skillful in where I am sure it will make a difference. At this point the team is already delivering with their process and we are just looking at ways to optimise.
There is a lot more to it that this, of course. However, for me this is the minimum thing that you need to do to coach a team. I've tried other approaches (when forced to by upper management), but I've never been successful.
> Individuals and interactions over processes and tools
This does not mean that you minimise process and tools. This means that individuals and interactions trump processes and tools. So if you have a process that doesn't fit the people on your team, then you change the process, not the team. Similarly, you try to encourage interactions through as many avenues as you can. You don't say, "You must use this tool and only this tool to communicate".
But it's a mistake to think that you want to remove process. That's not "agile". That's "ad hoc". There is nothing particularly wrong with ad hoc processes if you are successful, but the "we'll just use common sense" approach that many teams attempt is usually anything but successful.
Process is there to support individuals. When I am coaching a team, I never go in with the idea of introducing any particular process. Of course, I am more skilled with some processes than others, but imposing my skill on a team I am coaching is not going to be successful. Instead, I watch what people are doing and write it down. That is the process. At that point I start looking at problems that we can solve. I look for places where the process is not consistent, or where people are struggling because they don't know what to do. Then I try to extend the existing processes so that it is consistent across the team. Finally, I start introducing things that I'm skillful in where I am sure it will make a difference. At this point the team is already delivering with their process and we are just looking at ways to optimise.
There is a lot more to it that this, of course. However, for me this is the minimum thing that you need to do to coach a team. I've tried other approaches (when forced to by upper management), but I've never been successful.
I think process is important. If there isn't some kind of method or process, it isn't really engineering. You can't build modern bridge or building just by going at it.
My comment wasn't clear: scrum is sold the majority of the time as a whole new process and it's seen that way by most, from the minute they do the training.
I've read the scrum book and to me it seems like a process that helps develop your own process. I think that's a fantastic idea.
The problem I'm talking about is that 90% of scrum masters and companies moving to scrum, well, are moving to scrum, as though it's a whole new process as opposed to organically developing new effective processes that fit the company like a glove.
On a smoke break, I heard about a company "doing agile" that's now moving "back to waterfall" after laying off 2/3rds of their team. Another big blue chip I work with also got shafted in a big way by a consulting company that tried "moving them to agile".
What you do is a world apart from what most people attempt and it's the latter that devastates.
My comment wasn't clear: scrum is sold the majority of the time as a whole new process and it's seen that way by most, from the minute they do the training.
I've read the scrum book and to me it seems like a process that helps develop your own process. I think that's a fantastic idea.
The problem I'm talking about is that 90% of scrum masters and companies moving to scrum, well, are moving to scrum, as though it's a whole new process as opposed to organically developing new effective processes that fit the company like a glove.
On a smoke break, I heard about a company "doing agile" that's now moving "back to waterfall" after laying off 2/3rds of their team. Another big blue chip I work with also got shafted in a big way by a consulting company that tried "moving them to agile".
What you do is a world apart from what most people attempt and it's the latter that devastates.
> But it's a mistake to think that you want to remove process.
It's also a mistake to keep a process that isn't delivering any benefit though. I've seen very few stand-ups that provided a benefit and zero where there was no other way to get the same benefit.
It's also a mistake to keep a process that isn't delivering any benefit though. I've seen very few stand-ups that provided a benefit and zero where there was no other way to get the same benefit.
especially as the team and code grow there's little reason for standups, nobody cares about what most of the other people tells anyway unless they're effected in their goals.
much better to have a team leader who knows the tasks for everyone and warn people when they are operating an area where they can step on each other toes, so that they know they need to coordinate.
the Nx(N-1) rigid reporting structure of stand up makes very little sense
much better to have a team leader who knows the tasks for everyone and warn people when they are operating an area where they can step on each other toes, so that they know they need to coordinate.
the Nx(N-1) rigid reporting structure of stand up makes very little sense
One of the reasons SCRUM wasn't very popular in our team was that we realized it meant having a lot more meetings than we were having before.
I think if you go by the numbers, standard scrum has you spending nearly 20% in your time in developer meetings.
Stand ups didn't really work for us either as we are doing our own thing most of the time, so there is little to coordinate, and when there is a need, we usually just work closely together.
Stand ups didn't really work for us either as we are doing our own thing most of the time, so there is little to coordinate, and when there is a need, we usually just work closely together.
Capital-A-Agile puts a lot of emphasis on very fine-grained collaboration and reducing the amount of time people are "doing their own thing". Some advocates are pretty open about this being a form of micromanagement[1].
Some people thrive in high-visibility, fine-grained-collaboration environments. On the other hand, if you've got people who are already doing good work without many meetings, it's hard to see Scrum-flavoured setups being anything other than intrusive.
[1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...
Some people thrive in high-visibility, fine-grained-collaboration environments. On the other hand, if you've got people who are already doing good work without many meetings, it's hard to see Scrum-flavoured setups being anything other than intrusive.
[1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...
That's what turned me away from Scrum. When you do something really difficult you end up reporting the same thing for weeks. Or you feel you shouldn't even try something difficult because you can't break down into little daily chunks.
I prefer my people solve difficult problems and not just little bite-sized tasks that only touch the surface of the system.
I prefer my people solve difficult problems and not just little bite-sized tasks that only touch the surface of the system.
Micromanagement is indeed what it looked like to me with all the daily stand ups (what did you do yesterday), review meetings (what did you do last week ?), scoring (what do you mean it would take you longer than that other developer to finish something ?) and sprints (we HAVE to do this THIS WEEK).
That's certainly what it can be used for and probably is on a large scale.
The most important one that a lot seem to miss is the "did you face any road blocks?", with a culture where the whole team thinks and removes the roadblock such that it is removed for everybody for good.
Morphine is a pretty damn good painkiller. Unfortunately, it is extremely easy to abuse to the point where there are more people abuse it than people who genuinely benefit from it.
On a larger scale, communism as it was originally conceived sounds like a utopia. Unfortunately, the only thing that's actually happened is an abuse that takes anything from democracy to authoritarian regimes well towards totalitarianism, the anti-thesis of communism.
Scrum and agile is the same in that respect. Sounds great. Works well on paper but very rarely used correctly or with the original intention.
The most important one that a lot seem to miss is the "did you face any road blocks?", with a culture where the whole team thinks and removes the roadblock such that it is removed for everybody for good.
Morphine is a pretty damn good painkiller. Unfortunately, it is extremely easy to abuse to the point where there are more people abuse it than people who genuinely benefit from it.
On a larger scale, communism as it was originally conceived sounds like a utopia. Unfortunately, the only thing that's actually happened is an abuse that takes anything from democracy to authoritarian regimes well towards totalitarianism, the anti-thesis of communism.
Scrum and agile is the same in that respect. Sounds great. Works well on paper but very rarely used correctly or with the original intention.
That blog post is really odd. It's like "sure you're being micromanaged, but its by a mob instead of a tyrant", as though thats a comforting thing. How is that better?! You cant just throw the word "team" in there and pretend it makes things ok.
> I'd argue stand up meetings are the opposite of agile
Those 15min when the team gets together and talks about what they're doing and where they need help ... that's the most useful meeting I've ever been a part of. 80% of all other interactions could be removed with a kanban board and some patience.
Like, shit man, sometimes it takes me more than 3 minutes to reply on Slack because I'm doing shit. Go do some stretches or something ...
Those 15min when the team gets together and talks about what they're doing and where they need help ... that's the most useful meeting I've ever been a part of. 80% of all other interactions could be removed with a kanban board and some patience.
Like, shit man, sometimes it takes me more than 3 minutes to reply on Slack because I'm doing shit. Go do some stretches or something ...
> Those 15min when the team gets together and talks about what they're doing and where they need help ... that's the most useful meeting I've ever been a part of. 80% of all other interactions could be removed with a kanban board and some patience.
For me it's almost always a waste of 15 minutes. I get to hear 8 people mention what they're up to even though only 1 or 2 (on a good day) will be having any impact on what I'm working on. Of those 2 it's generally more effective to send an email or update the issue so I don't forget about it 5 minutes later.
For me it's almost always a waste of 15 minutes. I get to hear 8 people mention what they're up to even though only 1 or 2 (on a good day) will be having any impact on what I'm working on. Of those 2 it's generally more effective to send an email or update the issue so I don't forget about it 5 minutes later.
> Like, shit man, sometimes it takes me more than 3 minutes to reply on Slack because I'm doing shit. Go do some stretches or something ...
Amen. Especially when the only proper response is a LMGTFY.
Amen. Especially when the only proper response is a LMGTFY.
[deleted]
We've talked about the stand up a few times in retros. We've mixed it up a few times (we now do a task based stand up rather than a person based one) but always felt it was more valuable than not having it.
To echo another comment on here -
Daily standups have been the most useful development I've seen in my 17 year career so far, I'm not sure why there's the hate for them.
It's a small time allotment where everyone gets just a couple of minutes to sum up where they were yesterday, where they're going today and what's holding them up.
I've seen them go wrong, when managers decide that they need to attend and use part of the meeting for "management announcements". I've seen it go wrong when one team member cannot shut up and regularly took over the whole meeting (yes, the scrum master was ineffectual). But in general I've found the daily rapid-fire catchup a thing of beauty.
The rest I can take or leave. One of the worst projects I've ever observed had a highly paid SCRUM Master/Consultant/Trainer and that team seemed to spend several hours each day on process. They failed to deliver anything, ever, the product was scrapped and everyone was laid off, including the development manager.
Daily standups have been the most useful development I've seen in my 17 year career so far, I'm not sure why there's the hate for them.
It's a small time allotment where everyone gets just a couple of minutes to sum up where they were yesterday, where they're going today and what's holding them up.
I've seen them go wrong, when managers decide that they need to attend and use part of the meeting for "management announcements". I've seen it go wrong when one team member cannot shut up and regularly took over the whole meeting (yes, the scrum master was ineffectual). But in general I've found the daily rapid-fire catchup a thing of beauty.
The rest I can take or leave. One of the worst projects I've ever observed had a highly paid SCRUM Master/Consultant/Trainer and that team seemed to spend several hours each day on process. They failed to deliver anything, ever, the product was scrapped and everyone was laid off, including the development manager.
> ...everyone gets just a couple of minutes to sum up where they were yesterday, where they're going today and what's holding them up.
Peer-to-peer, listing blockers is more or less the only thing that matters, followed distantly by making sure we're not stepping on each other (deploying the same thing, refactoring the same class).
It's also important to sync up that designs are good and work together, but that's outside the scope of Agile (and standups).
The bulk of the info in the yesterday-today-blockers standup is to let the manager get a quick rundown of what the employees are up to. It's a management tool, basically. And that info is all duplicated (if you're doing it correctly) in the agile board, the burndown chart, and in the version control system. So management could just create better queries and dashboards on top of existing data and get the same information.
Peer-to-peer, listing blockers is more or less the only thing that matters, followed distantly by making sure we're not stepping on each other (deploying the same thing, refactoring the same class).
It's also important to sync up that designs are good and work together, but that's outside the scope of Agile (and standups).
The bulk of the info in the yesterday-today-blockers standup is to let the manager get a quick rundown of what the employees are up to. It's a management tool, basically. And that info is all duplicated (if you're doing it correctly) in the agile board, the burndown chart, and in the version control system. So management could just create better queries and dashboards on top of existing data and get the same information.
We've run the standups like that with no management involvement at all in some places. I still find them useful as they allow people to resolve dependencies a schedule work appropriately.
Those other tools have a tendency to get ignored, get out of sync, out of date and add overhead.
Those other tools have a tendency to get ignored, get out of sync, out of date and add overhead.
> Those other tools have a tendency to get ignored...
That's basically my point. Managers should home their craft and improve their tools instead of molding the people around them to meet the needs of middle management.
That's basically my point. Managers should home their craft and improve their tools instead of molding the people around them to meet the needs of middle management.
Well, I'm not sure that the daily standups have always been about that, and as a developer I've found them useful.
I've found them useful, but only to the extent that they focus on burndown and not presenting status reports to management while the rest of the team listens.
Maybe its useful to you, but to be honest, I cant remember a single thing about the standup meeting I had today and I made a point of paying attention. People talk about like "blockers", but if something is blocking me I just go talk to whoever can fix that, and if I need to know about something I just ask people to loop me in. I dont need agile for basic communication skills
You don't need to remember what happened this morning particularly, so long as you participated.
Great for blockers you know how to fix or who to ask, but you may miss some others.
"I need permissions on this server to do X and am waiting for someone to do that" might have an easy workaround that a colleague knows.
"I'm doing X but it's taking some time because I'm not familiar with Y" might be met with someone offering to help as they have experience you didn't know about.
You'd never get this without some form of generalised conversation.
Great for blockers you know how to fix or who to ask, but you may miss some others.
"I need permissions on this server to do X and am waiting for someone to do that" might have an easy workaround that a colleague knows.
"I'm doing X but it's taking some time because I'm not familiar with Y" might be met with someone offering to help as they have experience you didn't know about.
You'd never get this without some form of generalised conversation.
I feel like I can get all of the things you mentioned without a mandatory daily meeting, either through slack, email, or just conversing with someone. It's not that the daily standup bothers me per se, but lets calculate this out for a second. If the daily standup eats about 15 minutes, and you work about 250 days a year, thats about 3500 minutes spent in a scrum. Considering that, even being charitable, I might hear one useful thing every two weeks... I kinda would rather spend those 3500 minutes elsewhere
I had a standup at a 24 person company where every single person (except the CEO of course) had to attend standup and report. That's a long standup, esp. when someones report spirals into a discussion.
Wasn't very agile.
Wasn't very agile.
Yeah, that sucks, you don't want more than 5 or 6 people in one really.
> It's a small time allotment where everyone gets just a couple of minutes to sum up where they were yesterday, where they're going today and what's holding them up.
Don't you have a kanban board or equivalent where you can see what everyone's been up to and what their upcoming tasks are? Do you need to know what's holding them up if it's not you?
For those of us complaining, it's not that we don't see the value, we just see other, arguably better ways to get the same value.
Don't you have a kanban board or equivalent where you can see what everyone's been up to and what their upcoming tasks are? Do you need to know what's holding them up if it's not you?
For those of us complaining, it's not that we don't see the value, we just see other, arguably better ways to get the same value.
>>Don't you have a kanban board or equivalent where you can see what everyone's been up to and what their upcoming tasks are?
Not where I am now, and in places where we have had various boards it was still useful to have the quick verbal communication - "Oh, I have a script that deals with some of that, it might be a useful guide, let's talk afterwards"
>> Do you need to know what's holding them up if it's not you?
The same thing may bite me soon so I need to know, or I may have a simple workaround and can offer to help them out.
I find the line in the article about it being unnecessary if the team is functioning and communicating well quite weird - the stand-up, in my experience, has been a part of that and has also been a way of saving other communication time.
Not where I am now, and in places where we have had various boards it was still useful to have the quick verbal communication - "Oh, I have a script that deals with some of that, it might be a useful guide, let's talk afterwards"
>> Do you need to know what's holding them up if it's not you?
The same thing may bite me soon so I need to know, or I may have a simple workaround and can offer to help them out.
I find the line in the article about it being unnecessary if the team is functioning and communicating well quite weird - the stand-up, in my experience, has been a part of that and has also been a way of saving other communication time.
Daily standups have been the most useful development I've seen in my 17 year career so far, I'm not sure why there's the hate for them.
Two things that bother me:
1) You either have to hold them at the start of the working day (in which case they become a synchronization point and everyone has to turn up at the same time -- which will inevitable be a bad time for some people) or a bit later (in which case you end up with an odd slot at the start of the day which usually isn't long enough to start on anything substantive).
2) They mandate daily visibility, and (by design, I think) prevent people going off for a week or two and solving something substantial on their own.
There are possible solution to (1) -- e.g. asynchronous stand ups in a chat client (and it's probably not coincidental that the only times I've found these things at all helpful, they've followed this model rather than the actual stand-up-in-circle thing). But (2) is kind-of the whole premise of "agile teams", so not sure what can be done about that.
Two things that bother me:
1) You either have to hold them at the start of the working day (in which case they become a synchronization point and everyone has to turn up at the same time -- which will inevitable be a bad time for some people) or a bit later (in which case you end up with an odd slot at the start of the day which usually isn't long enough to start on anything substantive).
2) They mandate daily visibility, and (by design, I think) prevent people going off for a week or two and solving something substantial on their own.
There are possible solution to (1) -- e.g. asynchronous stand ups in a chat client (and it's probably not coincidental that the only times I've found these things at all helpful, they've followed this model rather than the actual stand-up-in-circle thing). But (2) is kind-of the whole premise of "agile teams", so not sure what can be done about that.
> asynchronous stand ups in a chat client
I've been thinking this is actually the perfect standup. People don't tend to write novels in chat clients anyway (and to the extent they do, you can move the text to a README or wiki and just link it).
Does anyone have any experience with this? Any pros and cons worth mentioning?
I've been thinking this is actually the perfect standup. People don't tend to write novels in chat clients anyway (and to the extent they do, you can move the text to a README or wiki and just link it).
Does anyone have any experience with this? Any pros and cons worth mentioning?
We do. Post in Slack. It's great because you can ignore anything that doesn't mention you (which is what people do in napping-while-standing IRL standups anyway) but you can always go back and see what someone's up to if it becomes relevant.
Well, I wrote "great", but the latter case should be handled by other tools anyway. So really the whole thing could be replaced by just at-mentioning someone who needs to know what you're doing, when they need to know it. Which is just, you know, normal communication. But if you must do standups this is the way to do it, I guess, since it does the least harm.
Well, I wrote "great", but the latter case should be handled by other tools anyway. So really the whole thing could be replaced by just at-mentioning someone who needs to know what you're doing, when they need to know it. Which is just, you know, normal communication. But if you must do standups this is the way to do it, I guess, since it does the least harm.
I pushed http://geekbot.io/ as an alternative for physical standups at my current place -- it's been generally well received, and when I've used it on short projects (that were set up a way that needed daily sync-ups) I found it pretty helpful, and much less intrusive than a physical standup.
Still prefer to have things structured in a more coarse-grained manner, though.
Still prefer to have things structured in a more coarse-grained manner, though.
Does the timing matter? We hokd ours in the middle of the day at the moment. Still seems to work (though the discipline is lacking and they often overrun, which I hate)
It matters if you're trying to preserve some decent chunks of time for focussed work.
And if matters if the standup is scheduled for 9am and you can't drop the kids of and be sure of getting in before 9.10
If everyone goes for lunch at the same time, holding it 10 minutes before lunchtime could be a smart move. But only if you've already got that "everyone eats together" culture.
And if matters if the standup is scheduled for 9am and you can't drop the kids of and be sure of getting in before 9.10
If everyone goes for lunch at the same time, holding it 10 minutes before lunchtime could be a smart move. But only if you've already got that "everyone eats together" culture.
We hold ours after lunch. No "everyone eats together culture", unfortunately, but there is now an "everyone finishes lunch by 13.30" culture.
Based on my personal experience, most projects are doomed from the start due to these 2 MAJOR problems:
1. Not prioritizing the task of gathering, decomposing and documenting use-cases at the project kick-off.
2. Chronically under-estimating effort required.
[1] http://thecodeartist.blogspot.com/2015/04/use-case-is-everyt...
[2] http://thecodeartist.blogspot.com/2017/04/effort-estimation....
1. Not prioritizing the task of gathering, decomposing and documenting use-cases at the project kick-off.
2. Chronically under-estimating effort required.
[1] http://thecodeartist.blogspot.com/2015/04/use-case-is-everyt...
[2] http://thecodeartist.blogspot.com/2017/04/effort-estimation....
I often see these as well. I would even go so far as to say these problems are the rule rather than the exception. Why is software development still so high risk?
I don't know the answer but it seems to me that software development is much too bespoke. Take a relatively simple case of web store front development. What if the development company said, OK, for your store you can have option A or option B. Period. The developer doesn't gather requirements at all, and all the tools and libraries are known and have been used before. The customer gets to pick a few options like when you buy a car (e.g., say some look&feel options). This is a low risk, predictable, "there's only one way to do it" approach.
I'd like to see software development become vastly more predictable and stable. This will bore some developers who always want to try the latest framework and technology, but novelty adds risk.
I don't know the answer but it seems to me that software development is much too bespoke. Take a relatively simple case of web store front development. What if the development company said, OK, for your store you can have option A or option B. Period. The developer doesn't gather requirements at all, and all the tools and libraries are known and have been used before. The customer gets to pick a few options like when you buy a car (e.g., say some look&feel options). This is a low risk, predictable, "there's only one way to do it" approach.
I'd like to see software development become vastly more predictable and stable. This will bore some developers who always want to try the latest framework and technology, but novelty adds risk.
I dont think its "under-estimating" as much as to get buy-in in a corporate environment means promising to over-deliver
Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack
Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack
That too.
However most of us tend to be overtly optimistic about the possibility that something will work as expected. Also we tend to forget the secondary tasks involved[3].
Also the fact that there is usually an expected schedule/due-date that are presented before being asked for estimates, people tend to invariably try to fit the effort-estimate into the pre-determined schedule subconsciously neglecting the secondary tasks.
Its like when asked if i can cook a turkey-dinner in 2hours, i say - "looks do-able, i can try...". Completely forgetting the fact that i am being expected to raise it from an egg, and take care of it for a few months first.
[3] Slide 8 - https://www.slideshare.net/cvs26/effort-estimation-73647698/...
However most of us tend to be overtly optimistic about the possibility that something will work as expected. Also we tend to forget the secondary tasks involved[3].
Also the fact that there is usually an expected schedule/due-date that are presented before being asked for estimates, people tend to invariably try to fit the effort-estimate into the pre-determined schedule subconsciously neglecting the secondary tasks.
Its like when asked if i can cook a turkey-dinner in 2hours, i say - "looks do-able, i can try...". Completely forgetting the fact that i am being expected to raise it from an egg, and take care of it for a few months first.
[3] Slide 8 - https://www.slideshare.net/cvs26/effort-estimation-73647698/...
> Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack
Or doubling down on existing tech (and technical debt) instead of keeping their options open.
One of the problems with agile development processes is that they're not paired with agile design principles.
Or doubling down on existing tech (and technical debt) instead of keeping their options open.
One of the problems with agile development processes is that they're not paired with agile design principles.
Also nice: the joke by Rich Hickey that Agile solving software development via sprints is like someone revolutionizing the marathon by firing a starter pistol every 100 meters.
Thats a good one, from his "Simple made easy" talk[0]
[0] https://www.youtube.com/watch?v=zPT-DuG0UjU
[0] https://www.youtube.com/watch?v=zPT-DuG0UjU
I should explain that to my boss, we're literally doing waterfall but with standup meetings...
Is waterfall even a thing? I feel like the software industry is constantly coming up with solutions to cultural problems that were more relevant in 1977 than 2017
Ive worked at places that werent "agile" and it wasnt the strawman experience of waterfall.. it was just people doing work. They just didnt make a big deal about squeezing everything in a two week window and avoided uncomfortable/useless planning and retrospective meetings.
Ive worked at places that werent "agile" and it wasnt the strawman experience of waterfall.. it was just people doing work. They just didnt make a big deal about squeezing everything in a two week window and avoided uncomfortable/useless planning and retrospective meetings.
"wagile"
"Agile waterfall" may be a meme but I have seen job listings use that exact term to describe the company. Out of everywhere I've ever interviewed though, no company that has described themselves as Agile have been remotely Agile, ones that don't spend so much time thinking about process generally are Agile to a degree.
Great stuff.
I asked one Agile coach about how and when one should do software architecture decisions for a larger project, he said you can take an extra sprint/spike at the start to do software architecture if necessary.
At another place, the testing members of the team always tested the previous sprint's work (otherwise they'd be doing nothing for the first 80% of the sprint, if they tested that sprint's software).
So if you had a requirements sprint, a software architecture sprint, a development sprint, then that gets tested on the next sprint, what process does that remind you of? :)
I asked one Agile coach about how and when one should do software architecture decisions for a larger project, he said you can take an extra sprint/spike at the start to do software architecture if necessary.
At another place, the testing members of the team always tested the previous sprint's work (otherwise they'd be doing nothing for the first 80% of the sprint, if they tested that sprint's software).
So if you had a requirements sprint, a software architecture sprint, a development sprint, then that gets tested on the next sprint, what process does that remind you of? :)
That is still iteration. Agile doesn't say you can't do things in phases, it just says those phases need to be short enough that you can iterate on them.
Yea but how done is your sprint if your work isn't tested?
It's the old, "done" vs. "done done" debates we had end of every sprint. I wrote the code, it mostly works, it has bugs. Am I done? Should I move on?
Technical debt creeping higher and higher.
It's the old, "done" vs. "done done" debates we had end of every sprint. I wrote the code, it mostly works, it has bugs. Am I done? Should I move on?
Technical debt creeping higher and higher.
Agile does say the results of sprints should be something the customer can understand and use: a software architecture document, or untested code from the development sprint, isn't that.
I've been there. Now we do scrum and do standup meetings but it's a lot less strict. Most of the team talks constantly anyway as we're all in the same room.
Our old boss is long gone.
Our old boss is long gone.
This is anecdotal, but I've found that the more "agile" a place is, the more underworked I am. In most non-agile places, if im out of work its up to me to find a way to make myself useful (agency!), but in agile environments I usually am told not to take something on because "it wont fit in the sprint". I generally think agiles main benefit is bringing the low performers up to average, but at the cost of handcuffing your top performers.
When I worked with a bigger agile group one of the things I liked was having a task list put together and then divided up among everyone but also having an 'on-deck' group for stuff we didn't think we'd have time for. Anyone who got things done faster would have their pick of the on deck work and was some extra freedom and recognition for doing so.
Its a nice idea in theory, but generally ive found these reserve backlogs are full of things nobody actually wants to do, they just think itd be vaguely nice if someone else did it. Its either stuff with no direct business value (refactor the flargenstock), or high-risk/low reward work
Yea, I think you have to do it well. In general for us it was either fun extra features that product management wasn't super excited about or stuff that was just planned for later.
> bringing the low performers up to average, but at the cost of handcuffing your top performers.
Sounds about right. If you view humans as interchangeable resources then predictable performance is good. Most businesses don't need or benefit from a Linus Torvalds to build their CRUD app.
Sounds about right. If you view humans as interchangeable resources then predictable performance is good. Most businesses don't need or benefit from a Linus Torvalds to build their CRUD app.
Sadly true, although weirdly given most companies hiring practices they apparently think they need Linus to build their facebook for cats app.
Ugh, I deal with this, too. "It won't fit in to the current sprint." Who cares? Nothing bad is going to happen! I just take them anyway and take people to task to explain why this is a worse situation than my salary burning up while I do nothing instead.
I don't see value in stand ups most of the time and usually they just get in the way of your work e.g. "I'll start this feature in 30 mins because we've got a standup in 10 mins". I already know what most people are doing from either group chat or the planning board, and a lot of details won't have much relevance to everyone so you end up zoning out just like you would in typical bad meetings.
The "what did you do yesterday?" part can also encourage people to scramble to justify they worked hard enough yesterday when it's tricky to condense why a task isn't as trivial as it sounds.
What did you do yesterday? What are you doing today? What is getting in your way? That's exactly what planning boards are for! Create a Slack bot which automatically summarises and posts this for each team member every day if you really must.
Planning boards are great though. They give you an overview of what everyone is up to, what progress is being made and they're little effort to keep up-to-date compared to having to reply to lots of emails about "what's going on?".
The "what did you do yesterday?" part can also encourage people to scramble to justify they worked hard enough yesterday when it's tricky to condense why a task isn't as trivial as it sounds.
What did you do yesterday? What are you doing today? What is getting in your way? That's exactly what planning boards are for! Create a Slack bot which automatically summarises and posts this for each team member every day if you really must.
Planning boards are great though. They give you an overview of what everyone is up to, what progress is being made and they're little effort to keep up-to-date compared to having to reply to lots of emails about "what's going on?".
I have yet to see an implementation of "Agile" that's not a cargo cult pretext for micromanagement.
Some advocates are pretty open about this:
https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging
It is an interesting question. I suspect its palatable because it evens the playing field. The game changes from skills based to politics based, and that suits some people better.
I think the article is correct. Agile has valid motivations and solves concrete problems.
But in practice, you will eventually see confirmation bias and cargo cult.
The motto of delivering customer value has been used as an excuse to emphasize the surfaces exposed to the customer (e.g: features) and neglect non-features (non-functional requirements, e.g: maintainability, security, performance, scalability, configuration, testing).
But in practice, you will eventually see confirmation bias and cargo cult.
The motto of delivering customer value has been used as an excuse to emphasize the surfaces exposed to the customer (e.g: features) and neglect non-features (non-functional requirements, e.g: maintainability, security, performance, scalability, configuration, testing).
Microservices seems to be the latest cargo cult technique being pushing without really considering whether the benefits outweigh the costs. Some consultants always need another thing to push that a particular company's problems for them so therefore it must be applied everywhere.
Another kind of cult is religious adherence to methodology while ruining the very value the methodology is supposed to enhance.
When you think something is stupid (like adopting only standups), frequently it's because you don't understand the motivation behind it. Standups are one of the first obvious changes any team, no matter how oldschool and rigid, can adopt and see the results behind it quickly, to encourage further transformation.
When you're changing something big (like a development process that is stable, consistent and filled with people, resources, operational and deployment plans, etc.), you want to change it either radically, or chunk by chunk. Radical changes are easy to decide yet hard to pull off while preserving business continuity, it's a bit of a gamble not everybody is willing to take. So, many executives want the "transformation" to actually be "step by step evolution". And one of the first steps are standups and enhancing the planning.
All of the above doesn't debate the fact that there are companies which get Agile terribly wrong, and companies which can't get Agile right due to extremely rigid structure. However, not all companies who fail to visibly transform into Agile in a few easy steps are like that: sometimes they're stuck on early iterations, slowly working their ways further while preserving continuity and market momentum, and there's nothing wrong with it.
When you think something is stupid (like adopting only standups), frequently it's because you don't understand the motivation behind it. Standups are one of the first obvious changes any team, no matter how oldschool and rigid, can adopt and see the results behind it quickly, to encourage further transformation.
When you're changing something big (like a development process that is stable, consistent and filled with people, resources, operational and deployment plans, etc.), you want to change it either radically, or chunk by chunk. Radical changes are easy to decide yet hard to pull off while preserving business continuity, it's a bit of a gamble not everybody is willing to take. So, many executives want the "transformation" to actually be "step by step evolution". And one of the first steps are standups and enhancing the planning.
All of the above doesn't debate the fact that there are companies which get Agile terribly wrong, and companies which can't get Agile right due to extremely rigid structure. However, not all companies who fail to visibly transform into Agile in a few easy steps are like that: sometimes they're stuck on early iterations, slowly working their ways further while preserving continuity and market momentum, and there's nothing wrong with it.
Standups are a complete waste of time. Whoever floated that idea and made it popular should be ashamed of themselves.
I was sick of "circle time" and "show and tell" when I was in kindergarten. I don't need to deal with that as an adult when I have work to do.
I was sick of "circle time" and "show and tell" when I was in kindergarten. I don't need to deal with that as an adult when I have work to do.
All managers not only engage in waterfall, but covet all of the privileges of waterfall. The ability to tell lessers what to program down to the line of code is the ultimate expression of power for people who will never, ever be C-level. And to top it off, they use their powers to force you to compel you to agree that their practices are agile.
Agile has never, and will never exist when micromanagement is a good enough drug for those who will never reach actual influence.
Agile has never, and will never exist when micromanagement is a good enough drug for those who will never reach actual influence.
This is very true, but Agile isn't the only un-achievable property in this case. Even basic healthy atmosphere and efficiency barely have a chance in these situations, so expecting someone in a wheelchair to run feels a bit naive.
I think the most critical factor in the success or failure of a software development project is the skill and dedication of the developers. Yet I never seem to hear or "Agile Coaches" mention that. I guess clients would not be receptive if someone were to tell them that their best course of action was to replace half of their team.
I think this is why agile is, frankly, so insulting. I went to a good university for four years to learn computer science, a field that is legitimately hard. I produce real business value daily. And yet this methodology places about as much trust in me as a mcdonalds worker.
> I think the most critical factor in the success or failure of a software development project is the skill and dedication of the developers.
And yet. It is part of the agile principles.
#9 Continuous attention to technical excellence and good design enhances agility.
I am shocked to see how the agile principles are ignored by "Agile Coaches".
https://www.agilealliance.org/agile101/12-principles-behind-...
And yet. It is part of the agile principles.
#9 Continuous attention to technical excellence and good design enhances agility.
I am shocked to see how the agile principles are ignored by "Agile Coaches".
https://www.agilealliance.org/agile101/12-principles-behind-...
[deleted]
Most of my freelance projects and technical coaching gigs in the last few years where at companies that were in or after their "Agile transition". And most got "Agile" horribly wrong.
I think cargo cult is an issue, but the problem goes deeper. I wrote a conference talk titled "Your Company Will Never Be Agile" around that topic. The gist is:
Many C-level executives want "true business agility" for their company: They want to be able to react quickly when circumstances change. Many "workers in the trenches" (developers, testers, ...) want to be able to do good work and provide value to the customer.
But in established companies, the organizational structure, processes and policies, annual budgets, KPI and bonus systems and middle management prevent the company from becoming truly agile.
So, young, small companies are more agile, because (among other things) they did not become a bureaucracy yet, they are mostly run by engineers with not much middle management, and because of survivor bias (they do not have a war chest yet, so those that were not able to react quickly do not exist anymore).
Unfortunately, there is no English recording (but the slides are here: https://speakerdeck.com/dtanzer/your-company-will-never-be-a... ).