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 5 years ago.
Improve this question
I have read much information about agile and waterfall and I just cannot think of any reason why someone today should do the waterfall. I am concerned especially about testing process.
Do I miss something, is there some clear advantage that I have overlooked?
There are still cases where waterfall is appropriate. Canonical examples include military, space, medical and safety-critical systems such as flight control software where you absolutely need to determine the spec first in exact detail, develop it, then thoroughly test the complete product.
Agile works for most business and product software (i.e. the majority of software built) because it allows users to start with a rough idea and refine it as they go along. If their website or internal line-of-business application isn't quite right (or has bugs) for a few iterations then it is generally outweighted by the business value that's delivered quickly from the bits that do work. You wouldn't want to start with a rough idea for a nuclear power plant controller system and refine it as you go along.
The trade-off of using pure waterfall is that it is orders of magnitude more expensive to develop software in these scenarios. However, the cost-benefit is still favourable since you cannot afford for (say) your spacecraft to hit a null pointer exception halfway into orbit.
There are of course shades of grey in between. It is possible to use Agile techniques within a waterfall framework (see RUP) and the balance can be scaled up and down between pure waterfall and pure agile.
One of the main pros of the waterfall model of development is that it has been used for years and years to develop. It works. Even though there is a large shift and focus on agile, waterfall is a very clear process with start points and end points for each section of the development.
With the introduction of agile programming it is easy to see the falls of waterfall and how it is not as adaptable to the demands of programming these days.
As long as you are careful and plan ahead and test sufficiently I would say testing in agile can be as effective or even more effective than waterfall - it is certainly easier to work with agile when testing throws a few bugs that can cause design changes your way.
Another thing to consider is developing using, test driven development. http://en.wikipedia.org/wiki/Test-driven_development
Outsourcing
I have seen many companies stick with waterfall for outsourced projects. Most vendors will be very specific when it comes to pricing quotes. Waterfall suits this model quite well - you hand off what you want, they produce it. I'm not a fan of this, but I can understand the reasoning for executing this way. I think most outsourcing companies will eventually find a way to become more agile as it becomes more of the industry standard.
The answer to the question depends on what kind of development methodology you are using for your project. Is it agile/Is it waterfall/etc etc. Over the past three to four years I have been part of projects that involved only Agile or only Waterfall, so will be using them as my reference point.
If the requirements of the project keeps on changing we should never go for a waterfall design , since waterfall methodology assumes that designing/analysis/etc has been finalized while if we go for agile it is based on an incremental approach where we divide our project into incremental stories and building/testing as we go along, so if the requirements change it does not involve to much of re-work from developers as well as the testers.
For example say we have to create four new web pages as part of our project, then waterfall assumes that their design etc has been finalized and that testing will start once all the four pages have been developed while incase of agile what happens is we first develop one page and hand it over to the QA for testing [manual/automation], and so on. Thus we can see that agile adds value to our project by not making it susceptible to requirement changes in addition to finding the functionality flaws/bugs at the time of development.
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 years ago.
Improve this question
We have two distinct agile teams, each working on separate, but related, applications.
Each team has, until now, been able to work in an independent fashion (distinct code bases, persistence stores, sprints, backlogs etc). Recently, product management decided that these applications will become even more closely integrated. On a side note, the size of each team (comprised of QAs, Devs, BAs) will be increasing over the next 6-12 months.
Management has decided to keep the agile process largely intact, since it has worked well (two teams working independently as much as possible) but have floated the idea of a contract-based service layer as means of integrating the applications.
In each sprint, any story that requires integration with the other application will be identified. At that point, an additional "integration" story will be added to the other teams backlog. That team will then be tasked with fulfilling the contract. In the meantime, the other team can continue their original story work, substituting a mock/fake service until the other team produces a working service.
Since Agile preaches a KISS philosphy, several people on the teams have taken issue with the "complexity" of this approach. They are advocating continued used of stored procedure sharing as a leaner/simpler integration methodology that "has worked well in the past".
I prefer contract based programming for all sorts of reasons, but the main reason is it's ability to provide compile time visibility into the behavior your application is expected to provide. You also get clear boundaries around who owns what code, and whose code you are likely to break if you break your contract. Stored procedures do none of that.
Since we have already reaped many benefits from agile, I'd like to think that there is already an "agile-friendly" way to deal with this kind of app integration/synchronization. Does creating a contract based SOA layer meet the agile smell test? Is there a third option I haven't considered?
I don't think that keeping current process intact is good idea. Cooperation and communication between teams has to increase otherwise it will have negative impact on both teams. You should follow similar practice to Scrum of Scrum.
Edit
Scrum of Scrum: I don't have experience with project handled by more than one scrum team but because of very good experience with Daily Scrum a believe that Scurm of Scrum works and increase productivity in all teams.
Great question. Walking the design tightrope is always a tricky one. I think keeping the applications as loosely coupled as possible is definitely the way to go.
The simplest thing that could possible work is a great approach, but following this to a dogmatic end without regard for the SOLID principles and general good design is going to give you two applications that are tightly coupled and probably full of technical debt that will bring the team grinding to a halt at some point in the future.
Decoupling and adding the abstraction in now seems like the most sensible thing to do, as long as you aren't adding lots of additional "framework" that isn't yet needed. The trick is to ensure you have a good enough design that would allow that framework to grow if needed, without building out a lot of unnecessary stuff at this point - you need to do just enough to decouple the applications.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
My team has grown fairly quickly from 1 to 5 over the last year or so and are very interested in changing our development style from Waterfall to a more iterative approach like Scrum. We work for a University and specialize in CRUD web apps for internal customers who are always changing requirements along the way.
So, my question is...How do we best implement Scrum techniques?
Supplemental concerns: Is it recommended to quit Waterfall "cold turkey" in order to facilitate the transition or do you feel a progressive approach is more effective? In other words, pick and choose some scrum techniques to implement now and add others further down the road?
Make sure your dev practices can support agile. You should have automated tests, daily integration builds, one-change-one check-in, customer accessible test environment, etc.
Get your customer on board. Scrum is a business-centric PM framework. It is in their interest to use agile techniques because it gets them the greatest value for their money. But they have to want it.
Get your team, PO, and management professional training in Scrum.
Make sure you, your team, and customers share the agile values (Agile Manifesto style). You would be amazed how many people value documentation over working software.
If you have 1-5, then go cold turkey. Scrum is a simple framework.
IMHO a step by step approach is wiser. You should first start doing retrospectives at the end of each iteration / sprint (if you use iterations - if not, that should be step 0 :-)
On the retrospective, you look through what is going well, not so well, and what can / should be improved. Then pick the most pressing issue and think about how it can be improved - primarily using Scrum, but you may have a look at other (agile or not) solutions too if you feel the need to. The aim is to work out your own process, which may be strict Scrum, or a hybrid - whatever works best for you, in your specific situation.
Personally, I would go a bit more Jeet Kun Do when it comes to project management strategies. With my team, I've created a piece of software where they answer the scrum questions (with some personal sauce), so instead of 15 minutes of debating, everybody knows what to do. And it beats having someone taking notes.
Even though SCRUM/Agile project management is populair, the waterfall approach has it benefits too. I would give a try-out first and keep the goodies and get rid of the baddies.
Make sure your team is truly cross-functional. Get all team members be commited 100% to the project on hand.
Note - succes of scrum teams often depends on strong scrum master - hence try to get a experienced scrum master or a coach to help your team during the transition period.
Try not to mix waterfall and agile - suggest go cold turkey to scrum.
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
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!