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 8 years ago.
Improve this question
If you have a room full of capable developers, what can be done to encourage those developers to become excited and enthusiastic about software and software development?
No gimmicks, but a genuine move to create an environment where people want to work in software, not just because the company is a good company to work for overall.
In my opinion, the absolute, #1, most essential thing that motivates developers to be enhusiastic about their work is a sense of ownership over their product. All the team-building excercises, reading groups, etc. are good but ultimately ineffective if the developers don't have a sense of ownership.
Here's a quick, off the cuff list of things that are important, in my mind, to ensuring this is the case:
Developers have a real and honest stake in the future design of the system. There will always be requirements that come from outside the development team, but developers should be represented when those requirements are discovered and be able to give real input into the future state of what you're working on.
Developer championed requirements or changes to your solution should be given a voice. A balance needs to be found, certainly, but all too many companies don't have proper mechanisms to allow pure development-focused requests to get through. These could be product enhancements, building up unit tests or simple refactorings, but they are essential to the quality of your product and for giving developers a stake in your project.
Developers should have contact with users. A development staff that's treated like the guys in the basement who churn out code are never going to have a very enthusastic approach to the product or developing their own skills.
Embrace new technologies, even if it's only for a PoC or prototype of what the technologies can do. No developer in the world has ever been excited about churning out boilerplate code, and they never will be.
Let development teams own their process. Development methodolgies decreed from on-high will without fail demotivate the development team, who now need to deal with the added burden of planning meetings and waterfall development. Require that a process exist, but until there's a problem, keep your hands off the specifics.
"Just the way things work" is NEVER an excuse for a broken process. If developers have a legitimate concern with a process they need to follow, they need a honest chance to argue against it. As a manager, one of the worst things you can say is "That's the way the VP / Executive / CEO / God wants it, so we need to follow it". You need to champion your developers concerns, or failing that, allow them direct interaction with the person in question. If you as a manager are viewed as a sockpuppet for the executive, good luck ever motivating a developer again.
Shield your developers from all the politics to the best of your ability. Let them what they do best, develop software. Nothing kills a productive team like having to squabble in inner-office politics.
This well-known conversation says it best:
Peter Gibbons: Bob, I have eight
different bosses right now.
Bob Slydell: I beg your pardon?
Peter Gibbons: Eight bosses.
Bob Slydell: Eight?
Peter Gibbons: Eight, Bob. So that
means that when I make a mistake, I
have eight different people coming by
to tell me about it. That's my only
real motivation is not to be hassled,
that and the fear of losing my job.
But you know, Bob, that will only make
someone work just hard enough not to
get fired.
Hire the Right People
During the interview process ask questions that let you see their passionate about the craft.
Some examples, Do they:
Read software books or blogs, listen to podcasts?
Play with new languages/libraries at home?
Contribute to open source projects?
Once you have good people stay out of their way. Have the right amount of process, don't force unnecessary standardization, listen to issues, be honest about reasons things are happening.
Read Peopleware by DeMarco and Lister.
I've yet to meet a capable developer who is not already excited about making great software. The trick is to stay out of their way and not destroy the natural enthusiasm.
The Joel Test is a good start.
what can be done to encourage those
developers to become excited and
enthusiastic about software and
software development?
Nothing.
A passion for software development comes from within, and cannot be created from zero. Feeding an existing passion is easy- resources, training, and a visible appreciation for that passion from management are all it takes.
The only exception may be to lead by example. If you're excited, others may follow.
UPDATE: As has been said in other answers, it's much better to hire well up front. I'd pass over ten good programmers who just want a paycheck for one good programmer who codes in his/her spare time for fun.
ANOTHER UPDATE: This answer has been jumping around with up/downvotes, so let me clarify. The OP's wording specifically asks how to make an existing team excited "about software development". It is my contention that if they are not already interested in their chosen professions, there is not much an employer can do to engender an interest. A disinterested, unmotivated team will make a mess of the most fascinating project. By contrast, a motivated team of professionals that like their jobs can make the best darned calculator program out there, and enjoy every minute of it.
Having an interesting, challenging and profitable problem to solve, where all developers have a stake in the results. If not, you have a room full of developers sticking around as long as the pay checks clear.
I have to agree a little bit with the comment made by Pascal, but I'm not going to start off that way.
Overall, it has been proven that one of the best ways to give developers an environment that allows them to like their work is to give them freedom. However, your looking at a different route here, you are trying to find "passionate" developers.
To be 100% honest there is not a direct connection to "capable" and "passionate". There are hundreds of developers out there that are capable of being programmers, and mighty good ones at that. But many of them do not have any desire to become passionate developers.
To create a team of passionate developers, you really have to start with the recruitment process and HIRE passionate developers, not try to "create" them.
For me, the things that keep me motivated are:
A problem/task that I find challenging, that I can learn from
A plan to implement the solution in a way I think is reasonable. Nothing is more de-motivating for me than a management team that forces technologies I don't believe in down my throat.
Other folks to discuss the possible solutions with, be they on the same team or not.
A management team that appreciates the hard work I'm putting in.
Just to be precise, is the question "I have a team of developers, and I want to make those specific developers enthusiastic about software development", or simply "I want a team of enthusiastic software developers"? In the latter case, simply don't hire people who aren't enthusiastic.
In the former case, you're pretty much screwed. It's hard to change someone's personality so much that they start to care about something they didn't really take an interest in before. Of course it can be done, but let's face it. How many here have been unable to convince their better half that programming is interesting? For that matter, how many people have failed to adopt their girlfriend's enthusiasm for shopping, or shoes? ;)
Convincing people to share your interest and enthusiasm for something is hard work.
Unless you're willing to set aside a few years of your life for getting into the head of each individual developer, getting to know them and what makes them tick, and gradually push and prod them towards taking an interest in something that they previously simply considered a job, you're probably better off letting them go and hiring people who are motivated to begin with.
Give them interesting problems.
Give them the means to solve those problems.
Minimize the amount of crap they have to deal with that isn't directly related to solving those problems.
Reward them for successfully solving those problems. Don't underestimate the value of a sincere pat on the back from the guy who signs your paychecks.
Give them a stake in the larger venture -- beyond the next paycheck.
And when they suggest a new problem they think is worth solving, listen.
I think the biggest thing is the company has to value what the developers can do for the company. If the company is run by cheapskates who just see your developers as an expense they can't wait to be rid of then you are doomed. The developers' team needs to be viewed by management as a strategic asset that makes them money now and will make them more money in the future.
Also good communication in the company is vital. The developers have to be able to find out what it is the company needs them to do. Autocratic top-down bureaucracy and mushroom management can wreck morale and make it impossible for developers to add value, regardless of what level of enthusiasm they brought to the job. The software your team builds will be only as good as the communication in the company--I think that is what Conway's Law is about.
So that is a big challenge, in many cases an impossible one, because senior management will have their own ideas about priorities and communication and good luck influencing them. But the alternative is guerrilla development, where you're fighting an endless battle against your own company.
money, money, money... and don't say that money doesn't matter if the project is exciting or boring routine.
You don't.
You either have people in the team that love learning and always want to push themselves to be better, or you don't have those people in your team. Of course reality is, you'd have a mixed bag.
Just employ people who are enthusiastic (it's easy to tell), and don't employ the ones who see programming/developing software as 'just' a job.
It's impossible IMO to turn complete non-enthusiasts into passionate programmers. There is no silver bullet.
In Weinbergesqe fashion:
You've asked the wrong question. The right question is "What are the things that managers do that dispirit developers and reduce moral?" Then don't tolerate those things in your environment.
And oh by the way, you should already know the answer to that question. If you don't find another job.
Hookers and blow?
How about giving them a financial stake in the outcome of their software project(s)? For example, corporate profit sharing.
That being said, passionate developers are the kind of people who go home and write software in their spare time.
Going to a software development conference with good, inspirational speakers can make a huge difference.
Read "Dynamics of Software Development" by Jim McCarthy. Seriously, nearly the entire book deals with this and related issues.
Although I agree that it is not easy (or even possible) to create passion about programming, I think it is possible to keep passionate developers enthusiastic about their work. Even the most passionate programmer developer can become disillusioned if placed in a stagnant work environment.
So what can be done?
Provide plenty of opportunity for personal development, give lots of freedom to learn new things. Let the developers have some choice in the courses they take, and the conferences they wish to attend.
Toys - Not in the traditional sense, but being able to use the latest technologies
Provide a nice place to work. It doesn't have to be Google, but it does have to be somewhere you would want to spend time.
Of course money helps. Not in the sense that a company can pay for enthusiastic staff, but people need to feel suitable rewarded for their efforts.
I have found working in an organisation that has embraced agile development has many of the correct qualities for building enthusiastic teams.
If they're fundamentally unenthusiastic about software development, there's nothing you can do.
If they're enthusiastic, that's great, and you need to avoid squelching that. There are some excellent recommendations elsewhere in these answers.
If they used to be enthusiastic, and have had that beaten out of them, you are likely to get good results by giving them reasonable challenges, shielding them from bad management, and in general treating them like valuable and respected people.
If you have a room full of capable developers, what can be done to encourage those developers to become excited and enthusiastic about software and software development
The correct question is actually "What can be done to encourage those developers to become excited and enthusiastic about software and software development in our company".
It's quite simple actually. The answer has never been a secret. It's just nobody listens to it.
Very simply elements:
Let those enthusiastic developers work among other passionate people. Remove those who don't care from the team. Otherwise they will act like diseased cells proliferating apathy and depression to the other team members.
Aspire to develop a quality and professional product
Establish a professional and effective process
Trust and respect people. Value their knowledge. Respect their opinions. Actually, it's part of a bigger strategy: let your developers be able to make a difference and let them see they can really influence and change things.
Let them grow professionally and let them see this growth is appreciated and needed by you
Now what doesn't help at all.
Pay them badly. Developers are also humans (for the most part) and they also have their bills to pay.
Reject their initiatives, proposals and improvement suggestions. Tell them each time they come up with something that their attempt to introduce change make them a foreign und unwelcome element in the company.
Have low quality product and have no interest to make it better. Hacks, copy/paste code, accumulating technical debts, things falling apart after each release, that does not motivate developers.
Have badly run development and chaotic process. Tasks, projects and small decisions taking a new vector every few days will finally remove desire to be involved from anybody. Failing schedules because of unpredicted work load and feature set, they all go down the road. It will suffice to run out of coffee some day for some of them to start moving elsewhere.
Have a boring and uninteresting social environment. Developers having nobody to talk to to share their interests will finally feel dull. Not everyone is interested in taxes, football and kindergarten issues as the only topics on social gatherings.
I am inclinced to say nothing like others have, and i must agree that a real passion for it is not something you can create, it either exists or it does not however there are things you can do.
Scoring high on Joel's test is a great start,
Fire all the PHBs and hire smart managers who maximise the chances that the software will actually be finished and work right.
A management team that knows computers and can hold their own in a technical conversation is a very helpful feature. Don't try to sell passionate developers on hype, tends and buzzwords.
Set clear and stable goals and communicate the goals accurately to the team or people. And then just get out the way to let developers get that done. Do not go far away from developers though, you need to tackle those issues like out of free food, purchase of fancy office equipments and other trivial things that developers do not care to do yet useful to improve productivity and add perks to developer team.
Dan Pink notes 3 things that motivate people if there is creativity required in a job. RSA Animate - Drive: The surprising truth about what motivates us is a 10 minute video about these but here are the 3 things:
Autonomy - Give the team control over the schedule and empower them to own their work.
Mastery - How well are they developing their craft of building excellent software.
Purpose - Why are they making this software? What massive benefit will it have?
A few other sources on this stuff:
Top Three Motivators For Developers (Hint: not money!)
Autonomy, mastery, purpose
Empowered Teams Are Dead – Long Live Autonomy, Mastery and Purpose
Why Open Is Better Than Proprietary?
Money vs Autonomy/Mastery/Purpose
Creating an Organization that Values Autonomy, Mastery, Purpose
The 3 Things That Motivate Us
Related
I work in a big organization, spread around the world, about 17,000 people. Have to ask for money wayyyyyy in advance for projects before even really knowing what they are.
So we're redesigning an old intranet. Spending a chunk of money we have on user research and UX design phase. More on the 1.0 and piloting it and dealing with content migration and all that fun stuff.
Any ideas (insane ballpark here) about how much $ to ask for the next phase (rolling it out, more testing, actually replacing the legacy intranet)? I know details are sparse but there are some silly budget deadlines that require me to pull a figure out of thin air before I even really know what our end users want. If I don't come up with a number, we get nothing and have to hunt around in various budgets to get cash.
What would you throw out for low / medium / high numbers here? Low being open source, out of the box functionality, not insane customization, no more UX research beyond what we're already doing, and off we go. Medium being a nicer step up, and high being paying someone like Igloo $400k to use their out of the box platform, and then another bunch of custom plugin development and design work on top of that.
Right now I'm thinking 250k, 500k, 750k. Am I in the right ballpark, or am I over in some other arena that's not even in the same league and hasn't seen a baseball game in years?
As you've all but acknowledged, it's an impossible question to answer. You are constrained by an illogical system which seeks to reduce risk by increasing control in the mistaken belief that accounting for all spend in advance will increase return on investment. Your challenge is to learn how to play that system to your advantage, secure your funding and achieve the freedom to deliver your project with minimal interference.
Support
Fortunately, you are the best-placed person to do this. You have the best understanding of your organisational context and if you look at broadly similar (global, cross-functional) internal projects, you can get a good idea of how these projects are regarded and how they secure and maintain support and funding. Talk to colleagues and learn what you can. Ultimately you aren't looking for a right answer - you need to know what constitutes an acceptable answer and how to proceed when your guess proves to be "wrong".
Start looking externally to learn what you can about projects in similar organisations. Listening to others' experiences will give you a better understanding of potential risks, so dig deeper than the run-of-the-mill success stories. You might consider attending conferences, intranet-focused meetup groups and participating in online communities.
Vision
What is important is that you have a vision for your intranet project. As you go on, this vision may change. You will hear lots of assumptions about what people expect to be on the intranet. It's great to read you are conducting UX research as it's vital to understand what people actually need and use.
Needs
A guest presenter at a recent intranet event I ran showed us an intranet she'd built in-house over a five year period which was designed solely to help employees do their jobs effectively.
There were no generic calendar tools, no pages of content that no one ever looks at and no fashionable social features. Instead there was a lean, focused business tool, written in PHP, on which she'd spent GBP20,000 each year.
Equivalent value? Probably a month of Sharepoint consultancy.
It takes careful leadership and communication, but once you stop trying to deliver mediocre generic solutions based on what everything thinks "should" be on an intranet, you can ditch out-of-the-box tools and start focusing on your users' real needs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work in a small company (2-4 software developers) where software is "only" a part of the main product (specialized measurement instruments). So far the software has been built from start to end with no formal process at all, but as we're steadily growing in both in number of products and people involved, it's evident that we need to adopt some kind of methodology for the whole thing (designing, building, testing, maintaining) to avoid blowing into a mess
The problem is that none of us has much real-world experience on such processes. Wikipedia's software development methodology and software development process entries list lots of practices, and I'm aware of the modern buzzwords (agile, extreme, etc.), but we're still lost on how and from where to start all this.
What should we do to get started, given that currently we have no formal process, and the goal would be to have a light process that helps us keep things under control without slowing us down? Is there some:
Essential de facto literature that we should read first?
Essential tools? (We do have a SCM, but should we start using something like FogBugz?)
Practical "do this and this" guidelines?
Any guidelines are welcome, as long as they're not 1000+ page books! I want to avoid both the religious hype and the dull academicity that seem to surround this field, and find out what to do in practice.
Highly recommended reading includes : The Agile Manifesto and The Pragmatic Programmer. Subsequently, you'll probably want to get familiar with Scrum software development, or Test-Driven Development. At the very least you should have:
Source Control repository
Bug tracking system
Standard set of tools
for communication (A wiki tends to be
popular for documentation, these
days),
IDE
Testing framework
A lot of things will depend on the skills of your team and the application domain that you're seeking to go into. Get yourselves familiar with some methodologies, then practice them. Have 15 minute standing meetings at the start of the day. Develop code incrementally with a write a failing test, make it pass, repeat mindset. Etc etc.
I would suggest to try Scrum for start. As lightweight project management framework it should suite your small team needs.
To do that less painful I would also suggest temporary hiring someone familiar with scrum (certified scrum master maybe), after 3-4 months you should be able to keep it running by yourself. Really investing in few months of experienced team member should pay off. And I don't mean analytic, consultant or whatever you call person that comes, analyzes, makes presentation, takes money and goes while you stay with a problem. I mean Team member that will work with you but also introduce scrum to you via daily practice.
You could also just read some books instead, or send one or two team members to a training, but I think that having someone to incorporate Scrum into your daily work and start learning by examples is the best.
Good description detailed description (based on daily work) would be Scrum and XP from the Trenches (alternative source).
Subscribing rigidly to someone else's view of the development process isn't going to work for everyone. Start with the real basics
Get the basics of the development process right - see The Joel Test.
Track everything. Use a system like JIRA, FogBugz or so on to track all issues, features and bugs that are ever reported. Track how long you spend on each task; the information you have the better prepared you'll be.
Triage - Work with stakeholders to make sure what you are doing is actually important, rather than just what you think is important. In my experience, developers and customers often have wildly differing views!
I'm a huge fan of the recent Lean literature by the forerunners of the movement, Mary and Tom Poppendieck:
Lean Toolkit
Implementing Lean Software Development: From Concept to Cash
Leading Lean Software Development
These are very practical books that look at the whole business value chain from a software team's viewpoint, instead of being head-down in software land and ignoring business goals.
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 3 months ago.
Improve this question
First a little about myself. I am not an experienced software engineer, architect or developer. I have done mostly small ASP and ASP.NET projects in C# for the last 5 years. I am pretty good with HTML and JavaScript. These projects were done when I had free time from my other duties which were not related to software development. I have now been moved into a software developer position. The company I work for is not a software development firm.
I am now working on a Silverlight LOB application with WCF and Entity Framework. I have been given little specifications for this project, just the 'make an application like X, only simpler so we don't have to pay for it', my boss doesn't check on my progress as often as I think he should, the project manager(a co-worker) will stop by now and then but we never discuss the specs, architecture, UI or business rules. I am mostly just asked when I think it will be done. I have had to learn Silverlight, WCF and Entity Framework to work on this project which is not a problem as I really enjoy working with these technologies. The problem is I am the only one in the company that knows anything about these and have no mentor/boss to discuss the problems and how they could be solved. I have been able to seek out one interested party in the company that has at least given me a list of some of the requirements.
I can't believe this is how software development should be done. I think the project managers should offer guidance and keep a closer eye on what is being done to prevent going in the wrong direction(but how can they in my situation since the don't know the technologies!).
Should I feel this way or am I way off base?
Thanks for listening.
What you describe is certainty not optimal, but it's extremely common, particularly in smaller shops. Some people find it rewarding to work in that kind of environment. It's not what the software engineering books teach, but that's why there are so many software engineering books.
If you want to continue working in this environment, you're going to have to supply all the discipline you rightly recognize as missing yourself. Write up a spec. Build a schedule. Share these with your management. Hold yourself to deadlines.
Share your concerns with your management; don't be shy about that. Chances are, they recognize the situation. Your boss doesn't check your progress? Publish your progress to him. Show him where you need to get to, how far along you are, and what's blocking you.
It'll be chaotic, no doubt, but you'll learn a lot.
Every organization is different. If they are operating in this capacity then you should adapt and make the best of the situation. It's either happening because that's how things are done and they are aware of it, or they don't know the wiser or don't want to invest to improve the process of delivering strategic/tactical projects.
In a perfect world everyone would have a robust Quality Methodology in place which would provide a framework for Project delivery and systems implementation. It's just not a reality.
Here are some tips to help you operate more effectively:
Identify your sponsors (the people who own the product) and determine the high level benefits and driving objectives of the business problem they seek to solve
Identify your stakeholders (who has influence and who has interest) and get them to communicate their needs as much as possible
Involve both sponsors and stakeholders in the process as much as possible or as much as they want
Capture what requirements you can from them through written form (email)
Provide opportunities for them to gain visibility into the delivery and to provide feedback
Your project will likely fail from your boss point of view. Because i'm sure you developing program not suitable for him. But you don't feel guilty. It's your boss' pain.('because you are good programmer). Sorry for so dark post :-).
The role of the project manager is not to know the technology, but they definitely should have a finger on the pulse of the project, so to speak. The real project management job is not to control the project, but rather to enable it. Either way, from your description, looks like yours isn't doing such a great job at it.
The other extreme is a process-heavy organization where meetings and committees decide everything, and all the real communication, if it exists at all, happens through side channels.
The ideal world lies somewhere in between.
Your project manager should not be too concerned with how you're doing things. Since they have no qualifications, the best they can do is connect you with someone who does. When they can't verify that you're building the thing right, they should at the very least ensure you're building the right thing. Even if it's for internal use, you still have a customer, and no communication with the customer spells bad news to me. :)
If your PM is not concerned about the issue, you could try to do something yourself. For example, ask the PM to connect you with a would-be end user of the application. Extract bits of your application and give them to the user to play with -- just make sure the bits you give them don't look or feel too finished.
If you can't change things, take this as a learning experience. Make sure next time you're up for a project, you know the things that went wrong last time, and try to mitigate them from the start.
And finally, if your bosses tell you this is a "more agile way" of working, punch them in the face. Agile is, or should be, synonymous with discipline, not complete lack thereof.
Good luck!
It is a hard situation. Only you can really determine the best way to proceed. However, I do think that the concern with the schedule and concurrent lack of documentation (requirements, expectations, use-case scenario documentation, etc) is a train-wreck waiting to happen. Even the sharpest and most experienced dev-teams suffer from the same problems.
The "when will it be done?" questions are best mitigated by regularly providing small partially functional builds that you can use to get useful information out of the moving target that is your customer. It is amazing how much communication can occur when somebody (your boss/customer/end-user) can actually "play with" something in front of them and reconsider what they really want.
I believe this situation is quite common. I had this, too, at my previous job. Here the bet is on the fact that you are already independent and well-versed in your business. I think you should tell your manager how you feel about this.
They should change something after hearing your opinion about this situation. Because if you do something wrong and the manager does not notice it, the company can lose a lot of money and time.
But it’s also not worth constantly waiting for someone to guide you and check your work. In any case, your workflow should have self-management.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am looking for an easily digestible book to present to my boss/team.
Background info: More and more of our meetings at work involve my boss/team pondering how to implement more "best practices" around here. ("Here" = a very small application development shop. 4 developers)
The following things are items that my whole team agrees that we need:
Nightly builds
Decomposing "bugs" in our bug-tracker into smaller, more-specific items
Automated testing
The problem we face is how to get started.
I believe that if my shop could simply choose a clear and specific plan or set of rules, then everything else would fall into place. Right now we are stuck in discussions of fuzzy, feel-good ideas and nice-sounding buzzwords.
Please recommend to me your favorite book (or online resource) that contains clear, discrete, sequential steps for implementing a management scheme for guiding a TDD or Agile team/shop.
I realize that there are other paradigms besides TDD and Agile that would also address these concerns, but my own self-interests and biases point toward TDD and Agile so I would love to harness my team's desire for change and "nudge" it in that direction. Or feel free to slap me down if you vehemently disagree with my sentiments! I will take no offense. :)
As others have stated, I think these questions are answered best when respondents list only one book recommendation per answer.
Thank you all.
To throw another Pragmatic Programmers title in the mix: Ship It!
Great book - take a look, might suit your needs with management.
For your needs I recommend Test Driven Development: By Example (Kent Beck). It is clearly-written, more practical than theoretical, and prescribes time-tested recipes to adopt an agile, test-driven approach.
I suggest that you start with what you agree on: Nightly Builds and Automated tests. Nightly builds is a no-brainer. For Automated tests I would start with:
Each commit with new functionality should have at least one automated test
Each commit that fixes a bug should have at least one automated test that fails without the fix and succeeds with the fix
If you do this, you will start to gain experience. With this experience it will be much easier to understand all the good advice that the literature has.
There is a lot of good books on good practises, but you have to figure out what works for your team.
Agile methods are not really methods...
There are more a spirit. The main is a focus on :
communication
reactivity to changes
customers orientation
This can be achieved in lot of ways, and it's more important to find your way to do it. If you want an example of what this spirit can be, you can read the free 37signals' online book, Getting Real.
But there are some steps you can start with
They are no big rules you must enforce, but you can try the following and see how it goes with you team :
Quick stands up meetings. 5-15 minutes daily meeting where everybody stays up on his feet and explain what he has accomplished, what need to be done and what can prevent him from doing it. Keep it under 15 minutes, with the minimum number of people.
Set simple goals for short term deadlines instead of big goals in weeks.
Build small team (3 persons) and divide the work between them. Put them in the same room and ensure they have at least half a day to work without ANY interruption.
Set many little regular review with your customer. Don't write specs. Sketch, design, prototype, show to the customer, fix/adapt/change then build. Then do it again.
Testing, versioning, bug tracking are tools, not methods. No one cares how you do it and with what software are long as you do it. They are not the issue.
It's not really a step-by-step book, but full of great advices and easy to digest: Practices of an Agile Developer. And if you want to have in house TDD training, I recommend netobjectives. I had their TDD course ones and it really opened my eyes.
Sadly, even the most clear and specific plan can turn out to be disputable.
I'll tell you what works. Starting TDD immediately. It has boundaries. It's relatively easy. You'll still have a million questions.
You are free to say, "But what about nightly builds?" "What about using the bug tracker?"
A lot of pondering can mean one of two things.
First, it can mean that someone is muddying the waters with "concerns" and "questions". Sometimes this is really displeasure at changing, voiced as "concerns". Sometimes this is really crushed egos ("I thought I was pretty sharp, now someone is saying I must have improvements imposed on me.")
Second, it can mean that this is dauntingly large. Consequently, don't look at this as "Many New Best Practices". Look at this as just a few incremental improvements. You're not changing yourselves fundamentally (well, that could happen, but don't start out with that as your plan.)
My experience is that you can only do one new thing at a time. Do TDD until it's boring. Then do something else. Often nightly builds become obvious after you have a robust test suite. Then when that's boring, do some other small, incremental process improvement.
One thing at a time. Baby steps. Avoid throwing out babies with bath-water. All you want is to be a little better next month than you are this month.
If there are concerns on adopting one small incremental improvement, find the root cause. Who's ego is bruised? Who's worried about change?
You can print him Scrum and XP from the Trenches by Henrik Kniberg, It's more focusing on agile development process that on TDD, but it's an easy and quick read.
Check out books by Marty Cagan.
my favorite is Planning Extreme Programming
EDIT: it provides a complete replacement for traditional project management geared towards an XP/Agile team
the danger is, adopting modern development methods and then strangling them with archaic project-management and administration practices!
I work for a software vendor whose market is developer tools and we have been looking for a QA person for our products.
Since we are a small shop the position will be a combination of Support and QA however since we make developer tools, our support consists in large part of actual development (in that the person must read and understand our customers code and find and point out bugs in it).
The QA portion will also consist of writing applications (in a variety of platforms and languages) and testing how they work with our tools.
The main issue I am running into is when you tell someone with development experience that the position contains "QA" it its title (or even in the job description) they shy away from considering the job.
I'm very interested in feedback and suggestions for how I can find a good person to fill this job and ensure that they are happy doing it. Any ideas?
Money and responsibility.
The reason I shy away from these types of jobs is they dont tend to hold my interest long enough. Having real development tasks should keep you out of that category. The other problem is the salary is usually significantly lower with that in the title.
I am a developer, but spent time working as a QA person (test writing, automation, tool writing/coding). I saw it as something I was doing on the side, and would eventually move out of.
The main reason I wanted out was that it simply was not the career I wanted. No amount of money/responsibility would change that. However I think respect has something to do with it as well. A lot of QA work is simply unappreciated, so that is something that would need to be clearly explained as "not how things work at your company."
I would find someone who wants a QA position, but has strong developement/coding/problem solving skills. They could fill in doing the tool creation or other small coding tasks, but it would be on the side. Sort of a reverse of my feelings above.
I think the ideal combination of jobs is product manager + QA. What I mean by product manager is someone who writes requirements documents and is responsible for making sure the product meets the requirements. This person would be a peer of the lead developer, not a superior. A person who is a developer but likes management and wants to take that career path might be very interested in that combination of roles.
To start with you can just take "QA" out of the title and description if that seems to be 'hot button' that is keeping candidates from looking at the position seriously.
From your description, your position doesn't have much in common with a traditional 'tester' role - the work is mostly writing and thinking about code, not banging on someone else's code and trying to break it. Think of it as a fairly eclectic, tools-oriented development position, and try to advertise and staff it accordingly. (And expect to pay accordingly as well - you get what you pay for.) There are quite a few developers out there who have good skills, but maybe a little shorter attention span than others, and who would prefer to work on a succession of mini projects rather than a longer-lasting piece of a bigger project.
You may just want to keep "QA" out of the title, and call the position "Developer Support" or something like that. Don't mislead any candidates about the duties of the role, but you can cast it more as a "You will be responsible for building the releases and ensuring they are ready to ship to customers."
Also make sure that there is a career path that leads into more development, not more QA, if that's what the candidate wants.
Finally, make sure that the other developers treat this person as a fellow developer, and not as somebody outside the team.
It's sad that "QA" has some stigma attached to it among developers, but it does.
I was a programmer working as a tester for a little time. If I may, the answer is quite simple: let them do whatever they want.
If you give them free reign, I can guarantee that your software will be tested in ways you never imagined.
If, on the other hand, you try to control such a person, then they will grow to despise you. This is inevitable.
The benefits outweight the costs. If you're a large corp then this decision is easy. Just hire software developers and tell them to "go to town" on your product. You'll love the results.
Money and responsibility are key, as Adam and Chops point out. Quality engineers should be on the same pay scale as the developers. Interesting work is also an important factor. The role sounds like a nice variety of tasks.
At my company, developers are often loaned to the test team between projects or when test team is swamped. Some have a knack, others don't. Still, most developers would rather test their own code than find bugs in others' work. The test managers actively woo developers with strong testing skills. I resisted switching to the test team for seven years. A promotion, a 20% raise and a promise that my role was primarily trouble-shooting, management and planning finally convinced me to switch. I do more hands on testing than I thought I would, but I get the challenging work too.
Pay comparable to development. Be truthful; disclose actual expectations of the role. Change the title to Software Quality Engineer.
I agree with Adam, money and responsibility are key. I would suggest that, if you're within a small company, that your QA team is small/non-existent. That probably means there's good opportunity for someone to come in and make a genuine effort to contribute and shape your companies QA policy, procedure and workflow.
Our company had a similar issue with QA, and we're still not there 100% with it. But giving the QA person the power to dictate policy and procedure, and participate in all aspects of product development so as to keep them in the loop has worked well for us. This means, when it comes to QA and testing, we've got someone who understands the product, knows it inside and out, has been heavily involved from the start, and has heavily shaped the procedures they themselves, and the development team, will follow. Responsibility is key.
Most developers are neither good testers nor do they enjoy testing, and you want someone who is both. Be honest in your job ad that the position is NOT a stepping stone to a developer position and you will have fewer applicants but a better chance of keeping who you do hire. QA typically has lousy pay, so if you are willing to pay better, you should be able to find someone. You won't keep them if you hire someone who wants to write code all day, regardless of how much you pay them.
I think you have a toughie here:
The cost of a full time developer for doing the job you require would be too high.
Most dev's (including myself) would get incredibly fed up, very quickly. Most dev's passion is coding, they want to do it as much as possible. Where TBH, from what you have said, it may be very little in the job role you have.
I would say perhaps look for a Junior, someone fresh with little experience. They will probably mould better to your testing/QA process, and it gives them a chance to start looking at production code, with perhaps opportunity to work with it.
Unless you are lucky, I would not expect a "developer" to stay for long, so either expect a bit of turnover, or possibly expand to a full dev role if required, and get a cheaper sole tester in.
I know you are a small shop, so finances may be a large part to play, but I would say you need to weigh up the possibility of getting a dev in and fixing the problems you have if they occur that often. Testers are cheap by comparison. May be best to get a tester in, find all the issues, then get a contractor/part time dev in to fix issues.
Dude, A certain company I work for has found the solution to your problems. Hire QE not QA. QA (Quality Assurance) does have a stigma to it. The job title itself implies boring rote tasks to most developers. QE (Quality Engineering) sounds just as bad, but doesn't scare off nearly as many people.
If all else fails just hire a developer. I mean seriously, you want someone who can write code, so hire someone who has training in that. The thing is, you need to look at your applicants and talk to them. You are looking for someone who knows how QE works and you want to hire a developer that works in the language your program uses not what it's written in.
The most common title for this posotion is "Software Developer in Test".
But I think another trouble is much more important - its hard to prevent a person with good testing and dev knowledge from migrating to Dev team