Where did all the developers go?(agilewarrior.wordpress.com)
agilewarrior.wordpress.com
Where did all the developers go?
http://agilewarrior.wordpress.com/2014/05/13/where-did-all-the-developers-go/
35 comments
This needs to be at the top.
90% of what is sold to me as "Agile" is not at all agile. It is unproductive snake-oil sold by people that benefit by playing with numbers, taking credit and acting as whip.
Nowadays the existence of the word in job descriptions is actually a filter for poorly-run companies. Either they unconsciously swallowed the Kool-Aid or there is a lack of managerial trust in the builders and they have chosen to sacrifice work output for an emotionally comforting feeling of control.
The insinuation from many companies that anybody would want Agile processes to work efficiently is ridiculous. Those that work well are agile because they intuitively or consciously follow the original principles and are part of a cohesive team that doesn't do unnecessary work.
90% of what is sold to me as "Agile" is not at all agile. It is unproductive snake-oil sold by people that benefit by playing with numbers, taking credit and acting as whip.
Nowadays the existence of the word in job descriptions is actually a filter for poorly-run companies. Either they unconsciously swallowed the Kool-Aid or there is a lack of managerial trust in the builders and they have chosen to sacrifice work output for an emotionally comforting feeling of control.
The insinuation from many companies that anybody would want Agile processes to work efficiently is ridiculous. Those that work well are agile because they intuitively or consciously follow the original principles and are part of a cohesive team that doesn't do unnecessary work.
>Nowadays the existence of the word in job descriptions is actually a filter for poorly-run companies
I've noticed this, as well. In those friendly little emails LinkedIn keeps sending me, the companies who claim to be big-A Agile are the ones that seem like the least enjoyable to work for. The ones that actually are agile and would be fun to work for find other ways to signal that fact - mostly by using descriptions that show them to be developer-centric and focussed on software.
I've noticed this, as well. In those friendly little emails LinkedIn keeps sending me, the companies who claim to be big-A Agile are the ones that seem like the least enjoyable to work for. The ones that actually are agile and would be fun to work for find other ways to signal that fact - mostly by using descriptions that show them to be developer-centric and focussed on software.
I think more and more people realize this. The four original value statements from the Agile Manifesto are mentioned far too infrequently compared to all the processes and tools peddled by various agile salespeople.
A friend of mine recently asked me to give a short presentation to a few developers working at his small software company. He suggested that Agile may be a good subject and we spent an hour discussing how his developers analyse, design, code and test their projects so that I could give a relevant talk. It turned out that what they were doing was naturally very close to agile development and the whole talk would have been a waste of everyone's time. I just gave him the link http://agilemanifesto.org and ended up talking about XSS.
A friend of mine recently asked me to give a short presentation to a few developers working at his small software company. He suggested that Agile may be a good subject and we spent an hour discussing how his developers analyse, design, code and test their projects so that I could give a relevant talk. It turned out that what they were doing was naturally very close to agile development and the whole talk would have been a waste of everyone's time. I just gave him the link http://agilemanifesto.org and ended up talking about XSS.
I'd add that the concept of the "story" and the fact that it needs a title of the format "As a <party> I need <functionality> because it add <some business value>." That practice is quite powerful. It continues to amaze me how many project managers are content starting and promising delivery of a project without a clear Definition of Done or any understanding how all this effort will add value to the company/product.
"Getting shit done over attending meetings"
And yet I've seen "agile" teams waste more time in "agile" meetings than in anything else... except for PingPong.
And yet I've seen "agile" teams waste more time in "agile" meetings than in anything else... except for PingPong.
Sprint demos, sprint commits, backlog grooming, daily scrums... It goes on and on. So much of it is not actually getting anything done. Make sure your burndown is good guys!
"Working software over comprehensive documentation"
And this is why nobody who is a real engineer should ever take most software engineers seriously.
And this is why nobody who is a real engineer should ever take most software engineers seriously.
Well written software should generally be able to double as documentation.
Just no.
Well-written software (i.e. clean code, clear functions) is great and a joy to work with, but is absolutely not a substitute for documentation. Public APIs are double-triple-extra not exempt by merely being well-written, especially not C/C++ APIs, which have complex meta-details like "is this thread-safe?", "does this allocate memory?", "can I call this twice using the same object?", etc.
I get that if code is clear enough, it should be self-documenting. That alleviates the need to write as many comments. //Comments//. It's not a user manual. It's not an explanation of architecture. It's not a help guide. It's not an example of how to use it. It's not best practices. It's not how to write a plugin for your system. It's not an explanation of why the software is needed or where it fits into the business's plan. It's. Just. Code.
I've inherited enough undocumented code to take new stance: if I quit tomorrow and people are unable to train a new person to fully understand my code without me to train them, then I'm doing it wrong. "Wizards" are also liabilities.
Well-written software (i.e. clean code, clear functions) is great and a joy to work with, but is absolutely not a substitute for documentation. Public APIs are double-triple-extra not exempt by merely being well-written, especially not C/C++ APIs, which have complex meta-details like "is this thread-safe?", "does this allocate memory?", "can I call this twice using the same object?", etc.
I get that if code is clear enough, it should be self-documenting. That alleviates the need to write as many comments. //Comments//. It's not a user manual. It's not an explanation of architecture. It's not a help guide. It's not an example of how to use it. It's not best practices. It's not how to write a plugin for your system. It's not an explanation of why the software is needed or where it fits into the business's plan. It's. Just. Code.
I've inherited enough undocumented code to take new stance: if I quit tomorrow and people are unable to train a new person to fully understand my code without me to train them, then I'm doing it wrong. "Wizards" are also liabilities.
Ok, let's say that the code can double as documentation (which is what I stated), and not that the code doubles as all of the documentation.
The code should be able to provide you with the how and the why (supplied with proper testing that covers planned use cases, and comments when testing and code are insufficient.) When code is well written it will answer a lot of questions, I encounter this almost daily when reviewing code.
What code is not is a manual or instructions on plugin writing, etc. You are right on the money there. It's also not API documentation, again, right on the money.
The code should be able to provide you with the how and the why (supplied with proper testing that covers planned use cases, and comments when testing and code are insufficient.) When code is well written it will answer a lot of questions, I encounter this almost daily when reviewing code.
What code is not is a manual or instructions on plugin writing, etc. You are right on the money there. It's also not API documentation, again, right on the money.
Even the cleanest code will only ever tell you how something is done, and not why.
The best-factored simply-named controller source or whatever else will not, in isolation and without documentation, ever tell you why we are asking the computer to do the things it does.
The problem with this is that somebody (rightly or wrongly) will see the code one day, and infer what they think it is doing, and change it, and break things elsewhere in the world.
If you don't want that to happen, you are forced to only ever write code that matches the exact logic of what already exists--and because you, rockstar ninja cowboy that you are, don't have any documentation including business use cases or logic for a particular hack or inelegance, you must then look on and only make the mildest of changes to the sacred monolith.
Or, you know, you could document your projects and software like a real engineer, and others can later check that they can make changes with impunity--or even better, throw away chunks of unneeded code wholesale because their time is (according to the docs!) past.
EDIT:
This whole "The code is the documentation hurrrr" meme is really annoying--it can only express the hows and not the whys. There is more to software than simply the steps the computer takes to transform data.
If there wasn't, we'd still be using assembly and Perl every day.
The best-factored simply-named controller source or whatever else will not, in isolation and without documentation, ever tell you why we are asking the computer to do the things it does.
The problem with this is that somebody (rightly or wrongly) will see the code one day, and infer what they think it is doing, and change it, and break things elsewhere in the world.
If you don't want that to happen, you are forced to only ever write code that matches the exact logic of what already exists--and because you, rockstar ninja cowboy that you are, don't have any documentation including business use cases or logic for a particular hack or inelegance, you must then look on and only make the mildest of changes to the sacred monolith.
Or, you know, you could document your projects and software like a real engineer, and others can later check that they can make changes with impunity--or even better, throw away chunks of unneeded code wholesale because their time is (according to the docs!) past.
EDIT:
This whole "The code is the documentation hurrrr" meme is really annoying--it can only express the hows and not the whys. There is more to software than simply the steps the computer takes to transform data.
If there wasn't, we'd still be using assembly and Perl every day.
Agile is software. How can you talk Agile without involving the people who create it?
And yet, non-devs are the people that talk about going to these Agile conferences. They're also the people targeted for Certified Scrum Master certifications. The movement of Agile away from developers has been happening for awhile. It's just another management philosophy now.
Does it matter that the people creating the software are no longer at the table.
Yes. Full stop.
All in all, I feel that the author is simply answering his own questions.
And yet, non-devs are the people that talk about going to these Agile conferences. They're also the people targeted for Certified Scrum Master certifications. The movement of Agile away from developers has been happening for awhile. It's just another management philosophy now.
Does it matter that the people creating the software are no longer at the table.
Yes. Full stop.
All in all, I feel that the author is simply answering his own questions.
> The movement of Agile away from developers has been happening for awhile. It's just another management philosophy now.
No, its not. Its a management buzzword now. It started as a philosophy, and where it still is, the substance of its principles remains important. But, increasingly, its become a meaningless phrase that marketeers that neither understand nor care about technology slap on snake oil to sell it to managers that are out of the day-to-day process of technology.
No, its not. Its a management buzzword now. It started as a philosophy, and where it still is, the substance of its principles remains important. But, increasingly, its become a meaningless phrase that marketeers that neither understand nor care about technology slap on snake oil to sell it to managers that are out of the day-to-day process of technology.
Its a management buzzword now.
To expand on this a little -- members of larger organizations have succeeded in neutralizing a threat to their perceived interests by making the language mean less than it used to. Effective agile practice breaks down a barrier between people making decisions and people doing the work. That must feel like a threat if your position involves little more than politely instructing other people what to do.
To expand on this a little -- members of larger organizations have succeeded in neutralizing a threat to their perceived interests by making the language mean less than it used to. Effective agile practice breaks down a barrier between people making decisions and people doing the work. That must feel like a threat if your position involves little more than politely instructing other people what to do.
> To expand on this a little -- members of larger organizations have neutralized a threat by making the language mean less than it used to.
I think that looking at it as threat neutralization is badly misleading. I don't think management saw agile as a threat and neutralized, I think (1) management saw it as something that was producing value that they wanted to harness and implement, but generally failed to understand, and (2) people selling to management recognized this demand, and slapped the valuable label on whatever they could package. No threat, all opportunity. But same net effect.
> Effective agile practice breaks down a barrier between people making decisions and people doing the work. That must feel like a threat if your position involves little more than politely instructing other people what to do.
Honestly, I think that that the subset of management that understands agile well enough that they could feel threatened by it if they couldn't find a way to profit from it is the same subset that understands how to let it happen and own the results. The one that would be threatened by it if they could understand it well enough don't.
I think that looking at it as threat neutralization is badly misleading. I don't think management saw agile as a threat and neutralized, I think (1) management saw it as something that was producing value that they wanted to harness and implement, but generally failed to understand, and (2) people selling to management recognized this demand, and slapped the valuable label on whatever they could package. No threat, all opportunity. But same net effect.
> Effective agile practice breaks down a barrier between people making decisions and people doing the work. That must feel like a threat if your position involves little more than politely instructing other people what to do.
Honestly, I think that that the subset of management that understands agile well enough that they could feel threatened by it if they couldn't find a way to profit from it is the same subset that understands how to let it happen and own the results. The one that would be threatened by it if they could understand it well enough don't.
There is a contingent of managers who feel that users talking to devs is somehow a threat.
"I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?"
Effective agile practice breaks down a barrier between people making decisions and people doing the work.
I like having a rate limiter between me and the people who keep changing their minds about what I should be doing. I like being able to outsource the job of talking sense into those people.
I like having a rate limiter between me and the people who keep changing their minds about what I should be doing. I like being able to outsource the job of talking sense into those people.
All too often the person between me and the people who keep changing their minds are sales people who will tell the customer that everything is possible, and usually for free.
Agreed. Good management doesn't bother me about every little change and gets the customer to appreciate what we can actually deliver.
Effective agile practice breaks down a barrier between people making decisions and people doing the work. That must feel like a threat if your position involves little more than politely instructing other people what to do.
Yes indeed. There have been many times when I've been explicitly forbidden to talk to actual users in big companies.
Yes indeed. There have been many times when I've been explicitly forbidden to talk to actual users in big companies.
Were there reasons given for this? Two somewhat reasonable possibilities that immediately come to mind are (1) the difference between anecdotes and solid data; and (2) wanting to have decisions and rationales documented.
This has happened to me a lot too. A lot of times there will be tons of politics involved and for whatever reason somebody (a team or project lead) may want to portray 'their' version of the narrative mostly for political reasons.
At one place where I worked there were 4-5 big teams with different technology specializations and for every big project we did, these 4 teams had to have a cut of the project for budgeting purposes.
So no matter if there was a need for it or not, youd have BizTalk, or SAP, or SalesForce or whatever inject themselves into a solution and create a complete mess from an architecture standpoint. Completely idiotic.
At one place where I worked there were 4-5 big teams with different technology specializations and for every big project we did, these 4 teams had to have a cut of the project for budgeting purposes.
So no matter if there was a need for it or not, youd have BizTalk, or SAP, or SalesForce or whatever inject themselves into a solution and create a complete mess from an architecture standpoint. Completely idiotic.
Specifically that the users don't always "know what's best."I could well be "(1) the difference between anecdotes and solid data; and (2) wanting to have decisions and rationales documented." The problem is that this is biased against genuine insights by the user population.
I used to be in 'Enterprise' development and I have noticed that a lot of people I knew who were doing PM work have now jumped onto the Agile bandwagon.
>Is it because we’ve been hijacked by Scrum professionals, certification wonks, vendors, and other ‘professionals’ who do everything but deliver software?
Right on the money I'm afraid.
Right on the money I'm afraid.
Yep, the "Agile" that I was taught through a 2-day course I went to for a client I used to work with was quite different than the "Core Agile" that was laid out originally. It didn't take long for the company to slide back into a sort of waterfall-agile or, as this author phrases it "everyone is falling backwards reverting to 30 day waterfall sprints under the umbrella of Scrum".
Really sad that at the end of the day "Agile" meant more admin work and meetings and no noticeable improvements (to me). Of course management saw "improvements" but the "scrum masters" would just tweak numbers to make it look like we met deadlines or completed enough story points. It was really sickening to watch everyone pat everyone else on the back for doing a good job when I knew at least 1/3rd of the scrum teams didn't get close to what they were supposed to accomplish.
Really sad that at the end of the day "Agile" meant more admin work and meetings and no noticeable improvements (to me). Of course management saw "improvements" but the "scrum masters" would just tweak numbers to make it look like we met deadlines or completed enough story points. It was really sickening to watch everyone pat everyone else on the back for doing a good job when I knew at least 1/3rd of the scrum teams didn't get close to what they were supposed to accomplish.
It goes both ways. I've been at a company that had "scrum coaches" that ensured the Agile practices were followed to the letter and fought against the higher managers when they pushed back in waterfall like ways. Agile was quite a success and we shipped a ton of bug free/stable released of our product in 1/6 the time as anyone in the corporate had bid the job at. The process also engaged and empowered developers far more than they had been in the past.
Conversely, at another employer they pasteurized "agile" into their own canned "agile-fall" methodology that had many antipodal theoretical conflicts, resulting in just 4 week single iteration waterfall sprints. The results of said agile-fall were very lackluster as no one was empowered, and there no greater clarity into process for dev's.
As such, there is certainly a right and wrong way to do agile. I'd say too many companies fear it because it let's the patients run the asylum (dev's) and reveals that you really don't need so many PHB's.
Conversely, at another employer they pasteurized "agile" into their own canned "agile-fall" methodology that had many antipodal theoretical conflicts, resulting in just 4 week single iteration waterfall sprints. The results of said agile-fall were very lackluster as no one was empowered, and there no greater clarity into process for dev's.
As such, there is certainly a right and wrong way to do agile. I'd say too many companies fear it because it let's the patients run the asylum (dev's) and reveals that you really don't need so many PHB's.
This seems pretty dead-on. When hiring for a company, it's generally understood that having talented developers in your company will help attract other talented developers.
As the groups mentioned in the above comment have shown a stronger presence, even more people from these groups appear. And, as the number of developers has dwindled, there has been less reason for others in their profession to come and share.
As the groups mentioned in the above comment have shown a stronger presence, even more people from these groups appear. And, as the number of developers has dwindled, there has been less reason for others in their profession to come and share.
Why would one need a conference to discuss a process that should be explainable in 5 minutes. If you can't reasonably explain your development process (agile or not) in 5 minutes, it's broken. If it takes you hours to explain your process, how many days does it take to implement and how much time is left over for actual development? I think most developers see through the bullshit of certified scrum masters and other such nonsense and its detrimental effect on productivity and don't want to waste even more time on this.
I saw agile implemented at a smaller team at a large corp. They explained their approach to me in about 3 sentences when I joined as an intern. They had no scum master because they didn't add a scrum master initially so no scrum master felt like his job/role was at stake if he didn't feel important.
Exactly. And don't get me started on all the buzz-following-I-never-wrote-two-lines-of-code hipsters at this events.
Oh! And also, Lego. I'm a grown man, come on!
Oh! And also, Lego. I'm a grown man, come on!
As a developer, I want to think about code. If I have the choice of learning something new, or digging into a new skillset it is going to be about code- not project management.
The last thing I feel like doing is sitting in a conference of non-technical people talking about how some new funny words they made up in project management will fix everything. Scrum masters, vendors, etc... it all just doesn't really engage me any more than talking about concurrency gets a project manager going.
This isn't to say that I don't think PM isn't important, but just that it really isn't a terribly interesting problem. I haven't seen (personally) that many scenarios where some new trick from a PM book, class, conference has actually made the difference in a project coming in on time/budget.
I personally like a lot of Agile stuff, but I don't strictly adhere to any specific one, nor do I want to in a small team. I just want to produce good code.
The last thing I feel like doing is sitting in a conference of non-technical people talking about how some new funny words they made up in project management will fix everything. Scrum masters, vendors, etc... it all just doesn't really engage me any more than talking about concurrency gets a project manager going.
This isn't to say that I don't think PM isn't important, but just that it really isn't a terribly interesting problem. I haven't seen (personally) that many scenarios where some new trick from a PM book, class, conference has actually made the difference in a project coming in on time/budget.
I personally like a lot of Agile stuff, but I don't strictly adhere to any specific one, nor do I want to in a small team. I just want to produce good code.
> As a developer, I want to think about code. If I have the choice of learning something new, or digging into a new skillset it is going to be about code- not project management.
Obviously this.
I suppose I might attend an agile conference in the unlikely event my employer desperately wanted to send me to one. Even then I'd probably try to discourage them from the notion in order to get the money spent somewhere more productive (technical conferences, specialized training, etc.)
Obviously this.
I suppose I might attend an agile conference in the unlikely event my employer desperately wanted to send me to one. Even then I'd probably try to discourage them from the notion in order to get the money spent somewhere more productive (technical conferences, specialized training, etc.)
The Agile processes are ways for managers to enforce a manufacturing-like process to software development to micro manage development activities to squeeze every little bit of productivity out of developers in the expense of creativity. They work well for managing junior developers or for body shop. Senior developers hate them.
The daily meetings usually turn into daily status meetings, no matter how much the Agile advocates claim otherwise. The rough estimate become a hard deadline, with daily remainder of why it's slipping. Pair programming - free training for junior developers, a waste of time for senior developers.
The daily meetings usually turn into daily status meetings, no matter how much the Agile advocates claim otherwise. The rough estimate become a hard deadline, with daily remainder of why it's slipping. Pair programming - free training for junior developers, a waste of time for senior developers.
> Pair programming - free training for junior developers, a waste of time for senior developers.
The fact that you consider training a waste is depressing. Good senior developers recognize that training is critically important unless they want to do everything personally – and it's extremely rare that you don't learn something, too. If it's a waste of time, you're doing it wrong - a truly senior developer would learn from that and fix something.
The fact that you consider training a waste is depressing. Good senior developers recognize that training is critically important unless they want to do everything personally – and it's extremely rare that you don't learn something, too. If it's a waste of time, you're doing it wrong - a truly senior developer would learn from that and fix something.
It wouldn't be a waste of time if there were not an endemic bias against both having older developers and paying them more for their experience.
As the employer-employee loyalty culture has been systematically destroyed, I am far more likely to see the training of more junior developers as training my own replacement than as improving the capabilities of my team.
If you want me to train someone in anything, you really ought to make me feel secure in my position, such as by offering me some form of job security. For the sake of discussion, let's just call that "tenure". If I am an "at will" employee, the only form of job security at my disposal is to be indispensable, and training others undermines that.
So if your company has a clear career path, with employees from entry-level tenderfoot to ultra-senior guru, and every step in between, you might feel good about training. If, on the other hand, your office is full of young bros, and the dusties are encouraged to move out to pasture when it's time, your time is coming.
If a company truly has a commitment to training, a necessary prerequisite is a commitment to long-term employee retention.
As the employer-employee loyalty culture has been systematically destroyed, I am far more likely to see the training of more junior developers as training my own replacement than as improving the capabilities of my team.
If you want me to train someone in anything, you really ought to make me feel secure in my position, such as by offering me some form of job security. For the sake of discussion, let's just call that "tenure". If I am an "at will" employee, the only form of job security at my disposal is to be indispensable, and training others undermines that.
So if your company has a clear career path, with employees from entry-level tenderfoot to ultra-senior guru, and every step in between, you might feel good about training. If, on the other hand, your office is full of young bros, and the dusties are encouraged to move out to pasture when it's time, your time is coming.
If a company truly has a commitment to training, a necessary prerequisite is a commitment to long-term employee retention.
These can all be real problems but they say nothing about pair programming or agile and everything about the toxic culture at some places
You can take a process that grows out of a healthy culture and transplant it into a toxic one. Agile practices and pair programming cannot be divorced from the team culture. To do otherwise is cargo cult ritual management.
There is very little inherent to pair programming in itself that can be considered good or bad in isolation from the people using it. Good teams follow good practices. This is not because the practices are good, but because the team finds them to be temporarily useful to meet their specific needs.
If your manager went to a conference, learned about agile stuff, and returned to institute pair programming, you will likely find that to be of dubious value. If your team decides internally that the new hire should do pair programming with each of the existing team members until the greenness fades, that will probably have a better outcome.
There is very little inherent to pair programming in itself that can be considered good or bad in isolation from the people using it. Good teams follow good practices. This is not because the practices are good, but because the team finds them to be temporarily useful to meet their specific needs.
If your manager went to a conference, learned about agile stuff, and returned to institute pair programming, you will likely find that to be of dubious value. If your team decides internally that the new hire should do pair programming with each of the existing team members until the greenness fades, that will probably have a better outcome.
Pair programming is not training. It is not the main function of pair programming. The fact training becomes the most important reason trumpeted for pair programming speaks fully how ill conceited the concept is.
I'm all for training. I'm against 8-hour a day, 5-day a week pair programming. Even if training is so important, developers are not signing up to be a professional trainer.
I'm all for training. I'm against 8-hour a day, 5-day a week pair programming. Even if training is so important, developers are not signing up to be a professional trainer.
Pair programming is a tool just like everything else. It should be used when it's effective and not used when it's not. It can be effective at times. I completely agree that 8 hours a day, 5 days a week pair programming is highly ineffective.
[deleted]
(1) There are no such thing as "Agile processes", and anyone that tells you there is is lying to sell you a process.
(2) The only relation anything "Agile" has to do with manufacturing is that the Agile approach to software is close parallels to Lean methodologies in manufacturing (which have circled around to create Lean software methodologies.) But Lean, while it is an approach to improving productivity, is pretty much the opposite of doing so at the expense of the creativity of the line workers, as they rest on the combination of defining and measuring value and harnessing the deep knowledge of the workforce to propose, implement, and test methods of improving value produced.
(2) The only relation anything "Agile" has to do with manufacturing is that the Agile approach to software is close parallels to Lean methodologies in manufacturing (which have circled around to create Lean software methodologies.) But Lean, while it is an approach to improving productivity, is pretty much the opposite of doing so at the expense of the creativity of the line workers, as they rest on the combination of defining and measuring value and harnessing the deep knowledge of the workforce to propose, implement, and test methods of improving value produced.
Lean, applied to software, would mean that the software team can see opportunities to improve their process and/or tools, and would have the power to do so.
I've actually been on a team that did this. "For the next two-week iteration, we're going to change the process in this way, and we'll see how that works."
Process doesn't have to be a static thing handed down from on high. Hack it. Make it work for you. (One of the agile approaches to software is "pay attention to pain". That is, when it's hard to change the software in some way, that's telling you that it should be refactored so that it quits being hard to change it in that way. Well, the same thing works for process. If the process is painful, pay attention. It's telling you that you need to change the process.)
I've actually been on a team that did this. "For the next two-week iteration, we're going to change the process in this way, and we'll see how that works."
Process doesn't have to be a static thing handed down from on high. Hack it. Make it work for you. (One of the agile approaches to software is "pay attention to pain". That is, when it's hard to change the software in some way, that's telling you that it should be refactored so that it quits being hard to change it in that way. Well, the same thing works for process. If the process is painful, pay attention. It's telling you that you need to change the process.)
> Lean, applied to software, would mean that the software team can see opportunities to improve their process and/or tools, and would have the power to do so.
Yes, that's exactly what Lean in software means (and you'll note that it has a very close relation to Agile principles -- Lean is pretty much Agile with more focus on measurable output and several decades more of development behind it -- both for the good and the bad [there's a lot of depth in the literature of practices and how and when they work to draw from for your circumstances, but there's also breadth and depth in the buzzword snake-oil].)
Yes, that's exactly what Lean in software means (and you'll note that it has a very close relation to Agile principles -- Lean is pretty much Agile with more focus on measurable output and several decades more of development behind it -- both for the good and the bad [there's a lot of depth in the literature of practices and how and when they work to draw from for your circumstances, but there's also breadth and depth in the buzzword snake-oil].)
Agile & Lean have quite a few things in common such delivering lots of little chunks of value to customer as fast possible. Not doing things in large batches etc. Asking the people doing the work to implement improvements, since they know the work etc
There are agile practices though. Some of them are so simple we don't even think of them as being a practice.
Practices like continuous integration and unit testing traditionally fell into that category. I would say these days that writing unit tests is so common that it doesn't feel like it came from anywhere. Just that it always existed.
Practices like continuous integration and unit testing traditionally fell into that category. I would say these days that writing unit tests is so common that it doesn't feel like it came from anywhere. Just that it always existed.
I think the important thing to keep in mind is that while Agile principles may sometimes be commonly well served by certain sets of practices or processes, the practices/processes themselves are usually not Agile (except for the high-level process of evaluating and selecting processes -- Agile is about choosing the process that works for the actual set of people you have, not about choosing process based on considerations outside of the work groups ability to produce quality software.)
The ossification of Agile into a set of cargo cult practices divorced from the particular teams and their needs flips Agile into exactly what it was a reaction against.
The ossification of Agile into a set of cargo cult practices divorced from the particular teams and their needs flips Agile into exactly what it was a reaction against.
I agree 100%.
In my experience the main thing to keep in mind to improving any system is to:
1. See what state you are in 2. Figure out what new state you would like to be in 3. Guess at something that will help you move into that state and then follow that guess. 4. See if that move helped you get closer to that state 5. goto 1
People label those steps with lots of names depending on what industry they work in but in the end that is the easiest way to get better.
In my experience the main thing to keep in mind to improving any system is to:
1. See what state you are in 2. Figure out what new state you would like to be in 3. Guess at something that will help you move into that state and then follow that guess. 4. See if that move helped you get closer to that state 5. goto 1
People label those steps with lots of names depending on what industry they work in but in the end that is the easiest way to get better.
> Pair programming - free training for junior developers, a waste of time for senior developers.
I disagree. That's not how you build a team. Also, senior developers who can't pair program, aren't senior developers. That means you can't communicate, or at least you don't want to, even if it's talking about code you don't want to. That's not how you become a lead/architect.
I disagree. That's not how you build a team. Also, senior developers who can't pair program, aren't senior developers. That means you can't communicate, or at least you don't want to, even if it's talking about code you don't want to. That's not how you become a lead/architect.
> Also, senior developers who can't pair program, aren't senior developers.
Ah yes, the cliched "if you don't do X you can't call yourself Y" shtick. I know many senior developers that don't pair program. Why? It's inefficient and they get significantly less done. Not to mention, you have no room to experiment with different approaches because you've got some person sitting next to you and human emotion kicks in and they feel like they're being watched and judged at every move.
You know when pair programming is endorsed by the senior developers? Root-causing bugs.
Ah yes, the cliched "if you don't do X you can't call yourself Y" shtick. I know many senior developers that don't pair program. Why? It's inefficient and they get significantly less done. Not to mention, you have no room to experiment with different approaches because you've got some person sitting next to you and human emotion kicks in and they feel like they're being watched and judged at every move.
You know when pair programming is endorsed by the senior developers? Root-causing bugs.
Who wants to build a team? Some of us are just there to get the job done and get out...
I can communicate very well, and am helpful as I can be when people need it. But slow-as-molasses pair programming with an 8nexperienced junior sounds like hell to me.
I can communicate very well, and am helpful as I can be when people need it. But slow-as-molasses pair programming with an 8nexperienced junior sounds like hell to me.
I disagree. You don't need pair programming to build a team. Overwhelming percentage of successful teams exist without pair programming.
One can be an effective leader, communicates well, designs and architects large system, mentors junior developers, inspires them to learn, coordinates development effort, sets up development processes and standards, and develops awesome software without doing pair programming.
Pair programming is not the only and true way to develop software. It's just some passé imposed by Agile advocates.
One can be an effective leader, communicates well, designs and architects large system, mentors junior developers, inspires them to learn, coordinates development effort, sets up development processes and standards, and develops awesome software without doing pair programming.
Pair programming is not the only and true way to develop software. It's just some passé imposed by Agile advocates.
As a dev, I like agile (or at least the idea behind agile) because it allows me to code more and meet with people less. If other developers are anything like me I have no problem understanding why developers aren't showing up to these conferences (basically day long meetings about meeting structures).
Once Agile was co-opted by management, it was time to move on.
Co-opted is the correct word.
I like the idea of story points as a tool for communicating with each other about rough estimates. I don't like story points as a source of data for management to put into spreadsheets and use in dubious "velocity calculations". I especially don't like the results of those calculations being used to measure my individual productivity and set expectations about my future work rate.
The language of agile has been co-opted to suit the needs of mediocre managers.
I like the idea of story points as a tool for communicating with each other about rough estimates. I don't like story points as a source of data for management to put into spreadsheets and use in dubious "velocity calculations". I especially don't like the results of those calculations being used to measure my individual productivity and set expectations about my future work rate.
The language of agile has been co-opted to suit the needs of mediocre managers.
Exactly this. Agile was converted from an adjective to a noun, and then people started selling the noun.
There's only so much you can charge someone to tell them, "The skills your developers possess for creating and modifying computerized systems can also be applied to organizing software development teams. Just make it part of their jobs to improve their own process, and give them frequent, objective feedback on how they are doing."
There's only so much you can charge someone to tell them, "The skills your developers possess for creating and modifying computerized systems can also be applied to organizing software development teams. Just make it part of their jobs to improve their own process, and give them frequent, objective feedback on how they are doing."
Yes. That could apply to other things as well. Once anything is co-opted by management it's time to move. If management would just learn to program...
As a developer, I know how Agile works. It's pretty simple. Now why would I want to waste a few days of working time to go to a conference about it? Most people can probably do zero to two conferences a year paid by their employer. To me this sounds incredibly boring compared to something related to my field or ecosystem.
This is not entirely a bad thing, although many of the negative conclusions drawn by the author are true.
One of main obstacles for going Agile has always been that it really needed all of the organisation to change, not just the developers.
Also, Agile conferences aren't really that interesting for developers anymore. We've already adopted most of the development practices to the point where many developers are no longer aware that they came out of, or at least became mainstream because of, the Agile and XP movement.
Most of us are Agile without being aware of it, which in turn leads to hilarious anti-Agile rants (based on experiences with top-down enforced cargo cult "Agile") in which the authors propose alternative practices that are typically Agile and tick all the boxes of the Agile manifesto...
The hard part about Agile is still adapting the entire organisation's processes, which generally is of more interest to management-types than to developers.
Finally, you would be surprised to learn how many people that are active stakeholders in software development processes only now start to learn what Agile is.
For most of us, in our fashions and fads driven bubble end of the industry, Agile is already passé, but for many it's still a revelation.
One of main obstacles for going Agile has always been that it really needed all of the organisation to change, not just the developers.
Also, Agile conferences aren't really that interesting for developers anymore. We've already adopted most of the development practices to the point where many developers are no longer aware that they came out of, or at least became mainstream because of, the Agile and XP movement.
Most of us are Agile without being aware of it, which in turn leads to hilarious anti-Agile rants (based on experiences with top-down enforced cargo cult "Agile") in which the authors propose alternative practices that are typically Agile and tick all the boxes of the Agile manifesto...
The hard part about Agile is still adapting the entire organisation's processes, which generally is of more interest to management-types than to developers.
Finally, you would be surprised to learn how many people that are active stakeholders in software development processes only now start to learn what Agile is.
For most of us, in our fashions and fads driven bubble end of the industry, Agile is already passé, but for many it's still a revelation.
It was about being agile, which is what developers were striving for. Now it's about doing agile which is in direct conflict with the notion of being agile.
I see an analogy between what happened to Agile and what happened to "Object-oriented". Both were, at a time (IMHO) genuinely useful, fresh and thus popular with developers.
Both got a bit overdone (Java: everything must be a method of an object!) and hijacked by the Certified Formal Methodologies people and pointy-haired bosses. People found the limitations of both Agile and Object-oriented - there's no silver bullet after all. The good things got incorporated into the set of good practices (and became obvious and thus not worth mentioning) the bad things are labeled as bad (although some stick with us.) Life goes on.
Agile is obviously a bit earlier in this lifecycle - I believe there are no mainstream object-oriented conferences anymore while Agile ones still exist.
Both got a bit overdone (Java: everything must be a method of an object!) and hijacked by the Certified Formal Methodologies people and pointy-haired bosses. People found the limitations of both Agile and Object-oriented - there's no silver bullet after all. The good things got incorporated into the set of good practices (and became obvious and thus not worth mentioning) the bad things are labeled as bad (although some stick with us.) Life goes on.
Agile is obviously a bit earlier in this lifecycle - I believe there are no mainstream object-oriented conferences anymore while Agile ones still exist.
Many of the developers in this community don't care that much about Agile development as a concept, because we are startup devs that prefer to work in a company that only has 3-5 devs total and doesn't need a fancy named system to make the development cycle work.
To us, "Agile" is the organizational system that you need to build out once the company scales up to lots of devs, but by that time we are already gone, working at a new startup building new stuff in another tiny team. We don't like the organizational cruft, we just like the process of building stuff, preferably with limited management.
To us, "Agile" is the organizational system that you need to build out once the company scales up to lots of devs, but by that time we are already gone, working at a new startup building new stuff in another tiny team. We don't like the organizational cruft, we just like the process of building stuff, preferably with limited management.
Agile only really works for teams of 3-7. It's defiantly not a methodology for larger teams.
There are things for scaled up Agile development such as SAFe, but it's really a hack.
There are things for scaled up Agile development such as SAFe, but it's really a hack.
> Agile only really works for teams of 3-7.
The usual rule of thumb is that "atomic" teams should be 5-9 members (often expressed as 7 plus-or-minus 2), with larger groups as teams-of-teams. Larger teams simply don't work as single teams, and there's centuries of experience supporting that in pretty much every field everywhere.
The usual rule of thumb is that "atomic" teams should be 5-9 members (often expressed as 7 plus-or-minus 2), with larger groups as teams-of-teams. Larger teams simply don't work as single teams, and there's centuries of experience supporting that in pretty much every field everywhere.
I once worked on an XP team of 30. It worked. We had people who specialized in some areas of the code, but we worked hard on avoiding silos.
Most of the research says agile teams of 7+-2 are best. At my work we have been trying to look at the differences that team size makes in software output.
SAFe is interesting because it can help show large companies understand the value to using XP practices. Crazy ideas like unit testing your code.
SAFe is interesting because it can help show large companies understand the value to using XP practices. Crazy ideas like unit testing your code.
I think you're mistaking "common wisdom" for research. A lot of people like to say 7 +/- 2, but as I understand it, that number comes from studies of short-term memory. (It's why phone numbers in the US are 7 digits.) Research of teams (not specific to Agile) puts the maximum effective size closer to 12, and the maximum size of a "tribe" around 150-200.
My own experience is that 12 people works great for an agile team, with 6-8 of them being programmers. If you're not using pair programming, cut those numbers in half.
My own experience is that 12 people works great for an agile team, with 6-8 of them being programmers. If you're not using pair programming, cut those numbers in half.
Yeah you are right, I asked Larry Maccherone to see if there was prior research about that common belief in the 7 person team and he was not aware of any.
If you are interested in hearing about some of the current research that we are doing about team size you can check into it on this video. I am not sure he is ready to publish his work but this can give you a taste of it.
http://www.youtube.com/watch?v=9Trgz2SAz0k&list=PLSRf1YEPZ7u...
If you are interested in hearing about some of the current research that we are doing about team size you can check into it on this video. I am not sure he is ready to publish his work but this can give you a taste of it.
http://www.youtube.com/watch?v=9Trgz2SAz0k&list=PLSRf1YEPZ7u...
Where I work, what began as a studiously followed Scrum process (where teams decided which parts were important and which weren't) has devolved into "we put a bunch of stuff in Trello and take it off as if we are short order cooks" and we never meet to reflect on what we've been doing. Very little enthusiasm for process all around. And as everyone knows, Agile has won so thoroughly that it's a meaningless buzzword. Everyone says they're agile even if they aren't. But I doubt I would ever go to an "agile conference", whatever that is.
At every single company I've worked at an Agile-like approach was used. This meant that the daily catch-up is called a Scrum, and that instead of working in a Waterfall approach we've created sprints of however long was needed to fit a bunch of tasks in. Also, instead of writing large spec documents that are signed off and given to a developer to implement we create a smaller spreadsheet of deliverables, and later changes are introduced into later sprints.
Naturally, things tend to fall apart when the spec isn't accurate, or when an estimate is off. In a client-facing business like an agency these approaches often fall apart when the client isn't getting something when they want it.
I've interviewed at a number of large agencies and it all seems to be the same. Everyone does Agile...kinda. They have the general feeling down, but they all skip some parts to make it usable for their clients.
This brings me to ask, does anyone REALLY do it properly in an agency setting? If you do it properly in a client-facing industry will it fall apart, or are people just too lazy to fully embrace Agile? I'm yet to hear of anyone doing it well, but I would love to hear from someone that knows how to do it well in a team of 15-20 people containing developers and Project Managers.
Naturally, things tend to fall apart when the spec isn't accurate, or when an estimate is off. In a client-facing business like an agency these approaches often fall apart when the client isn't getting something when they want it.
I've interviewed at a number of large agencies and it all seems to be the same. Everyone does Agile...kinda. They have the general feeling down, but they all skip some parts to make it usable for their clients.
This brings me to ask, does anyone REALLY do it properly in an agency setting? If you do it properly in a client-facing industry will it fall apart, or are people just too lazy to fully embrace Agile? I'm yet to hear of anyone doing it well, but I would love to hear from someone that knows how to do it well in a team of 15-20 people containing developers and Project Managers.
Developers find the most value in meeting with other developers. Being that Agile was created by developers, you can imagine we're a bit disheartened when we go to Agile meetups flooded with Scrum (which is complete trash and not in the interest of developers in the least bit) "professionals."
The best discussions I have about Agile happen on the internet or at a programming meetup for languages, databases, etc.
The best discussions I have about Agile happen on the internet or at a programming meetup for languages, databases, etc.
It turned out agile processes contained a bunch of important but unpleasant aspects - business people needed to be much more present in daily development, while developers needed to meet with business people much more frequently (often at specific times when said business people were available) and keep lots of non-development action points in mind (as the team now had collective ownership of those action points).
So, in a stroke of mutual back slapping, everybody embraced the less objectionable features of agile methods - daily meetings, short iterations, reduce documentation and focus on shippable code - thus feeling really good about themselves. This caused ample moral licensing, letting most development team members and business people cut down on the unpleasant aspects.
This collective ball dropping was fortunately mitigated by a surplus of employees happy to pick up this poor, unloved ball. Being orderly people they would suggest improvements to the process to prevent further ball dropping, carving out a place and title for themselves while they were at it.
So, in a stroke of mutual back slapping, everybody embraced the less objectionable features of agile methods - daily meetings, short iterations, reduce documentation and focus on shippable code - thus feeling really good about themselves. This caused ample moral licensing, letting most development team members and business people cut down on the unpleasant aspects.
This collective ball dropping was fortunately mitigated by a surplus of employees happy to pick up this poor, unloved ball. Being orderly people they would suggest improvements to the process to prevent further ball dropping, carving out a place and title for themselves while they were at it.
As a developer and designer I think agile methodology is a nice add-on for traditional workflows in startups. I love how it encourages interdisciplinary work. But I believe it took an unexpected turn towards treating the technical side of things as a mere commodity.
Last weekend I attended Startup Weekend event, looking to have fun trying to build something fast from a simple idea pitch. First day more than 80% of the crowd were business / marketing peoples. Designers were scarce and half of the few developers disappeared during the second day. Maybe I’m a masochist but decided to stay until the end, I figured I’d learn something about the agile event fauna. And I did: in most cases the agile methodology is stepping on top of rational thinking.
Do before you think and fail fast is good, only when you know how to do.
Last time I was on SW I had a lot of fun, but last weekend’s experience was somewhat sad. Gurus and their new methodologies might have some to teach, but will never replace rational thinking.
Last weekend I attended Startup Weekend event, looking to have fun trying to build something fast from a simple idea pitch. First day more than 80% of the crowd were business / marketing peoples. Designers were scarce and half of the few developers disappeared during the second day. Maybe I’m a masochist but decided to stay until the end, I figured I’d learn something about the agile event fauna. And I did: in most cases the agile methodology is stepping on top of rational thinking.
Do before you think and fail fast is good, only when you know how to do.
Last time I was on SW I had a lot of fun, but last weekend’s experience was somewhat sad. Gurus and their new methodologies might have some to teach, but will never replace rational thinking.
Commoditization is already happening IMO; many devs have internalized agile to mean "slap together as many open source/SaaS APIs and then apply duct tape so it holds together."
You'll see this sentiment leak out when discussing the necessity of domain modeling or testing in a mature web app that continues to grow. There's always a contingent that shows up loudly complaining, "but that looks like work! I don't want to!" They believe they have to always be kowtowing to Business by constantly shipping features and patching over what breaks.
As michaelochurch likes to say, we've been colonized by businessmen. Our own ideas about productivity and quality are slowly being replaced by theirs.
You'll see this sentiment leak out when discussing the necessity of domain modeling or testing in a mature web app that continues to grow. There's always a contingent that shows up loudly complaining, "but that looks like work! I don't want to!" They believe they have to always be kowtowing to Business by constantly shipping features and patching over what breaks.
As michaelochurch likes to say, we've been colonized by businessmen. Our own ideas about productivity and quality are slowly being replaced by theirs.
Most people at my company who are attending Agile training/conferences or whatever are definitely not technical people. Mostly they are Project Managers, Continuos Improvement Six Sigma types, or non-technical people put on software projects.
I've always wondered if our Devs know Agile practices already, learn it on the fly, or dont care. I am going with the latter.
I've always wondered if our Devs know Agile practices already, learn it on the fly, or dont care. I am going with the latter.
For me, it is two things;
1. Agile methodology needs to be managed by someone, and this someone is not normally a developer (in my experience), it also needs to be understood by the client and other members in the team, and this again, in my experience is not the case.
2. Personally I feel I have a negative view of these meetups, I feel unfortunately surrounded by non-developers in my teams who are more interested in their linkedin profile appearance, or having a 'cool' job, uninterested in the intricacies of their job and how much of a benefit it has to everyone involved. Working with people who think that if they are not being paid, they shouldn't care, it can take the enthusiasm out of your developers, especially when they are expected to go the extra mile to make up for the lack of process and documentation.
I apologies in advance if this comment is not to the satisfaction of the community. Just my (possibly bitter) two cents.
I apologies in advance if this comment is not to the satisfaction of the community. Just my (possibly bitter) two cents.
It's going to happen to DevOps, too. :(
DevOps always appeared to me to be the more dev centric agile practices (XP, Continuous Integration -> Continuous Deployment, Cross Functional Teams) trying to detach themselves from the project management type practices so that they could have conversations with people that actually know the tech.
IBM has already thrown their weight behind the DevOps buzzword. It will probably be harder to mess with than traditional agile was.
IBM has already thrown their weight behind the DevOps buzzword. It will probably be harder to mess with than traditional agile was.
I'm already seeing problems where the focus is less on inter-team communication and more on tooling, which is a Bad Thing. Yeah, puppet/chef is wonderful. Cloud is wonderful. But the communication issue remains, and it's much harder to fix than the tech. It requires active management support to break the hierarchy.
Yeah, that is alway the main issue. Getting people to talk to each other is very challenging.
If you use an admittedly over simplistic explanation of DevOps as getting someone who understands the final deployment environment to sit nearby the people who are making stuff.
Then define Scrum as having someone who has some idea what the customers want sitting there too.
You can get a ton done with just doing that. Sure it's always better if everyone knows everything.
That was one of the things that makes small startup teams powerful. They spend very little time talking to people who are not empowered to make decisions.
That was one of the things that makes small startup teams powerful. They spend very little time talking to people who are not empowered to make decisions.
The wider process is the only part of software development that non-developers can understand[1]. Developers, given the choice, would probably rather go to meetups and conferences about technology than about process. These two facts create enough of a bias towards "agile" events being dominated by non-developers, and it becomes self-reinforcing after a while (developers are even less likely to want to go to the events once they realise how many non-developers are going).
[1] If they could understand development, they'd be developers
[1] If they could understand development, they'd be developers
My feeling nowadays is that to develop you need to know how to program, that means, you need to know something.
But to be a project manager or scrum master all you need is a chance, that's all you need, a chance to do something you don't understand, you don't know how is built nor how it works, later you can show up in conferences and training sessions (paid by the company of course) to try to improve your performance/understanding in your current position.
Knowing that, is hard to show up in some events, conferences and meet these bozos.
But to be a project manager or scrum master all you need is a chance, that's all you need, a chance to do something you don't understand, you don't know how is built nor how it works, later you can show up in conferences and training sessions (paid by the company of course) to try to improve your performance/understanding in your current position.
Knowing that, is hard to show up in some events, conferences and meet these bozos.
The company I work for follows an agile-ish methodology. Having attended some agile conferences I would say that there aren't really insights there for most of our developers.
We do TDD and run our projects through ticketing and a CI server. Once those policies and technologies were in place developers pretty much stopped caring what agile was.(that doesn't imply we don't do it we just don't really worry about the logistics of it)
I sort of think of agile as a interface language for management to interact with us.
We do TDD and run our projects through ticketing and a CI server. Once those policies and technologies were in place developers pretty much stopped caring what agile was.(that doesn't imply we don't do it we just don't really worry about the logistics of it)
I sort of think of agile as a interface language for management to interact with us.
I think it was like that originally, but now it is just another set of cargo cult rituals, with new management buzzwords.
The problem remains that managers in most companies cannot reliably discern the difference between valuable work product and the physical evidence of completely wasted time. They cannot tell at a glance whether the code and/or architecture is museum-quality or DailyWTF fodder. They cannot tell when the entire development team is colluding to implement mortgage-driven development. The fundamental flaw in the system is that managers and developers do not think in compatible ways. To the manager, a developer might as well be an alien, asking him for more cows and sharper scalpels. To a developer, the manager might as well be an alien, asking him to drop his pants and hop up onto the Probulator.
What is really needed is someone with both pointy hair and a neckbeard, who can translate easily between the people who need to cover their asses and justify their own existence, and the people who need both rational objectivity and aesthetic merit in their work. Both sides are needed, because honestly I have known too many co-workers that cannot seem to fathom that they don't get paid unless the work they do can somehow add value to the things the company actually sells to people outside the company.
The artist usually doesn't know when to sign the thing and ship it to the gallery, and the gallery salesman often has no idea what the piece is actually worth when a customer shows up to make an offer.
The problem remains that managers in most companies cannot reliably discern the difference between valuable work product and the physical evidence of completely wasted time. They cannot tell at a glance whether the code and/or architecture is museum-quality or DailyWTF fodder. They cannot tell when the entire development team is colluding to implement mortgage-driven development. The fundamental flaw in the system is that managers and developers do not think in compatible ways. To the manager, a developer might as well be an alien, asking him for more cows and sharper scalpels. To a developer, the manager might as well be an alien, asking him to drop his pants and hop up onto the Probulator.
What is really needed is someone with both pointy hair and a neckbeard, who can translate easily between the people who need to cover their asses and justify their own existence, and the people who need both rational objectivity and aesthetic merit in their work. Both sides are needed, because honestly I have known too many co-workers that cannot seem to fathom that they don't get paid unless the work they do can somehow add value to the things the company actually sells to people outside the company.
The artist usually doesn't know when to sign the thing and ship it to the gallery, and the gallery salesman often has no idea what the piece is actually worth when a customer shows up to make an offer.
I definitely agree with alot of your points. I guess what I meant to say was that for alot of organizations it seems to be useless paradigm gibberish.
For our organization it doesn't seem to be, and my purely unscientific observation would be that getting devs on board is more about tools and channeling them through a process. That, you can get someone through pretty quick because its primarily logistics based.
We have tickets that are tied to pull requests you have to submit your PRs for test tickets before you can submit your PRs for feature tickets we have a CI server that will run those PR's against the tests at which point we merge everything.
This makes it pretty straight forward how development has to get done.
Where as, getting people who aren't code driven on-board requires complex paradigm adoption about how we design projects and road-map the business. Some of these people end up at these types of trainings because they are the people who need the indoctrination the most.
Developers we have faced have a tendency to either just sort of shrug and go "ok" or to want to totally fight the system and tear it down and replace it with X. We do our best to weed the violent opposition types by using test writing as examples during interviews the violent opposition types usually get visibly frustrated by the "test then code" approach of TDD so we haven't had to much trouble identifying people like this.
The long and short would be:
I think that the thesis of the OP that lack of dev's is a problem can be rejected because engineering unit employees don't face the same hill climb to adoption that business unit employees do and that this has been enabled by the fact that:
developers have at this point written them selves tools to automate their own side of the paradigm... i.e Jira Github and so on
For our organization it doesn't seem to be, and my purely unscientific observation would be that getting devs on board is more about tools and channeling them through a process. That, you can get someone through pretty quick because its primarily logistics based.
We have tickets that are tied to pull requests you have to submit your PRs for test tickets before you can submit your PRs for feature tickets we have a CI server that will run those PR's against the tests at which point we merge everything.
This makes it pretty straight forward how development has to get done.
Where as, getting people who aren't code driven on-board requires complex paradigm adoption about how we design projects and road-map the business. Some of these people end up at these types of trainings because they are the people who need the indoctrination the most.
Developers we have faced have a tendency to either just sort of shrug and go "ok" or to want to totally fight the system and tear it down and replace it with X. We do our best to weed the violent opposition types by using test writing as examples during interviews the violent opposition types usually get visibly frustrated by the "test then code" approach of TDD so we haven't had to much trouble identifying people like this.
The long and short would be:
I think that the thesis of the OP that lack of dev's is a problem can be rejected because engineering unit employees don't face the same hill climb to adoption that business unit employees do and that this has been enabled by the fact that:
developers have at this point written them selves tools to automate their own side of the paradigm... i.e Jira Github and so on
Many devs I speak and work with are either ambivalent or disillusioned about agile. In my circles this article keeps coming up in discussions about agile - https://securosis.com/blog/agile-development-and-security/.
Errr, while I agree that Agile has a hard time producing secure code, I see little evidence that non-Agile has any easier of a time. Sure, in theory Agile under some interpretations [1] precludes the sort of thoughtful design that security requires, but it's not as if very many projects are getting it right without Agile either. To a first approximation, everybody does security this way:
[1]: That caveat is important, please do not reply as if it is not there.
1. Some developer who thinks they understand security, but really doesn't,
make some vague sketches on a napkin that describe how one particular
attack, which isn't even that big a threat in the first place, could
conceivably be prevented, if the attacker cooperates well enough.
2. Development happens without regard to the napkin.
3. Flaws are fixed one-by-one as they are reported with little thought
given to whether the reported flaws reveal a systematic problem.
[1]: That caveat is important, please do not reply as if it is not there.
I agree with you. Security takes discipline, regardless of methodology. Interestingly, the only freely-available security-focused method I've seen is Microsoft's SDL (waterfall)[1].
The article does spark some interesting debate though, also about TDD.
[1] http://www.microsoft.com/security/sdl/default.aspx
The article does spark some interesting debate though, also about TDD.
[1] http://www.microsoft.com/security/sdl/default.aspx
[deleted]
There's an article that I am reminded of -- What Killed Waterfall could Kill Agile [1]. Essentially, the developers left once "Agile" started being plagued by elitism.
[1] https://gist.github.com/joshwand/710960
[1] https://gist.github.com/joshwand/710960
People still don't get it. There is a really simple antidote to elitism - democracy. Everybody gets the same amount of power, well defined as one vote. If you want to abstain your power, you can - just don't vote.
That way, people who want to do real work can concentrate on it without worrying about power games. Power games become pointless, because the power structure is set to stone. That's why democracy is so effective system - it lets you focus on the job, without the stresses of not having any power. Because you can have it, when you need it.
That way, people who want to do real work can concentrate on it without worrying about power games. Power games become pointless, because the power structure is set to stone. That's why democracy is so effective system - it lets you focus on the job, without the stresses of not having any power. Because you can have it, when you need it.
Technically agile has never been about actual programming, it is a process to plan and coordinate programming. Aka a process to 'manage' programming. So I'm not sure why one would be surprised that managers have more interest in it than programmers?
Agile got its first burst of popularity with Extreme Programming, which was all about programming (and how programmers work with business people). TDD and continuous integration both came from XP.
It's only in more recent years that the programming focus has been stripped away.
It's only in more recent years that the programming focus has been stripped away.
Who controls the travel budget at most companies? It's not developers.
Some people really don't like this article. It has been flagged off the front page after 3 hours despite having lots of points.
It's interesting to see how negative news about Agile are being censored.
It's interesting to see how negative news about Agile are being censored.
When 'Agile' became more process heavy and process driven than previous models, I sorta gave up on it.
Nice idea, shame about the religion around it.
Nice idea, shame about the religion around it.
> Where did all the developers go?
Into the cloud, perhaps?
Into the cloud, perhaps?
Does it make sense to teach someone DevOps?
[deleted]
All the developers are living in Lao PDR.
True Agile: