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.
Related
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 10 years ago.
Improve this question
The following is an outline of our current organization (or pecking order) and brief description of their roles
Solutions Manager (Visionary "Build this web-based solution that can do A,B and C")
Software Engineering Director (Over departmental PM's to manage resources, spend capex wisely..point finger, drive deliverables..go on golfing, and skiing trips without notice)
Lead Architect (Me, outlines, and established architectual and code base for solution from end to end, including hardware, software planning to get it done within budget. Coaches and drives development team to build product under an SOA, sprint dev environment. Write code, but mostly communicates with SM's to ensure vision and/or requirements are being fulfilled..etc..etc)
Middleware Developers (Engineers responsible for SQL adminstration, and coding middleware REST architecture)
Frontend Developers (Engineers responsible for developing, coding and deploying Web Portal)
IT Admin (Engineer responsible for hardware acquisition, security standards, co-location move.
I am the Lead Architect responsible for ensuring that what the Solutions Managers want is delivered. My delimna is the Project Manager somehow promotes a questionable frontend developer to a Lead. The now new de-fact Lead Frontend Architect relishes the title and no-longer believes he/she has to stay in synch with me much less follow standard development protocols. A rift is caused. To compound the issue the Project Manager (sympathetic to the less than productive Front-end Lead Architect) dissects the project and shelves critical components for a much future date until he or she can catch up.
Here's the kicker: The solutions managers and customers are not happy, and look to me for answers. They want to know why some of the features they've requested were shelved. Meanwhile the Engineering Director has no clue of the ramifications of this impending train wreck. No matter how I explain that 2 kings do not a good product make, the status quo seems to be getting worse. I don't have the authority to deal with the matter in a more direct and conventional matter. Lots of voice, and very little people with back-bone to follow up.
What is wrong with this picture?
What steps can I take to remedy this (if it is even possible at this point)?
What's wrong? To be honest, your job is to come up with it, and his job is to make it and in reality it's leads job to cope with you. You should simply finish architecture and clearly state that your job is done. If PM has any touch with reality left, He will put pressure from you onto lead. Flowchart of "doing the job" flows from hierarchicly highest to lowest, what I want to say with this is that you should not be entitled for poor coders work while your job is accomplished. If that makes any sense for you.
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 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 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!