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.
Related
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 6 years ago.
Improve this question
The questions may seem strange!
In the project I am working now, Scrum methodology was adapted from the last three months. We used to follow a V- Model as it was standard in embedded industry.
Our project ran into some trouble and this decision were made. What currently is being done is that the customer (Product Owner) is giving top level requirement directly to development team, the requirements team is just a part of it.
The development team works on it and show the final outcome to Product Owner and if changes are needed it is made. Once the Product Owner is ok with the result, then the changes made are reported to requirements and they document it and pass it to test team.
What my problem with such an approach is that in this process we are technically making requirements team and test team obsolete. They come too late into the process.
Is this the way Scrum works? In this process everything is driven by development team and others basically are more or less spectator.
Some where I saw that we could still have the V-Model within the scrum methodology?
Edit:
I understand the tiny V-model releases every sprint. But my question is do they all work in parallel? For example: in the traditional V-model, which is a modified waterfall, there always was a flow - the requirement team will release the requirement to Development and test and they work parallel in designing and then once development is completed the test team starts testing. How that flow is handled in scrum way of working?
You have mentioned that "The sprint is not complete until the requirements and test parts are done for each story. " In our project at least the requirement part is being done (test team is completely kept out and the testing is more or less done by the development team on the product). But the requirement job is more or less a documentation job.,
The entire scrum is being driven by the development teams perspective. We are seeing scenarios where Development team decide the way certain function work (because the initial concept is too difficult to implement for them or may be more complex).
There is no creation of boundary at any level! Is this the way Scrum suppose to work?
The test team in the project is more or less demoralized currently. They know very clearly any issue they find at system test level is not gonna be taken care much. The usual excuse from development team is that they don't usually see the issue at machine.
Having a separate requirement engineering team is obsolete in the Scrum way of working. You should all be working together.
Scrum suggests that you should be working in multidisciplinary teams and working in small increments. You can think of this as doing tiny v-model releases each sprint. The sprint is not complete until the requirements and test parts are done for each story. You should consider them part of your definition of done.
I'd suggest a good point for you is to actually read the Scrum Guide. It has the following to say about the make up of development teams:
Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there
are no exceptions to this rule;
Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business
analysis; there are no exceptions to this rule; and,
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as
a whole.
As an aside, I have some experience working in an embedded system with Agile methods and we had great success using automated testing to replace manual testers. Our testers, pretty much because responsible just for running the test suite on various hardware, physically running the tests. We even had the tests fully built into the production process; every new piece of hardware went through (a subset of) our test suite straight off the assembly line!
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 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.