As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
G'day,
I'm always trying to improve my performance as a developer and, after listening to this interesting podcast on the topic, I was wondering if people think it is worthwhile asking for feedback from colleagues.
I am thinking of obtaining feedback anonymously in the manner suggested in the podcast by using the Rypple site. And by asking one single, short question that directly addresses a specific aspect of my work or behaviour. For example, I'm looking at questions such as:
What can I do to improve the way in which the development team and the operational work together?,
How can I help you be more effective in your job interfacing with our major client?,
What parts of my technique could I improve based on the presentation I gave today?
etc.
Edit: I am not talking about general aspects, but specifically about how my performance as a developer can be improved. Communication and working with others is a large part of working with others in a company.
Edit: These additional questions are in response to a comment to my original question by JB King.
Further examples of possible questions that could provide useful feedback to help you improve as a developer are:
Am I becoming too focused or obsessive in my solution toolset?
What technology do you think I should learn to expand the team's capabilities?
What technology do you think I should focus on to improve the team's overall capabilities?
All of these directly address my personal progress as a developer.
cheers,
If you want to get honest feedback about what you are doing, you may want to find someone that observes what you do, and just ask their opinion, perhaps while having a beer. :)
But, it is important that you don't get defensive in any way, as you are asking for honesty.
And, you should consider making changes based on what they say, as that will help others to see that you are not only open to criticism, but willing to adapt, to become a better developer.
But, ultimately, you need to get an idea what type of programmer you want to be. Then it is useful if you have someone that you work with that exemplifies those qualities, then you can develop a relationship to see if they can help you become a better programmer.
For example, I knew an architect who would always pull a chair over and sit down when answering a question, so he was always on the level of the developer. That little action was so impressive to me, as it was a simple action, but it showed a willingness to bring himself to the level of others. That is how I want to be seen as I mentor others.
I think asking for anonymous feedback is bad, in part because it shows that there is a communication problem on the team, where people are not willing to be open with their feelings and opinions. The team lead should deal with that, as it could eventually be damaging to the team, if people keep their true opinions bottled up rather than expressing them, in order to help the team to be better.
I'd actually recommend not being anonymous when asking for criticism. One of your stated goals is to improve communication with colleagues; I think you might improve this better by actually talking with them instead of using a tool.
Being able to take criticism in person will show people you are confident and serious about improving. Face time is unfortunately underrated in our industry.
Yes, asking for feedback from colleagues is worthwhile. Often you don't know what you are doing great and where you could improve without getting at least a second opinion, if not a third, fourth, and so on.
Anonymity gives the benefit that those answering don't have to fear retaliation. Sometimes this works well and the result is honest feedback and sometimes people may enter stupid things trying to be funny. Que sera, sera.
I am not sure much good will come of it. I kinda agree with James on this one.
What might be better is to have some development workshops in your team. You could do it in such a way that each week 1 developer has the floor for an hour. Find a meeting room and a projector (if you have one) and let this developer present his / her discovery to the rest of the team.
At any point in time there are huge changes happening in the industry, so there should be a lot of areas to cover, for example - one week a certain developer could talk on up and coming changes in .net framework v4 (just an example), while another week yet another developer can talk about the benefits of shorter scrum iterations (again just an example).
The idea is the developer shouldn't be forced into presenting, and he/she should decide his or her own topic of interest.
This exercise might help strengthen communication in your team, and in this way the whole team is geared towards improving development skills.
This is the good idea, bad idea which I've seen is to take this idea too far, and expect developers to go away for weekends to so called coding dojos - yeah how fun (not).
Make sure these presentations are happening during normal paid business hours, or you'll have a riot.
"How can we do our jobs more effectively?" is a great question, and well worth asking!
But you should always discuss it openly. It's about as innocent a question as one can ask in the professional world, so if you tell people to discuss it anonymously, they'll think something funny is going on, even if that's not the case. And if you can't discuss such an innocent topic openly, your organization has serious problems.
Also, if you're going to ask questions like that, you need to pay attention to the answers, and either act on them or explain why you won't. People can handle, "Good point, but we're not going to do it that way, here's why." But it's pretty demoralizing to answer a question like that - especially if you made a lot of effort - and then feel like you've been ignored.
A good question that I've found to ask is: "Would you recommend this app to someone else?" and start the conversation there.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
As a ASP.NET developer with 5+ year experience. I like to measure my competency level in ASP.NET & SQL Server. Basically my goal is to raise my competency level and skill-set in ASP.NET; before that I need to know what is my level considering current ASP.NET and related technologies...
So, please provide some pointers...
Is there are any skill-set measuring Quiz or exam, which account experience and technology ?
How do you measure your or your junior developers skills or competency?
I guess I could rattle off some exams, like the MCP exams, or BrainBench, but you have to pay lots of money for those.
If you were really sold on taking an exam to gauge your competency, you could get a one of the MCP exam prep guides for ASP.NET, C#, and SQL Server and see how well you comprehend and take in that material. I'm not sure that it's the most accurate way of measuring competency though.
You can get a good qualitative evaluation of your SQL Server skills by simply reading Itzik's or Kalen's books and seeing how you comprehend them. For .NET, read Richter and critically evaluate yourself against the concepts you find in that book. Do those concepts make sense?
Probably the most valuable way to get feedback is to ask your senior developers for a frank evaluation of your skills.
If you're asking how I evaluate my junior developers, it's pretty easy once I see their code and they get a track record for a few months, but I don't believe quantitative analysis is the best way. Instead, I ask questions like:
Can they deliver?
Are they writing good code?
Are they taking the initiative to learn more?
What have they brought to the table?
Do they understand the software development lifecycle?
Do they break builds?
Are they good team players, or do they code in solitude?
Do they make suggestions?
Are they open to others' suggestions?
Do their design decisions make sense for the projects they've been on?
Ask yourself how your leaders would answer these questions about you. If you are seriously confident that they will respond positively, you will have an easier time "grading yourself".
Honestly, it's all relative. I've worked on teams where the junior devs from one team out-class the senior devs from the other team in every way. Different environments are going to value different skill sets in different ways.
As for a "test" of your skills, a pretty handy one would just be right here on StackOverflow. Look for .NET questions, try to answer them. The ones you can't answer, learn from those who do answer them. Rinse, repeat. It's not very structured, but it can definitely be helpful.
It's also good just to follow some of the major blogs and see if you can keep up with what they're talking about and try to implement some of it on personal side projects just to learn and practice.
The only way to really measure your skill level is to push it forward. Find stuff you don't fully grok and learn it. A truly skilled developer is never an expert, but rather just more of an expert than he was yesterday.
When asked on similar lines , I read it from somebody here on SO that
he will try to answer the questions on SO.
Let me rephrase it,
I will try to measure my performance with somebody's questions and answers.
Having said that i won't compare my competence with collective knowledge here on SO.
This is usually pretty specific to the company. There will be a bunch of criteria that the developer must meet before they get a promotion or advance to a higher level.
The hierarchy is usually pretty similar; with general (cumulative) criteria for progress to the next level. In my experience it is something like the following:
1 Graduate/recent work experience
Fair understanding of basic language concepts (agnostic).
Good all-round technical knowledge. Demonstrable
Problem solving skills. Numeric and verbal skills. Generally competent
Shows passion for a certain part of the domain.
Not a crazy person.
2 Junior/Trainee Developer
Good understanding of the primary language they use.
Makes use of de facto tools and technologies to deliver software.
Has delivered software on time and schedule.
Trusted to deliver components with guidance from more senior developers.
Can (and does) participate in design meetings and code reviews.
Has a good understanding of how the company works as a whole.
Understands unit testing and test driven development.
Fair understanding of source control and continuous integration.
3 Developer
Advanced understanding of the primary language.
Demonstrates skill in at least one other language.
Demonstrates the passion to learn more about their language.
Makes good use of design patterns when developing software to write maintainable code.
Actively seeks to improve process and efficiency.
Delivers components to a high level of quality.
Has the ability to lead a small team of developers to produce components.
Good understanding of test driven development, unit testing, mocking and stubs.
Good source control management knowledge: branching, merging, tags.
Can lead a code review with a junior developer and supervise their work.
Requires minimal guidance from more senior developers.
History of delivering quality software, on time
4 Senior Developer
Excellent understanding of their primary language
Good skills in other useful languages in the domain. In general, has a passion for learning about other languages and how the company could benefit from employing it/these to aid development
Great understanding of the domain, all of the components within it and all interactions between. This knowledge can easily be transferred to less senior developers.
Can design beautiful software
Actively seeks to improve development process and efficiency. Demonstrates languages and technologies in this area.
Fully understands the development process from start to finish.
Can lead a large team of developers to successful and timely project completion.
History of delivering excellent software and designs.
5 Lead Developer
King
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What's your opinion of the following job interview question?
In the requirement it never mentions about to have classic ASP experience.
But the question is "What are the differences between ADO.NET DataSet and ADO Record Set?".
I'm not an asp programmer, but since you've asked for opinions, here's one from Joel
Just for fun, here is the worst interview question on Earth: "What's the difference between varchar and varchar2 in Oracle 8i?" This is a terrible question. There is no possible, imaginable correlation between people that know that particular piece of useless trivia and people that Fog Creek wants to hire. Who cares what the difference is? You can find out online in about 15 seconds!
This is my favourite answer to these questions:
I'm sorry I don't know that; but
give me 5mins and Google I'll find
out for you.
I'd say it's a fine interview question.
Active Server Pages (ASP) != ActiveX Data Objects (ADO)
Some people ask what they know - and if you know it too maybe they like you :)
Well, they can even ask you whatever they want. About Perl, Python and Ruby, it is an Interview, they might be measuring your knowledge in other languages (if you heard about them, or if you know why .NET is better/worst).
The important thing in an interview is that you answer the questions to the best of your abilities, so what's my opinion, if you don't know then just say you don't know about ADO Record Set, but you list the benefits/features of a .NET DataSet
The best thing I've found in an interview if you don't know the answer to something is not sit quietly and then try and blag it. Be up front, say you don't know, but if you'd hazzard a guess then it would be insert educated guess here. The interviewer will appriciate the honesty, not everyone knows everything. People want to see confidence but also humility :-)
I'd say it's fairly pointless these days. Anyone who doesn't know probably just hasn't worked with old applications. All the ADO functionality has been out of date for about a decade now and there are some fine devs with years of experience that will just never have seen ADO.
I've hired a lot, and the difference between the really excellent candidates and the average ones is not what obscure things they know now, but what they can go pick up quickly when they need to.
In short a really good developer might answer this with: "I've never worked with ADO, but I could go find out", which isn't that useful for you as interviewer.
A more useful question would be
In what circumstances is it better to use a DataSet rather than iterate the rows of a table?
That way you get the important stuff - actual usage and technology application. They could answer in the context of Linq or a SqlDataReader or any other tech that they've worked with. What you get is what they understand and know how to use, not what they could Google in a few seconds anyway.
Probably they have some legacy code using the pre .NET version of ADO, and are testing to see if you have some knowledge of it.
I think knowing about the differences between ADO and ADO.Net is probably very useful in some positions.
If you've never done any classic ADO then you should probably just say so at the interview and move on to the next question.
Awful question if their goal is to test your capability as an engineer.
Reasonable question if your resume claimed you are both an ASP and ASP.NET guru, and they just want to see if you're telling the truth.
Of course if you work for a big corporate firm, they are more likely to just build their own DAL from scratch and use stored procedures instead of..........well, this.
I've asked a similar question at an interview although it was probably a bit more high level. I asked the candidate what he liked better about Java and what he liked better about C++. This was not some sort of "standard question" The candidate in question, in his resume and the interview up to then stated experience with both. I asked the question for two reasons. To check that the candidate actually has the knowledge he states (which could be a valid reason for the question on the ADO data/record sets). The second reason is to have the candidate show a degree of reflection and ownership of his tools.
In short, the appropriateness of the question is dependent on the profile of the candidate. If the candidate stated knowledge of both, let the candidate show his understanding. If this knowledge is critical to the job, same.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I've been in the business of developing hardware and software for 19 years now. In the earlier days the projects and teams I worked on were smaller, much more effective and more fun.
The effect of the input of one single developer to the final product and to its success was evident to everybody. We had direct contact to and feedback from the customers. This was rewarding for our work and a very effective way to improve the product.
With the years the complexity of hard and software increases and more and more people were needed to get things done on time. The downside of the trend to bigger teams for me is that the contribution of a single developer to the project success gets smaller and smaller. And we lose the contact to real world of the users and customers because of growing QA departments more and more.
I always enjoyed my work and kept in touch with latest technologies like OOP, UML, .NET, and whatever. I already worked a few years as a team leader but I didn't like it very much because I missed developing and coding.
I'm just frustrated about the fact that my piece of the whole "thing" we're working on gets smaller and smaller and I lose the overview about it and the contact to the ground. Please don't understand me wrong, I don't want to cry for the good old days but for me the work on more and more specialized sub modules of a giant system simply gets more and more boring.
I'm wondering if I'm alone feeling like that and maybe if you have some advice how to bring the fun back to my work. And sorry, no, I'm not interested in working on an open source project in my free time. Nine hours a day in front of a computer screen are enough, life is more than coding...
I also require interaction with and feedback from the customer. However, a customer can be many things. As long as I'm satisfying someone (end user, team leader, big boss, etc.) then that's enough for me. The interaction itself is the key factor.
As for the feeling of pride and ownership from having a large impact on the system, again it's a matter of focus. You are still creating something, even if it's a smaller piece of the whole.
I long ago realized that I'm a small fish in a big pond. Learning to feel happy about my place in that pond was the only solution.
IOW, it's all relative!
I guess it all depends, there is a degree of camaraderie that comes with smaller teams and a lesser chance of ego's colliding. I have experienced both and they both have their upsides and downsides. To be honest, while working on a larger team I learned so much from other programmers, you think you know a lot, but someone always knows more.
It all depends on the team and the egos of the individuals.
When working on a team with ego problems, it doesn't matter how cool the technology is or how much interaction you get with the customers. One bad apple can drain all of the fun out of working on an otherwise cool project.
On the other hand, if the team has gelled, it matters very little if the technology is out-of-date, or the business problem is boring. Working on an back-office accounting system using VI and 10-year-old beta C++ compilers can still be invigorating when you feel like your peers are in the same fight and have your back. When you learn from others and are listened to when you have some new approach to try. When the developers control the build/test/deploy process so that it's sane and improves the lives (and sleep patterns) of the support team. When your peers (and you them) are always willing to help with an obscure language issue or work through a maddening bug. That what makes programming fun and interesting regardless of everything else.
You may want to consider changing companies back to a smaller company where you had a broader set of responsiblities, for one idea. Also, what are changes in the process that would help with the points you don't like?
I do have the question of what you mean by large here? Would a team of 50 people in a project be large? Or is it more like 1,000 to be large? On one level I'm asking for scale as there are teams beyond large if one wants to look at all the developers that work on Microsoft's big products like Office and Windows while at the other end of the spectrum are the one person development teams that do it all.
I'd second Kelly's answer that it depends on the team and egos for another big factor in things. What do you consider fun? Is it finding more efficient ways to solve problems that have poor solutions? Is it conquering a Millenium puzzle? Or is seeing someone smile while using your software what makes it fun? Lots of different possible answers and while I can make suggestions, how good or bad they are is totally for you to interpret.
I don't think you're alone in disliking how as a company matures the process can change as new people in various roles are added with increased bureaucracy and losing agility as it may take more signatures to get a change to be allowed or developers lose that touch to the customer of their product. There is a spectrum of various ways to produce software and some places may have less process in place and be focusing on "just make it work" while other places may want the process to be much more formal and organized with 1,001 policies for every little thing. At which end do you want to be working?
To answer the question as it's asked in the title: No!
I feel very similar and talked to many others who think the same. From my experience small teams are much more fun to work with and by that (and some other reasons) they're much more effective.
Thank you all for your interesting and valuable answers (and for correcting grammar and spelling :-)
You gave me some big points to think about:
The missing interaction with custumers (whatever "customer" means)
The interaction and feedback inside the developer team
What means fun for me. I think its more the smile in the face of the user than the use of cutting-edge technology.
How to deal with the sometimes overwhelming processes.
Last but not least to find my comfortable place in the big pond. It may be not the one where I'm staying at the moment...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
After investigating a little bit scrum and kanban, I finally read this answer and decided to start using kanban, picking something from scrum (note that I'm working mostly by myself, and I do have read this question and its answers).
Now, my question is: which tool would be best to get started?
whiteboard and postit
agilezen.com
JIRA with greenhopper
a spreadsheet (possibly on Google Docs)
brightgreenprojects.com
Agilo
Target Process
something else (please specify)
Notes about each:
I would lean towards the whiteboard, but there are several drawbacks (e.g. cannot make automatic charts, time measurements, metrics, and sometimes I work from home - where I need it most - and it's not convenient to carry :-)
I don't want to remember another username/password (I promised to myself to signup only to OpenID-enabled services)
My employer has JIRA but my group doesn't use it - I might ask for an account (it shouldn't require another password) and maybe later involve the rest of the group. But I don't know if they are using greenhopper and if it's a big deal installing it.
I generally hate spreadsheets
maybe overkill?
I'd be happy to have a localhost instance, but it could be problematic to give access to the whole group (per network/firewalls) - not a deal-breaker but surely a concern
What I'd like to get from this?
being more productive
tracking how much time I spend in any given task, possibly discussing the issue with my supervisor
tracking what "blocks" me most often
immediately see where I am compared to my schedule
manage in a better way my long todo list (e.g. answering faster to the "what I should do next?" question)
Do you have any suggestion?
Note on the scrumish tag: read the Henrik Kniberg's PDF. He first introduced the definition of scrumish on page 9.
If I may, I think that you are on the wrong path. Anything else than 1. or 4. is overkill and pretty much useless for a non distributed team. So for a team of one person...
Seriously, if you can avoid using a web based application, just do it. First, unless you are already mastering Scrum/Kaban, you need to learn the process, not a tool. Don't let a tool dictate the process. Then most web based tools are just too much click intensive, less easy and fast to update, less transparent/visible than a spreadsheet and a physical board. They are really 2nd category options.
So, I'd go for a spreadsheet and a physical board combo. If you need some charts (I'm still wondering what kind of chart/metrics you want to generate and what value they provide), a spreadsheet is the ideal tool (but honestly, you don't need any tool to draw a burndown). If you need to work from home, take the spreadsheet (or use google docs) and post its with you. Let's be objective, the impediments you mentioned are actually not real.
Last thing, if you had chosen the simplest thing that can possibly work, you would already be doing Scrum, Scrumban or whatever. So, instead of looking for a tool, my advice would be to just start doing it.
agilezen.com seems like the ideal solution for you. I have used it in the past solo for myself and it is convenient. I would not let a prejudice against non-OpenID sites get in the way of making a good choice.
pick the tool you already have, and start using it; don't let the absence of the "perfect tool" become an excuse not to start
EDIT: pick the simplest thing that can possibly work. In your case that would be whiteboard and postit notes. These have almost no setup overhead and will provide a constant visual reminder of what you're supposed to be doing.
And I suggest that you get used to making decisions on your own, as you're going to have to be your own Scrum Master ;-)
In the interests of diversity ;-) www.kanbantool.com has just launched too. It's open beta and seems at first glance even more "lightweight" than agilezen.
Target process is good too
We've been using JIRA with Greenhopper for a few months, in an effort to go agile. I use it for both Scrum for development, as well as for my personal kanban. The software is pretty flexible, and I'm going to keep with it. The story/subtask management is really handy, and it's fairly easy to use. One thing I like is that you can add stories/cards quickly, and can customize the data. This allowed me to add definition of done fields, work order numbers, etc.
In short, we're happy with it.
Bright Green have just launched a free version of their tool. It looks good .. the free version is fully functional too: https://signup.brightgreenprojects.com/plan/Free
I've tried out another kanban product for personal use and am absolutely loving this one. Feels lightweight and simple but actually packs in a fair amount of functionality at the same time.
www.kanbanery.com (free for personal use)
A novel tool not mentioned before is getsmartQ (out of beta since Dec 2010)
Key characteristics: very intuitive, supports LWP, customizable forms, and task discussions
Pros
configurable workflow, mark overdue stories, mail notifications (e.g., for upcoming story deadlines), multiple story owners
Stories form completely customizable, per project workflow and story forms, different roles (people only creating stories)
very responsive GUI with partial updates
Apparently good support: I've asked a question and got a good answer within a few hours
Cons
no easy way to declare something as blocked or to distinguish type (feature/bug/..)
no API
no subtasks or story dependencies
In comparison to Agilezen it has a more sophisticated notification system, but apart from that still lacks important features (see cons above).
Note, getsmartQ is under active development and hence missing features mentioned above may have been implemented in the meantime.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I work with scrum about 2 months and don’t have all the experience I wish, so I would like to hear some inputs about it.
My concern is people never say about drawbacks for the two sides; company and workers.
I know the benefits of a cross-functional team but which are the drawbacks? What is hidden beside the amazing Eden Garden?
I'm confused because as a company benefits of replaceable people, for the team is good because the opportunity of having knowledge and share experience (besides all teamwork benefit).
Again, I know all the benefits but I want explore the drawbacks just because in the middle there are the ordinary people.
Normally these people dedicate heavily to gain knowledge. They buy books, courses, attending seminar and so on.
In every company when someone knows much more than everyone else, people and managers get desperate wishing or even demanding that these ordinary people share all their knowledge.
And that’s strange.. Because these are communism thoughts and we live in capitalism society and since I was born, everything was so competed and now people say about collaborative.
Can Scrum and Lean principles ruins (or making hard) the professionals' life?
Scrum and Lean, in and of themselves, cannot ruin anybody's life. Nor can they, alone, make your life.
The culture of your organization will always be a far more dominant factor than the particular product management or development management method in place. Scrum can be misused. Lean can indeed make workers feel replaceable and pressured to perform all day, all the time.
On the other hand, both tools (they are just tools) can be used to create high-performing teams where all members value each other and each others' contributions. Being on a team that delivers consistently good results at high velocity feels great.
You will also find every result in between. It depends much more on culture than process.
I believe that culture flows from the top. Therefore, look at how the company leaders treat each other, their subordinates, their vendors, and their customers. That will tell you much more about what your life will be like than which methodology the company follows.
I'm only going to address your comments about sharing knowledge reducing your own value. In an ideal team culture, knowledge itself isn't as valued as someone's ability to acquire new knowledge and solve problems they haven't seen before. When I think about the star engineers I have known, it's not because they know this or that, it's because it's obvious they could be on nearly any task, on nearly any team and they would both begin to solve the problem and raise the level of the entire team.
There are a few things I've seen from agile methodologies which I'd put against it when you're weighing it up.
From a developers perspective there are two things:
1) The short sprints often lead to short term decisions - which is as intended but can be frustrating for some developers. While delivering "just enough" is great for the project, asking a developer to do something that they know that they're going to have to very heavily refactor, if not rewrite, two sprints down the line can be demotivating.
2) Where you've got opinionated developers (and is there any other sort) I've seen conflict over prioritisation. Adding not only what should be done but how important it is and therefore when it should be done brings on a whole other level of disagreement. In theory the developers don't have a say here but hard delination never works.
From a management point of view they don't like the uncertainty. "When's it going to be ready?" "No idea, when we get to the point you say you're happy". Essentially for them it's a leap of faith - if they do it once then generally they're sold but getting them to do the first time is hard.
I will assume, that as one commentator suggested, you meant to ask: "What are the drawbacks of Scrum?"
I think that the biggest problem with Scrum is that it is easy to understand - but very difficult to implement properly. Scrum, like XP, like most methodologies is not built on individual atomic practices, each capable of improving an existing process.
Scrum requires a shift in the organizational mindset. It requires a shift from ego-centric to communal behavior. The entire organization should focus on bringing the most value, constantly, and do so over perceived self-interest.
For example, a cross-functional team member may be required to do things out of his comfort zone (the flip-side of being able to experiment with new interesting tasks), because it needs to be done by somebody.
Team Leaders and project managers need to relinquish authority when they are called to take on the role of servant-leaders, and when they are asked to stop telling team-members which tasks to pick, instead relying on the team to manage itself.
Stakeholders are forced to face the reality that they can't eat the cake, and have it whole, when they are forced to choose between having all of the scope they want or having it by the date they want it done (this is always true, but Scrum is really in-your-face about it).
Most of all, the drawback of Scrum, is its tendency to disillusion beginning practitioners. This comes from people expecting something from it that it can't deliver: A solution to their problems!
That's right! Scrum does not solve an organizations problems. It highlights them. It is up to the organization to step up to the bat and do something about them. Incidentally, this is done with what I consider to be the single most important ceremony of Scrum - The Retrospective! If you do nothing else in Scrum - do the retrospective:
Find out what you did well, and continue doing it.
Find out what you need to improve and do something to improve it.
Rinse and repeat!
In a presentation by Ken Schwaber to Google on Scrum, he once said that Scrum isn't necessarily good for the organization. It could tell you early on that your project is doomed to fail. If you avoid Scrum, you may have a few more months of ignorant bliss to prepare you for the day you lose your job. Funny, but true. Think on that.
Hope it helps,
Assaf.
I'm no expert in any particular methodology (Agile, Scrum, etc.) but I empathize with your feelings. One of the biggest issues I've seen is that a team that really isn't interested almost unanimously in the methodology will tend to have problems. A few outliers isn't a problem, but if 1/3 or more of the team isn't interested, it becomes a nightmare. Writing good software is important and a company should hire professionals that help them meet that goal, but if the team is forced to meet that objective without finding the experience rewarding the quality will soon drop off.
No, I don't think it will ruin your professional life, but it can be pretty miserable if a company is pig-headed and doesn't realize that they need an environment where their workers are finding rewarding work.
I'm not totally sure of the question because it was kind of hard to follow.
Basically... no? I fail to see how an agile principle could 'ruin a professionals' life'... if implemented incorrectly it could waste some of their time, meaning a small lack of experience gained. Other than that, if the methodology fits the business and is implemented correctly, then is is a powerful tool that is useful to everybody.
Any methodology only works if the people are competent.
Silly question imo.
I've certainly seen things packaged as Scrum and Lean make the development process more difficult. Usually the result of managers picking and choosing the aspects that support their purpose, without buying in to the underlying spirit. Any process can work if properly applied, and process can fail if applied poorly.
Cross-functionality isn't a means to make people replaceable. It's a means to solve flow bottleneck problems that decrease productivity.
Cross-functionality doesn't mean that everyone can do everyone else's job, it means that people are capable of assisting with the work step that come (immediately) before their work or (immediately) after their work.
A better term for this is "Local Generalization", or "Special Generalization". And again, the goal has nothing to do with making people more removable from the organization. Creating the kid of people who can use Local Generalization to their advantage costs a lot of money in teaching and guidance. Once an organization makes such an investment in a worker, they're even less motivated to remove them. And organizations tend to only make such investments in people that they already want to keep around.