Win a copy of Machine Learning with R: Expert techniques for predictive modeling this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

My opinion after one year of scrum experience

 
author & internet detective
Posts: 39540
778
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jan,
Just to be clear, i"m not suggesting you criticize "Scrum" or whatever they are calling it at the retrospective. I was suggesting small improvements to make things better.

Junilu,
Here you go:

image from http://ecx.images-amazon.com/images/I/41DytSgX9EL.jpg
 
Ranch Hand
Posts: 974
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:That's another misconception. Documentation is not taboo. Documentation that people spend a lot of time on that hardly anyone reads is strongly discouraged..



And who decides what is hardly read? There are for example very useful examples and exercises in my project. I have used them, I have read them. But since the scrum zealots here think programmers don't read anyway, they are not maintained anymore from now on. We have a sort of attitude like, reading is for nerds. If you read you are unpractical, uncommunicative, unscrummy. Noise is cool. What documentation was not read by whom? It was read by me! The only documents pile not being read was when I was working in PL1 on a mainframe for a bank a quarter of a century ago. Now that was a real waterfall project. But real waterfall projects, in the sence the scrum zealots describe it, hardly existed anymore before scrum appeared. Scrum did not solve the waterfall documentation overload problem. That waterfall documentation overload has become a sort of 'urban legend' (if that is the right English word to describe it).
 
Jan de Boer
Ranch Hand
Posts: 974
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote: I suggest the book "Software Architecture for Developers" by Simon Brown.



Well, the more I read about scrum, the more I am getting to hate it. Sorry! I read Extreme Programming from Kent Beck, ten horseshoes here. I was so irritated by it, people in the train got scared off me! (I read the book in the train, and at some pages made indecent gestures.) Anyway, if I am going to read a book, I am thinking of this one, that seems to have a less 'religious' approach: Agile! The Good, the Hype and the Ugly. Authors: Meyer, Bertrand. By the way this is another reason for me to dislike scrum. This attitude, if you do not like, it is because you have not understood it.
 
Jan de Boer
Ranch Hand
Posts: 974
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jeanne Boyarsky wrote:Jan,
Just to be clear, i"m not suggesting you criticize "Scrum" or whatever they are calling it at the retrospective. I was suggesting small improvements to make things better.



Yes, I know what the purpose of retrospectives are. In the beginning I have made suggestions. They were supported by a few people. Strangely enough, those same few people left. Forget retrospective!
 
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:and I loathe people and organizations that use a Good Thing as a blunt instrument to hammer down the peons. I've also been known to make sarcastic remarks about anything that simply provides an excuse to bring in overpriced software and/or overpriced consultants.


I totally agree, but I think that a lot of it has to do with consistency. If you're constantly chopping and changing, either in your hiring policies (in-house staff vs. consultants) or in methodologies, an incredible amount of energy is wasted in un-learning, re-learning or adjusting to the new regime.

I liken it a bit to politics. Britain has consistently rejected proportional representation because they hate coalitions, considering them "weak". Consequently, elections are decided by the 10% (or often less) of the population that "change their mind" - as voters are wont to do - resulting in flip-flopping majorities that spend most of their time undoing what the previous lot did. Example: British Steel, which was nationalised and de-nationalised 4 times in less than 40 years.

Conversely, France, notorious before 1962 for changing governments every six months, nevertheless managed remarkable economic growth and infrastructure investment, resulting in a railway system that was the envy of Europe and a nuclear-based energy programme which, whether you agree with it or not, gives France the cheapest energy in Western Europe (half the price of Germany's) and makes it the biggest electricity exporter in the EU.

But it takes twenty or thirty years for those sorts of things to happen; not four.

And it's the same with methodologies: I suspect very strongly that ANY reasonable one will be successful, providing a company is willing to spend the time (ten years at the very least, IMO) and money to develop expertise and familiarity in it. Unfortunately, far too many of them seem more interested in the latest snake-oil acronym.

Winston
 
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:

Junilu Lacar wrote:That's another misconception. Documentation is not taboo. Documentation that people spend a lot of time on that hardly anyone reads is strongly discouraged..



And who decides what is hardly read? There are for example very useful examples and exercises in my project. I have used them, I have read them. But since the scrum zealots here think programmers don't read anyway, they are not maintained anymore from now on. We have a sort of attitude like, reading is for nerds. If you read you are unpractical, uncommunicative, unscrummy. Noise is cool. What documentation was not read by whom? It was read by me! The only documents pile not being read was when I was working in PL1 on a mainframe for a bank a quarter of a century ago. Now that was a real waterfall project. But real waterfall projects, in the sence the scrum zealots describe it, hardly existed anymore before scrum appeared. Scrum did not solve the waterfall documentation overload problem. That waterfall documentation overload has become a sort of 'urban legend' (if that is the right English word to describe it).



Before 2006, which is when I joined my current company, practically ALL the projects that I had been involved in produced reams of detailed documentation that stood in for direct communication between developers, testers, architects, designers, and stakeholders. There was a lot of content that was largely predictive, trying to guess the future. Some of that future came true but a lot of it never did because events unfolded differently or did not happen at all. Requirements changed rapidly, sometimes multiple times in one week and the poor document maintainers had to try to keep up. In the meantime, piles of obsolete documentation, all dutifully stamped with their version numbers filled the corners of rooms, tops of filing cabinets, and any other nook and cranny they could be kept in before eventually getting shredded when the shredding truck paid a visit.

This afternoon, I'm taking my wife to see the doctor about her worsening carpal tunnel pain. My wife works for a large bank, the same one I left 10 years ago, as a "Scrum Business Analyst", a position I suspect arose out of their hybrid Watergile approach. All my wife does all day is type up documents that I know would be 10 times shorter if only the people for whom they are being written would just follow a more agile approach, which is to talk, draw up the tests collaboratively and save the results as an executable Gherkin spec. Instead, she has to type this up in Jira, then pass it on to the folks who should have been involved in writing it in the first place, who then go and copy paste from Jira, edit it once again so that Cucumber can actually run it. They do lots of wasteful things and still call themselves agile. Go figure.

I have also worked for state agencies. The printers at those offices were spitting out trees nonstop. I still have a big pile of obsolete documentation in my basement from my two-year stint there. I had to participate in the killing of all those trees. The state agency was the worst (or best, if you want to look at it that way) at producing useless documentation that became obsolete within a week.

So, when you say the waterfall documentation overload has become an "urban legend" I have to wonder, is it just that bad at the places that I know these things have and continue to happen or is Winston working in a place filled with enlightened waterfallers? I tend to think neither because I know I actually lived through that nightmare which unfortunately was NOT a dream and because all the enlightened waterfallers that I know are now staunch supporters of more agile methods.
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:

Junilu Lacar wrote: I suggest the book "Software Architecture for Developers" by Simon Brown.


By the way this is another reason for me to dislike scrum. This attitude, if you do not like, it is because you have not understood it.


The SA4D book is not about Scrum. It's a common sense approach to architecture (it recommends that project architects should also write code so they can see their ideas materialize as running software) and project supplemental documentation. I dont recall any part of the book even mentioning Scrum.

And your attitude of generalizing your bad experiences with specific poor implementations of a generally good idea is what I dislike. It's like saying all dogs should be put to sleep because you got bit by an ill-tempered dog. That's just not true. I agree, something needs to be done about these bad dogs, but let's not generalize it to entire population of dogs. That kind of thinking does not lead to anything good or worthwhile.

Look, I'm not trying to sell you on any of this. You do what you feel you need to do to get your work done. All I'm saying is that your generalization of specific problems, while they are becoming quite common, is not because of the ideas behind Scrum or Agile, it's with the people who are interpreting these ideas and executing in a less than effective manner. I have seen and experienced the good parts and the bad parts but nothing good comes out of dwelling on the bad, only from learning and building upon the good.
 
Bartender
Posts: 1810
28
jQuery Netbeans IDE Eclipse IDE Firefox Browser MySQL Database Chrome Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
About two weeks ago I was asked to interview at a company that was touting a new SCRUM and Agile environment. After reading this thread, I'm glad I declined the interview (other reasons, not because of Agile).

However, I have learned that I want to work for Cisco and learn TDD from Junilu. Where do I send my resume?
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:

Tim Holloway wrote:and I loathe people and organizations that use a Good Thing as a blunt instrument to hammer down the peons. I've also been known to make sarcastic remarks about anything that simply provides an excuse to bring in overpriced software and/or overpriced consultants.


And it's the same with methodologies: I suspect very strongly that ANY reasonable one will be successful, providing a company is willing to spend the time (ten years at the very least, IMO) and money to develop expertise and familiarity in it. Unfortunately, far too many of them seem more interested in the latest snake-oil acronym.


I don't think any company has that much time. The nature of business and projects is that things are always changing. Yes, any reasonable methodology can be made to work. I think that's pretty much a truism. And just as much a truism, any reasonable methodology needs the right people with the expertise and familiarity in it to make it work. There's a statistic out there that says something like 10% of developers are an order of magnitude more productive than the rest. I suspect the widespeard disatisfaction and disappointment with methodologies, any methodology,is largely due has a strong correlation to this statistic. I would even hazard a guess that the ratio is even smaller than 1:10 based on what I've seen from interviewing dozens of candidates for positions on my teams these past few years.

Let me clarify that some part about what I've seen, before someone misinterprets it for me

Over the past few years of auditioning developer candidates, I have met a lot of people with actual abilities that are subpar to what their resumes would have you believe. That said, I have also talked to some very smart and capable people who had no inkling as to what it's like to work in an Agile environment. I hired some of them anyway because I saw a positive attitude and an openness to the possibilities of doing things better. They have, without exception, thrived in the environment that my former manager (and now my current manager as well) and I created for them, which is an honest, open, pragmatic approach to agility. As I said in earlier posts, the latest batch of hires were actually disappointed that I didn't get to work with them much last year and now when I rejoined their project, the ones I have worked with these past few weeks have improved immensely and just this morning, they thanked me for teaching them new things. I also praised them for their quick turnaround. I'd like to believe that they are now in or at least closer to being in the ranks of the 10% of developers who are an order of magnitude more productive that the rest.
 
J. Kevin Robbins
Bartender
Posts: 1810
28
jQuery Netbeans IDE Eclipse IDE Firefox Browser MySQL Database Chrome Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not an expert on development methodologies, but from the stories I'm hearing, I can't help but wonder if these companies wouldn't be better served by training their developers in good sound practices and test driven development. Drop the buzzwords and the management-speak and just teach people to be really good at the basics and build from there. We've all seen developers who struggle with the most basic issues; understanding MVC, writing small methods, using composition and inheritance, etc. If I were managing a team of developers, I would start there. But that just my two cents worth.
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's exactly where I am right now, trying to train the developers I work with on sound engineering practices. I always say that a poor engineering practice will still produce poorly written software, no matter how much and how good a management practice you try to wrap or force around it. I could get discouraged, and honestly, I do once in a while, but I try not to dwell on it. Just keep moving forward and fight the good fight until you either keel over from the effort, win a few battles, lose a few more, or outright win the war. I see no end to this war so it's back to the jungle and fighting with guerilla tactics for me right now.
 
Jan de Boer
Ranch Hand
Posts: 974
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Jan de Boer wrote: By the way this is another reason for me to dislike scrum. This attitude, if you do not like, it is because you have not understood it.


All I'm saying is that your generalization of specific problems, while they are becoming quite common, is not because of the ideas behind Scrum or Agile.



No offense...but, just as a little joke:

Scrum is like islam! If you do not like it, you have not understood it and you should read the book. If something bad comes out of it, it is not really islam/scrum. And and now: if you attack it too vigourisly, you're a generalzing bigot!
:-)


 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:
Scrum is like islam! If you do not like it, you have not understood it and you should read the book. If something bad comes out of it, it is not really islam/scrum. And and now: if you attack it too vigourisly, you're a generalzing bigot!
:-)


Lucky for you, I can take a joke. Otherwise, you'd be on the same list as Rushdie
 
Jan de Boer
Ranch Hand
Posts: 974
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:
The SA4D book is not about Scrum. It's a common sense approach to architecture (it recommends that project architects should also write code so they can see their ideas materialize as running software) and project supplemental documentation. I dont recall any part of the book even mentioning Scrum.



Well I have read this one: James Coplien Lean Architecture. It talks about the importance of architecture in the scrum process. That improving the architecture is a constant part of the scrum process. That the architecture role should not be a task of a sole person but the responsibility of the whole team. That there should be constant refacturing. Is it something like that?

I know all that stuff! I know what the values of Agile and Extreme programming are. I know the ideas behind it.
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:

Junilu Lacar wrote:
The SA4D book is not about Scrum. It's a common sense approach to architecture (it recommends that project architects should also write code so they can see their ideas materialize as running software) and project supplemental documentation. I dont recall any part of the book even mentioning Scrum.


Well I have read this one: James Coplien Lean Architecture. It talks about the importance of architecture in the scrum process. That improving the architecture is a constant part of the scrum process. That the architecture role should not be a task of a sole person but the responsibility of the whole team. That there should be constant refacturing. Is it something like that?


Yeah, I have that book, too. I actually know Cope personally from being on an expert panel with him at a SPLASH (what used to be OOPSLA) conference and subsequent encounters. He has his own ideas about agility, some of which I agree, some of which I don't particularly agree. He doesn't believe in TDD. I do. I agree with his take on architecture though. That doesn't conflict with the idea that project architects, the guys who do most of the high-level thinking and decision making about architecture, should also code.
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:Well, the more I read about scrum, the more I am getting to hate it. Sorry! I read Extreme Programming from Kent Beck, ten horseshoes here. I was so irritated by it, people in the train got scared off me! (I read the book in the train, and at some pages made indecent gestures.)


I read the Extreme Programming Explained book in early 2000, just a few months after it was published. I had a completely different reaction to it. I credit Beck's book and Martin Fowler's "Refactoring" book for putting me on the path that I took in my search for the same kind of experiences they wrote about in their books. I guess it's telling that my seeing these books as promises of the kind of professional life I could have has led me to where I am today. At the same time, your negative reaction to the same book seems to have brought you to where you are with Agile today. Go figure.
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:I know all that stuff! I know what the values of Agile and Extreme programming are. I know the ideas behind it.


If there's anything that the process of learning TDD taught me, it's that just because you know, that doesn't mean that you can. It took me a few years to find my way around the pitfalls of TDD and agility. I knew what the principles and values were and I was totally on board with them but to use them in practice and really execute on them, that's a whole 'nother story. It takes, patience, perseverance, and the proper perspective on things to find that light at the end of the tunnel. Then it takes a lot of hard work and overcoming of various internal and external challenges to get to that light and into the open where all the possibilities seem to open up. It's not for the faint of heart and certainly a mindset of resistance, anger, and frustration won't help.

If you know anything about Aikido and its principles of non-resistance, non-violence, and peaceful outlook, you'll understand why I often cite my training in that martial art when I talk about being successful with Agile methods. It's all the same mindset.
 
Jan de Boer
Ranch Hand
Posts: 974
11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:some of which I agree, some of which I don't particularly agree.



Cannot I do the same with scrum? It is exactly the 'religious' part that gets on my nerves. Like it is a revelation, and a revolution. The if you do not like it, there is something wrong with you. And in your last posts you are doing that thing. That just raises an aversion.

One last thing to say. Scrum generalizes that people are all the same. I for example like to read documentation as a backup. I do not think personal contact is always the best way to communicate. Especially when it then comes down to numerous interuptions of your work. Please send me an email instead of constantly interupting me, because this is team work. Scrum makes me think of the teacher in Pink Floyds the Wall making humdrum of all the pupils. Do you know that movie? I saw it when I was the school going age. But it more applied to professional life after school then actually school itself.
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:

Junilu Lacar wrote:some of which I agree, some of which I don't particularly agree.



Cannot I do the same with scrum? It is exactly the 'religious' part that gets on my nerves. Like it is a revelation, and a revolution. The if you do not like it, there is something wrong with you. And in your last posts you are doing that thing. That just raises an aversion.

One last thing to say. Scrum generalizes that people are all the same. I for example like to read documentation as a backup. I do not think personal contact is always the best way to communicate. Especially when it then comes down to numerous interuptions of your work. Please send me an email instead of constantly interupting me, because this is team work. Scrum makes me think of the teacher in Pink Floyds the Wall making humdrum of all the pupils. Do you know that movie? I saw it when I was the school going age. But it more applied to professional life after school then actually school itself.



If it came across that I'm saying that something is wrong with you, that's not my intent. All I'm saying is that some of characterizations that you are making regarding Scrum and Agile are incorrect. There's a distinction between your perception / your experience and what it is really meant to be. Take for example this statement that you just made: "Scrum generalizes that people are all the same." Of course it doesn't. Where did you get that idea? One thing that I like about Agile is that people are generally treated as unique people, not plug-and-play resources. If you encounter an Agile implementation where they do talk about "resources" then that's a bastardization of the intent of Agile. If you feel you're being interrupted continuously such that the interruptions become an impediment to your work, there are mechanisms built into Scrum (go to the Scrum Master and work out a schedule where you can have some "alone time" work) that are there to address that kind of problem. If your Scrum Master does not address this impediment to your work, then he has failed one of his responsibilities as a Scrum Master. Is that a fault of Scrum? Certainly not. Did you try to work out a more suitable arrangement that fits your work style with your Scrum Master? Did you try to make compromises with your teammates? Did you air your concerns with them? If you did, what did they do? If they did not do anything to address your concerns, again, that goes against the spirit of teamwork.

On the other hand, you have to accept that there is a need to have more direct communication around the more dynamic aspects of the development effort. Such as detailed requirements. The whole idea of direct communication and collaboration in Agile is to eliminate the need to create and collect a large inventory of documentation to make sure that certain ideas are communicated to the team members. When those ideas are in flux, such as with most detailed requirements which haven't been implemented as working software and had the benefit of being seen by users and getting feedback about it, the agile principles of direct communication kick in. That's the purpose of making user stories small and writing them on index cards. That's why user stories are sometimes called "promises of a future conversation". Rather than spend time writing static documentation, you spend time talking directly to each other about the requirements and ideally, codifying them right there as automated tests. If your team is not doing that, is that Scrum's fault? I don't think so.

So it's not that I'm being religious or dogmatic about these things. I just understand it more than you do and I'm just trying to set you straight on many of your misconceptions which are based on your experience with poor implementations of Agile and Scrum.

And sure, Scrum is not for everybody. I don't think that means something is wrong with you. If it's not a fit, it's not a fit. If a square peg doesn't fit in a round hole, that doesn't mean that there's something wrong with the peg. I get that. But the peg shouldn't go complaining that the round hole sucks just because he doesn't fit in it either.

Anyway, I think I'll leave you to nurse your bottle of frustration and animosity against something that I find particularly enjoyable and gratifying when it's done right. To each his own I guess and whatever makes each of us happy is fine. No hard feelings on my end, I hope you don't bear any for me. I'll put my hammer down now.
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And just to dispel any doubts you may have about what it's like to work on our team that does Scrum and XP, here are some snippets from an IM conversation that I had with one of the developers I've been working with these past two weeks. He pinged me when I got home from my wife's doctor appointment for her carpal tunnel pain.

K: Hi Junilu. We had some fun today

Me: oh yeah, that's good

K: writing tests for the controller

K: hope to keep going. Thanks much!

Me: yeah, I'm glad to see you guys catching on to the idea.

Me: did you guys get I (our product owner) to answer your questions about what to do in those exceptional cases?

K: yes. he said to default to ...

Me: ok

K: that syntactic sugar is additictive.
addictive*

Me: yes, being able to read the code and understand it quickly is very addictive
it spoils you for any other way of writing code

K: yeah

Me: the term for it is "fluent API"

K: oh

K: You are our Code Sensei

Me: ;) -- I'm just a sempai (senior student)

K:
Ok feel free to join my room (referring to his personal WebEx meeting room) when you want to
we are almost done with the controller

Me: ok

===========
Like I said, they are quite happy with the way things are going now, despite me "hammering" on them these last two weeks about clean code, refactoring, driving their design thinking from the tests, all the technical debt that we have amassed in just a few short months, etc. I wouldn't be surprised if they describe their experience on my team as something of a "revelation" of how it is to work on a team that communicates and collaborates with each other effectively.
 
Jan de Boer
Ranch Hand
Posts: 974
11
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry but, if not you, scrum constantly makes me feel there is something wrong with me. That is the whole point. Do not take it personally.

My biggest frustrations:

It says, all programmers hate to read, all programmers hate to write documentation.
And I like to have things written down.
In the Kent book there was interview. If people do not want to pair program, fire them.
And I cannot concentrate with too much noise.
Also it said, good programmers like to be in a noisy room, because then they communicate and make progress.
And again I cannot concentrate with too much noise.
Also it said, if there is no noise in a scrum team, there is something wrong with the team.
And I politely told my team I am sensitive to noise, and subsequently I was ignored.

Scrum/Agile/XP tells me, .... ..., find another job, you are not a real programmer. And it does that because it generalizes a way all programmers work, that is not the way I work best. Hearing the other complaints, well maybe I am part of a minority but also not the only one in this.

By the way, I still technical capable enough to work here, so no need to worry. But I work 'despite' scrum. I accept it as an unchangeble fact here, but will never love it. I will leave it that way, and study it enough to make my boss happy.


 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:Sorry but, if not you, scrum constantly makes me feel there is something wrong with me. That is the whole point.


I totally understand how you feel. However, consider what Aikido's founder has to say:

O'Sensei Morihei Ueshiba wrote:Opponents confront us continually, but actually there is no opponent there. Enter deeply into an attack and neutralize it as you draw that misdirected force into your own sphere.


In your context, it means that the only thing that's making you feel that something is wrong with you, is you. To enter deeply into that attack from yourself, you need to do a lot of introspection and try to neutralize the negative thoughts. I know this probably sounds like a lot of martial arts BS to you but that's exactly what I did when I found myself conflicted.

It says, all programmers hate to read, all programmers hate to write documentation.
And I like to have things written down.


Tell me where Scrum/Agile says that. It doesn't. Again, that's just your take on it, not the reality of Scrum/Agile. The reality is that most programmers would rather code than write documentation. Most programmers would rather experiment than read lengthy documentation. And most programmers, myself included, don't trust internally produced documentation because in many instances, it's outdated or incorrect. We also don't like to spend precious time writing things down that are just going to become obsolete anyway once we learn more about our system. We just don't have enough time to keep going back to update a bunch of static and obsolete documentation.

If you like things to be written down, have you discussed this with your team? Have you made a case for the benefits of having things that you like written down actually being written down, that the cost of writing that stuff down will eventually pay off?

What Agile advocates is that a working product is valued more than comprehensive documentation. There's a lot of nuance to that pithy statement and that's the pitfall. Don't interpret that to mean that you should not write documentation. That couldn't be further from the truth.

Make a case for the kind of documentation that you find useful. More importantly, demonstrate how it unequivocally benefits you more than it costs the team to write that documentation. Have you done that? Have you tried to?

It's often said that Agile does not attempt to solve problems as much as it reveals problems. If you introspect and look past all your biases, maybe you'll see that there are some real challenges that you need to deal with, both internal and external.

BTW, it is often also said that most programmers don't like to write tests. Did you see what the developer said to me yesterday? "We had fun writing tests." He has overcome his fear and loathing of tests and figured out that they were actually very useful things to write, and downright enjoyable things to write when you do it right. It is no longer a tedious chore to write tests, it's actually something that allows him to get better at doing the thing that he loves to do: write code.
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:
In the Kent book there was interview. If people do not want to pair program, fire them.


Admittedly, that's a pretty extreme stance to take. But then again, Kent Beck pretty much wrote the book on Extreme, right?

There are a few ways to address the issue of a team member who does not want to pair up or group up when developing:
1. Make pairing/mob programming so attractive a proposition that the recalcitrant team member puts aside their personal bias and tries it until they like it.
2. Or until he really can't take it and quits on his own
3. Or make him an exception and just ask him to help when he has expertise that nobody else has

There may be other options but I'll stick with these three for now. The first option is generally my approach and I've been pretty successful with it. You need to spend a lot of time mentoring people though, and you have to have the people with the right mindset and openness to new ways of working.

I avoid #2 by not hiring people on whom I don't feel #1 strategy will work.

If I really have to -- and I've never really had to do this -- I'll probably resort to #3 but only after setting the tone, making it clear to the person what's happening and offering him a way out, like a rotation with another team or something. If he's a contractor, it's even easier. I just don't renew the contract. That's the Kent Beck approach, which I guess is the absolute last resort for me. But if it comes to that, it means I have failed in 1) the hiring process or 2) in the #1 strategy above and I'm really just cutting my losses at that point.
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:
Also it said, good programmers like to be in a noisy room, because then they communicate and make progress.
And again I cannot concentrate with too much noise.


This, again, is a mischaracterization.

One of the most successful Agile teams I know of at my company has described the "noise" that you refer to as a "hum". If you go into their common development area where developers and testers are working together, you can hear sort of a hum of quiet conversations going on with the different pairs. I love how their manager described it: "The Hum of Scrum" like a well-oiled machine just moving along and churning out usable software.

I have never worked in a war room myself. Like I said, we work virtually over WebEx. I'm in one right now, just listening to these two developers go back and forth on the design and refactoring that they're doing right now. They've been at it all morning and the talking is non-stop, but it's all useful talk and they bounce ideas off each other and ask me to interject when they get stuck. They're having fun, what more can I say? ¯\_(ツ)_/¯

Here's a more reasonable version of what you said: When programmers communicate well, they can make good progress. Programmers like it when they make good progress.

A noisy room that makes it difficult for programmers to concentrate and do their work is an impediment and that needs to be addressed. Your own limitations and low tolerance to noise should be address by your team and if they just ignore you, that's on your team, not on Scrum/Agile.
 
Junilu Lacar
Marshal
Posts: 14070
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jan de Boer wrote:
Also it said, if there is no noise in a scrum team, there is something wrong with the team.


(Tongue firmly planted in cheek) Well, if they're still producing software, I'd say that team has evolved and developed psychic communication abilities!

I too would be concerned if I didn't hear anything coming from a room full of developers supposedly pairing and doing Agile development. I'd check their eyelids to make sure that they didn't just paint eyes on them and everybody is actually sleeping on the job!

Like I said earlier, there really is a lot of verbal and visual communication within a team that is communicating frequently while they develop software collaboratively. I have a small whiteboard handy so that when we get stuck during one of our WebEx sessions, I can pull up the whiteboard, share my video, and draw things out. If everybody is just sitting there quietly and not having some kind of discussion, something's going on and it's probably not good.



That said, you have to make a distinction between pure noise that isn't productive and that "hum" which is. Noise, bad. Hum, good. Silence, something's up and it's probably not good -- get ready to be punked if people look too serious or like they're holding back laughter.
 
Winston Gutkowski
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:So, when you say the waterfall documentation overload has become an "urban legend" I have to wonder, is it just that bad at the places that I know these things have and continue to happen or is Winston working in a place filled with enlightened waterfallers?


I don't know where you got that idea , especially from my previous posts.

That said, I HAVE worked in places that made waterfall change-control work pretty well. Why? Because they had years of experience using it.

Anyone here remember TQ? I worked in a few shops that used it, with differing degrees of success, generally based on commitment. There were two main guys involved with its invention - one of whose surnames begins with a 'Z' or 'X', but I can't for the life of me remember it - and it was based on statistical systems of theirs adopted during WW2 that produced fantastic results for US war production.
But what happened? At the end of the war everybody found it too exacting and went back to the "old way" of doing things; and those two bods ended up going to Japan to help kick-start their economic and industrial miracle.

I can't say I ever became an expert in it, but it did teach me one thing that I've never forgotten as a programmer: Quality insurance is not the same as quality assurance; and you do far better by discovering causes than treating symptoms.

And I suspect that there is a truism that can be applied to ALL methodologies, especially ones:
(a) that have books written about them.
(b) that you pay consultants for.
and that is that they're good at some things, less good at others. The problem is that you tend to find the latter out for yourself, because the authors - or the people you're paying to rah-rah the troops - certainly aren't going to tell you.

And I'm with Jan on most of his objections, but I don't particularly target Scrum or Agile in my dislike of "silver bullet" methodologies; they just happen to be what we're talking about:
  • They promote cliques and acronyms.
  • They don't tell you what they're bad at.
  • They're used as hiring filters (another form of "club membership").
  • They (generally) don't play well with other "clubs".

  • And finally, I'd like to address the business of "noise": I'm a firm believer that programming is basically a solitary pastime, with the odd occasions - which, I'm happy to concede, probably need to be imposed from above - when you need to communicate with other people.
    But the primary business of programming, be it coding or just thinking, is done alone; and the times that we get the most done are usually when we have 24 or 48 uninterrupted hours of working by ourselves.

    My 2¢.

    Bring it on Junilu.

    Winston
     
    Junilu Lacar
    Marshal
    Posts: 14070
    234
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:
    That said, I HAVE worked in places that made waterfall change-control work pretty well. Why? Because they had years of experience using it.

    Bring it on Junilu.

    Sorry to disappoint you but I'm totally with you on this one, W, my friend. Besides, it's Friday and I like to end my week on an upbeat note

    ... although ...


  • They don't tell you what they're bad at


  • I agree, they generally don't tell you what they're bad at but a good Agile coach will tell you that more than anything else, Agile reveals to you what you're bad at.

    Cheers!
     
    Junilu Lacar
    Marshal
    Posts: 14070
    234
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Now you've made me wax philosophical again, on a Friday.

    There have been many times in my journey to agility when I have said to myself and my teammates, "You/we suck at this!"

    Our very own Kathy Sierra wrote about the Suck Threshold and the Kick Ass Curve and that's what I always refer to at times like this. All it takes is an awareness that you suck, a determination to get better, and the perseverance and dedication to work harder at getting better and powering through that "suck zone". To me, that makes all the difference in the world whether you end up a happy camper or someone morosely looking in from the outside.

    And now that I think about it, that's probably how I'm able to let words like "religious", "zealot", "dogmatic", and even "Agile bigot" kind of just roll off my back. Those are all words people use when they don't understand where the passion and excitement of being on the kick-ass side of the curve comes from. ¯\_(ツ)_/¯

    Huh. Another "revelation", I think.
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:I agree, they generally don't tell you what they're bad at but a good Agile coach will tell you that more than anything else, Agile reveals to you what you're bad at.


    Oooh. Wonderful bit of sales spin ... and also a great way of passing the buck.

    So: if you use Agile, and your project collapses in a steaming heap, it's your fault; not Agile's.

    Well, hey, I've got to get me some of this. And what's more, when I've got it, I can never, ever, ever, let anyone do anything a different way.

    Oh, and if I have people that don't work well with Agile, then it's their fault, so I don't have to feel bad about firing them....

    Happy Friday.

    Winston
     
    Junilu Lacar
    Marshal
    Posts: 14070
    234
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:
    Oh, and if I have people that don't work well with Agile, then it's their fault, so I don't have to feel bad about firing them....


    How is that any different from anywhere else you go?

    If you join the Military, there is a certain way you do things. If you break the rules, you're out.

    If you're playing a game, and you flout the rules of the game, you're going to get ejected.

    If you live in a society and you don't abide by the mores and social conventions, you can get in trouble. Sometimes, depending on the society, you can get into serious trouble.

    If you want to be part of an Agile team, then it's natural to have to abide by the rules and conventions of Agile. How is that unreasonable?

    Reminds me of a pledge that I learned when I joined my fraternity, Alpha Phi Omega:

    If you work for a man in heaven's name,
    work for him, speak well of him,
    and stand by the institution which he represents.
    ...

    If you must growl, condemn, and eternally find fault,
    Why, resign your position!

    And when you're on the outside,
    Damn to your heart's content.
    But as long as you are part of the institution,
    Do not condemn it.

    For if you do,
    The first high wind that comes along
    Will blow you away
    And probably you'll never know why.

     
    Junilu Lacar
    Marshal
    Posts: 14070
    234
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:
    Oh, and if I have people that don't work well with Agile, then it's their fault, so I don't have to feel bad about firing them....


    And please read what I wrote about that earlier. That's a mischaracterization of the attitude good Agile teams would take. Firing is an absolute last resort, after all other efforts to reach an agreement or compromise fails.
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:All it takes is an awareness that you suck, a determination to get better, and the perseverance and dedication to work harder at getting better and powering through that "suck zone". To me, that makes all the difference in the world whether you end up a happy camper or someone morosely looking in from the outside.


    Too simplistic.

    The Dunning-Kruger effect refuses to allow me to rest on my laurels, nor indeed concede that I might be an expert an anything; despite the fact that I have 30 years of professional experience - probably twice as much as most of the high-price bods that companies I've worked for pay to tell me what I'm doing wrong.

    Why? I'd say, it's because they have two or three years of experience in some focused methodology that fills a lot of gaps for them; and are therefore willing to be evangelists (and that's my best interpretation) on the subject.
    You'll have to forgive me if I take most of it with a pinch of salt.

    The test of how good Agile or Scrum (or any other methodology) is, is going to be in how long your company uses it. And if it passes the 5 year test, then it may be worth committing to memory; otherwise: keep the good bits and forget the rest.

    There are only two generalisms I can attest to in my career about good programmers:
    1. They're intelligent.
    2. They like beer.
    and I'd like to think that I qualify on both counts.

    Winston
     
    Junilu Lacar
    Marshal
    Posts: 14070
    234
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:
    So: if you use Agile, and your project collapses in a steaming heap, it's your fault; not Agile's.


    For the most part, yes. And I would say the same thing applies with any other reasonable methodology, even traditional waterfall, to whatever extent that it's reasonable.

    If people did things that were not in the spirit of the reasonable methodology, doesn't it stand to reason that it's their fault if things go wrong and not so much the methodology's?

    If your car had seatbelts that could provide reasonable protection under certain circumstances and you didn't wear your seatbelt and got into an accident, is it the seatbelt's fault that you to injured? What if you drove your car outside the parameters under which the seatbelt was built to protect? It's not the seatbelt's fault that you'd get injured in those circumstances, right?

    If a curve on the road was rated at 35mph, would it not stand to reason that you are at fault if you skidded off the road because you took the curve at 60mph? Is it the curve's fault that your a** is in a sling? Is it the person who rated the curve at 35mph who's at fault for your injury? It's you, right?

    Need I go on?
     
    Junilu Lacar
    Marshal
    Posts: 14070
    234
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:
    The test of how good Agile or Scrum (or any other methodology) is, is going to be in how long your company uses it. And if it passes the 5 year test, then it may be worth committing to memory; otherwise: keep the good bits and forget the rest.

    There are only two generalisms I can attest to in my career about good programmers:
    1. They're intelligent.
    2. They like beer.
    and I'd like to think that I qualify on both counts.


    Our team has been doing it since I joined in 2006 -- check.

    1. I like to think I'm not stupid
    2. I had my first mug of it when I was 13. And then I had a couple more. That may contradict #1 but hey, all 13-year olds are allowed to get their stupid stuff out of the way. I like to think I've done that I grew up on San Miguel Pale Pilsen but with my gout, my doctor won't let me drink beer any more. And then there's my kidney stone thing. Doesn't mean I don't like beer anymore though.

    Do I still pass your tests?
     
    Junilu Lacar
    Marshal
    Posts: 14070
    234
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:
    The Dunning-Kruger effect refuses to allow me to rest on my laurels, nor indeed concede that I might be an expert an anything; despite the fact that I have 30 years of professional experience - probably twice as much as most of the high-price bods that companies I've worked for pay to tell me what I'm doing wrong.


    That's where the disconnect is. Square peg meets round hole doesn't mean there's something wrong with the peg, nor that there's something wrong with the hole. That the FIT is not there, is what's wrong. But the peg shouldn't go around that the hole sucks, right?

    BTW, those high-priced bods that tell you that you're wrong are morons, don't listen to them. I've met them or if not the ones you met, their close relatives.
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:If you join the Military, there is a certain way you do things. If you break the rules, you're out.


    And did I sign up for the military when I got through programming school?

    If you're playing a game, and you flout the rules of the game, you're going to get ejected.
    If you live in a society and you don't abide by the mores and social conventions, you can get in trouble. Sometimes, depending on the society, you can get into serious trouble.
    If you want to be part of an Agile team, then it's natural to have to abide by the rules and conventions of Agile. How is that unreasonable?


    Because I didn't ask to "be part of an Agile team". Somebody - and probably someone with very little experience of programming (if any) - imposed that on me.

    Did we all start out our lives as "Scrum team participants"? Did programming stop, or was it much worse, simply because nobody knew about Scrum or Agile? Are companies that DON'T use Agile prominent by their demise on any of the major Stock Exchanges?

    NO.

    It's one way to attack a problem, and it may well have many good points in its favour; but you're not going to convince a hoary old sceptic like me that it's a "philosophy", nor that I need to buy in to any "social" BS that surrounds it, in order to be a better programmer than I was already.

    Winston
     
    Junilu Lacar
    Marshal
    Posts: 14070
    234
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    There's a common thing that the best senseis I've met in Aikido dojos do when they instruct and guide students. They always say "Good, good! But here's how you can do this better." It's not that they're trying to be condescending either. They're right. Whatever seems to work for the student is really fine. But if the student wants to learn at improve their Aikido, they also need to open their mind and observe what sensei shows them.

    Not that I've ever made claims to being a sensei; see my IM conversation with the happy camper TDDer from the other day.
     
    Junilu Lacar
    Marshal
    Posts: 14070
    234
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:

    Junilu Lacar wrote:If you want to be part of an Agile team, then it's natural to have to abide by the rules and conventions of Agile. How is that unreasonable?


    Because I didn't ask to "be part of an Agile team". Somebody - and probably someone with very little experience of programming (if any) - imposed that on me.


    So it's Agile's fault that it was imposed on you by somebody? That doesn't sound reasonable. Why don't you air your concerns with the person who imposed it on you instead of blaming your woes and frustration on Agile/Scrum?

    That anti-pattern of imposing Agile on teams who are just not ready for it has long been identified. We have made the same mistake in our group. That's why most teams outside my team are struggling. Not to brag, but we've been called "The Gem in Ohio" precisely because we are more successful at doing Agile than anybody else in our group. And it's precisely because we buy into what you so glibly call "the social BS" that surrounds it. It may seem like that to you but we're happy to wallow in it and kick ass by doing so.

    (Ok, so I did humbrag there a bit, but it's true, they think we're a "gem" - the director's exact word and they want us to help other teams get there. I'm leery of that responsibility though since I know I'll get treated like those morons that you ran into - I don't have the time or the hair for that kind of aggravation any more)
     
    Junilu Lacar
    Marshal
    Posts: 14070
    234
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    How the heck did I let myself get dragged into this conversation on a Friday?
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:There's a common thing that the best senseis I've met in Aikido dojos do when they instruct and guide students. They always say "Good, good! But here's how you can do this better." It's not that they're trying to be condescending either. They're right. Whatever seems to work for the student is really fine. But if the student wants to learn at improve their Aikido, they also need to open their mind and observe what sensei shows them.


    And I doubt that your sensei would dispute this: You learn what is good by learning what is bad. I actually rather like the Chinese idea of "yin" and "yang" all being part of a universal truth combined in a single symbol (of course this could just be my Western misinterpretation of it).

    In a martial art, you need to be taught what is good, because the penalties for learning what is bad are severe; but in programming there is no such restriction. You can fail as many times as you like, and computers don't judge - and it's the business of failing (assuming we learn from it, and are happy to continue) that makes us better.

    However, that does NOT apply to systems or methodologies; only to people.

    Winston
     
    Where all the women are strong, all the men are good looking and all the tiny ads are above average:
    Java file APIs (DOC, XLS, PDF, and many more)
    https://products.aspose.com/total/java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!