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 3 years ago.
Improve this question
I am starting my deep-dive into agile and had questions on how certain companies promote their releases. I need input on whether the community agrees that monthly release cycles for services is the same, in theory, as waterfall? My reasoning is that if a team bundles up several service changes/features and makes one mass monthly release then it's the same as waterfall. Wouldn't the
"agile way" be to release each change/fix/feature as they are merged?
One of the agile values is responding to change over following a plan.
Note that it doesn't specify that you need to release according to a particular frequency or method. This is because Agile is an approach and is not a framework nor is it a methodology.
One organisation might be able to release monthly and still respond well to change. A lot will depend on the nature of the product and the environment. Another organisations might need to release as soon as a change/fix/feature is ready. Both organisations can still be following the Agile approach.
As an extreme example, imagine a product that is only ever used by its customers at Christmas. There is still value in releasing frequently as the this helps to reduce technical risk, but it might be considered overkill to release every time a new feature is completed.
The original book on Scrum, "Agile Software Development with Scrum," specified monthly sprints. However it and other methods disconnect sprints from releases--that is, development from delivery--by specifying that each sprint creates a "potentially shippable product." The product is supposed to be in a state that could be delivered to customers, but for business reasons the company may not choose to do so. (One reason I have witnessed, by the way, is that the customer only wanted quarterly releases for anything except security patches.)
On the flip side, although this is debated in the Agile community, Continuous Delivery need not be blocked by sprint dates: You could deliver as often as desired, getting acceptance on the fly, and use end-of-sprint ceremonies to show stakeholders everything that was approved and delivered over the sprint.
Speaking as an Agile coach who maintains his waterfall certification (PMP) because waterfall is appropriate for some types of projects, I believe saying Agile is a subset of waterfall is a misperception based on tying deliveries with cycles, which isn't necessary.
Related
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 6 years ago.
Improve this question
For many years I have been involved in projects which are managed by waterfall or V-model frameworks. For a while I am reading about agile methodologies, mainly scrum, and getting opinions about sprints, daily meetings, burndown charts etc. However all the articles I read describe the methodology when everything goes well.
Last week, I was in an interview and not able to answer a bad-case question:
What if you realize that you misunderstood something about your daily
work in a daily morning meeting? Or, you find yourself in a situation that you
don't know the requirement of your daily work, what would you do?
I could only say; I don't know but I would not burn that day out. Maybe to talk to the scrum master and ask to gather the team again?
What should a scrum developer team member do in such a case?
EDIT:
There are many failure scenarios for scrum masters (motivating the team members, communicating with the customer, failure of sprints etc.), but I could not find failure cases for scrum team members.
You talk to whomever you need to talk to in order to figure out what you should be doing. That might be stakeholder, that might be a member of the team who is an expert on that part of the system, it might be someone else, it might be multiple people.
The daily scrum is an opportunity to get people on the same page. It isn't the only time you are allowed to communicate.
Ask for help as soon as he knows that the plan he had for the next 24h is void.
Probably first to a co-team-member, if that doesn't yield the answer the product owner, if that doesn't help a user, stakeholder or anyone else. If you can't get access to a person who can help you, signal the scrum master, as this would be an impediment.
Report on your findings at least at the next daily scrum, but of course you can call, send email, drop a message in slack, update the scrum board way before that.
This isn't a failure, it's getting a better understanding of the real problem. As this often leads to new work being found, the Sprint Backlog is updated with new sprint backlog items to reflect the new reality. If the new understanding jeopardizes the sprint goal, I (the developer) 'd personally call for a quick full-team meeting to adjust strategy.
I'd say this falls under this part of the Scrum Guide:
The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
As new work is required, the Development Team adds it to the Sprint Backlog.
http://scrumguides.org/scrum-guide.html#artifacts-sprintbacklog
In General, Product owner and Team member understand the requirement of particular scrum and task list for that scrum.
1.If one member is facing any issue in understanding the task or
business requirement, you can talk to product owner for more clarification regarding the story/task.
2.If you have understood the task but facing problem in understanding the technical requirement, you should have some quick discussion with another team member after your finding related to the task and fix the blocker of understanding as soon as possible.
3.Report your situation to scrum master if you are not able to make it even after having discussion with team member.
4.have a meeting with multiple members if you still see it a blocker.
Talks and discussion are the solutions for solving any issue in all process including scrum. Scrum is tightly scheduled process, so you have to take quick decision and action to fix understanding blocker.
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
How to move a team from waterfall development model to scrum model? What all are the steps that one need to follow to achieve a smooth transition. What would be the acceptance curve and will it be successful altogether?
First the team needs to want the change, and the business has to support it.
There isn't a set sequence of steps, and success can vary widely, as much depends on your particular situation.
I'd recommend getting Mike Cohn's book Succeeding with Agile, which gives some excellent advice for such a transition.
Though there are many ideas on how to implement scrum within an organization, starting with one team is certainly a consistent thread. So good work on starting that way. From there find someone with experience in implementing agile. A contractor, a colleague, or advice at meetup groups. Here's a link to one I have attended in the DC area - http://groups.google.com/group/dcnova-scrum-user-group
From there, my opinion is to adapt scrum to your team. It's size, it's need for adjustment, etc. Everyone has opinions, but if your team doesn't buy it, it's not worth it. Don't take that as a license to cut things from scrum. Keep the daily standups, the commitment, the retrospectives, the demo (etc), but adjust the size of the sprint, etc.
I recently saw a compelling presentation that advocated implementing pieces of scrum/agile as the team/business was ready. See this gentelman's site for details - http://www.dragile.com/
A big key is to not get lazy - do scrum. And have a high standard. If you're going to go it alone (which can be dangerous) - read your heart out. Read examples, talk to others, go to meetups, etc. Don't let your inexperience in scrum sour your team to it.
Another good link for an example of one team's experience implementing scrum.
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
In my experience with learning to manage a team using agile there are two critical components to making agile/scrum work. I think that Jody's point about not being lazy is really important, with the more free-flowing work pattern of agile it can be easy to succumb to skipping meetings or other such nonsense.
Get a good web based task tracker. This allows developers to login and see what they need to do and will help track progress. I've been very happy with Pivotal Tracker (www.pivotaltracker.com). Of course the tracker is only worthwhile if you actually keep it up to date, which leads me to point two.
Having meetings EVERY day. The daily standup discussed in the scrum and agile books is by far the most important aspect of the routine. Keep the meetings short, do it in the same place at the same time every day. Update the task tracker during this meeting and keep it organized.
Transitioning a team from waterfall can be difficult. Having everyone on the team read about scrum is important. Also, understand that not every aspect of the scrum model will work in your environment. Facilitate an open discussion about what aspects of the model you want to adopt as a team. The more input you get from the team the more buy-in you'll have.
How to move a team from waterfall development model to scrum model ?
Strategizing Phase:
Well, the first step off course is the thought for change. Then comes the buy-in from the Management, and the Product Development Teams.
Release Planning and Virtual Product Discovery:
Ideally, you would start by identifying all stakeholders and identifying all the requirements by using the Agile Release planning method - which is a really lean way of doing Release Planning. You would identify virtual products at this stage if not already identified.
Team Forming and Infrastructure:
Next step would be forming cross functional teams based on what virtual products need to be built. This step can be tough. It may require RE-organization. Cross functional teams mean there will be no requirements gathering team, or software development team, or QA team. You would have to pull a experienced lot of people from each department to form a cross functional team. A Scrum Master and a Product for each team will have to be appointed.
Basic infrastructure will need to be established for the cross functional teams to operate smoothly, without interruption.
Start Sprinting With Team(s):
Start following the Scrum/Agile principles and have them Sprint. Capture various artifacts and use them to inspect and adapt.
WALAH you are Agile!
What all are the steps that one need to follow to achieve a smooth transition. What would be the acceptance curve and will it be successful altogether?
Steps are mentioned above in order. Acceptance curve varies based on how well you execute the steps I mentioned above.
Lastly Yes, off course it will be successful. 100% guaranteed successful.
Kidding, I wish I could guarantee that, but I can't. :)
What I suggest is this - When you read my statement "Yes, off course it will be successful", the hope you might have got, just hold on to that hope and take that first step!
I happened to be a part of a team which was migrating from waterfall to scrum. If the teams large and distributed, I don't think its easy for everyone to migrate to scrum all at once as a change in organization takes certain amount of days/months/years.
Once such approach that you may like to try is Tracer Bullet, although this term is used more in agile world, but you can surely prove your point to get the buy-in and lead by example if you/your team is stuck in the middle of waterfall and scrum and are looking to go nowhere in quick time.
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
I've been working on a CodeIgniter project with a friend of mine for almost a year now. We feel that our development process isn't as effective as we wanted to be, and currently we're not employing any software development methodologies. We're 2 man team, looking to have more people to work with us in the future, but we don't have enough people to start on scrum.
Right now, we're both working on this project on the side, would be nice to know which methodologies are best for us, to get our development going faster and more efficient.
Agile and Scrum won't make you faster or more efficient:
Since you tagged this with agile and scrum, I thought I'd mention this: neither agile nor Scrum has as its goal faster or more efficient development as you ask for in your question. In fact, changing to these approaches involves a significant learning curve, but if practiced well contributes toward very low defect rates, software that meets the customer's needs, and a development process that responds to changing requirements. Used long enough, Scrum can provide good data about roughly how much work a specific team can get done in a period of time.
Still, you might benefit from some practices:
All that said, there are a couple practices that may want to try:
Pair Programming and Test Driven Design (TDD)
Continuous Integration
TDD is not easy to learn, especially on your own. See if you can attend a CodeRetreat or similar event.
If you aren't already using a modern software change management tool (SCM) like Mercurial, git, or subversion, get one and learn how to use it.
Get regular feedback from "customer"
If you don't already know (you didn't say in your post), you might ask yourself who you are making the software for. Can you frequently and regularly demo it to that person and get feedback? Find out what they want next and put those items at the top of the backlog.
Try to make your product incrementally useful
Rather than making big product-wide changes, add small useful amounts of functionality. Your design will drift but if you have sufficient automated tests in place you can refactor as needed.
I'm curious why you say you don't have enough to do some form of scrum?
You're both on the team, one of you can own the process and the other or both of you can be the product owner. You do your daily scrum so you can know what each of you are doing - picking the work from the backlog you agreed to do. And as you add members you'll already have an established practice they can integrate into.
You can work in 2-4 week sprints, do sprint planning,review, and retrospective regardless of the number of members.
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 9 years ago.
Improve this question
I was organizing the team to do parallel development of next version of the product. I grouped the team by
Client specific
Feature specific
Handling the cross-functional issues by assigning that task to specific individual.
Would like to know what other ways project managers/ leads group teams?
It doesn't matter so much how you do your split but there are pitfalls when splitting a development team that you need to be aware of.
The level of integration determines how much risk you have. Separate software products that happen to share some libraries have very little risk. Highly integrated runtime components pose significantly more risk.
The worst possible situation that you can find yourself in is where there is a dependency between teams to deliver a feature but no clear ownership. For example, team A is waiting on team B for a "back end service" but team B argues that the service is complete. Team A says the service does not meet all the requirements. But team B has moved on to new features. And so on....
I've seen this us vs. them attitude literally grinding development to a halt. To combat this behavior, encourage cross team pairing and shared code ownership. Rotate team members from time-to-time. Make sure there is a single responsible person who will make a feature happen end-to-end.
A team dedicated to developing reusable modules usually doesn't work. It because a collection of modules of dubious value and a governance nightmare. The best reusable modules comes from teams who deliver similar features and identify overlap themselves.
We group people by product specific in our organization. Each team writes code for a specific product. When features of a product intersects with another product, sometimes they collaborate on that feature. We do a lot of compartmentalizing, so its possible.
Write plenty of reusable modules. Thats the key.
My organization also does client specific work only for large clients.
I am a firm believer of pair programming, I would team such that one pair would manage and write test cases (tdd) while other one would code it. I would build up a team based on the same theme.
If your product involves more than one technology then, You can group teams techno wise
skillsets
The key is to allow each team to follow the same standards, but be able to work as independently (decoupled) as possible.
If its the same code base across your clients you probably don't want to split the team by client specific needs since it could lead to more overlapping of changes.
If features cross system functional (AR, security, reporting, etc.) areas you probably want to split by functional areas.
Other ways to split teams:
front end (design implementation) and business logic and database/datastorage
new development and maintenance (newer/more jr people on maintenance)
core functionality and addon modules (if component based)
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 11 years ago.
Improve this question
In the course of my career I've noticed that developers working on new functionality are, as a rule, more cheerful than these assigned to troubleshooting and fixing bugs.
Good tips on keeping business support a happy? Organising business support in the way that team's morale isn’t hurt?
If we start with the assumption that the reason for new function developers being happier is that they get to feel proactive or in control and the troubleshooters are reactive and pushed around by the users one answer comes to mind:
Create a model for those doing troubleshooting to fixes to generalise these from point fixes into broad, consistent fixes for a class of problem. This puts them in the situation of creating new code, even if not new functionality, and they get to think a problem through and anticipate and avoid problems rather than playing whack-a-mole.
In fast moving environments it may also be possible to rotate people through the job descriptions by have them follow their feature from new development into fix and realease and hopefully into version 2 of the feature.
Our organisation has a substantial amount of support work and we've got hit with this problem really hard. The motivation on support teams could dropping down exponentially over the time if you don't do it right.
The principles which worked for us were:
Choose the right people. Some people are happier doing new stuff. Some people are actually much more suited to a steady no-nonsense job. It means that you should have two teams - one for development and one for support. Developers only stay on a completed project until they pass their knowledge to the supporters.
Choose the right leader. Good organisation is make or break here. A good leader would help to organise good relationship with the product users and at the same time will care for his team.
Rotate. We try to keep the support people on the project for a period of less then 2 years and then move them to something new. This helps maintaining proper morale and ensure that their skills don't rust.
Relationship with the customer. Make sure that the support team know how valuable they are. The customers/users should occasionally visit the team or the team should go on-site to have a face-to-face session with the users (a friendly dinner or lunch will also help)
I have seen this too.
There are few approaches that I can think of:
1. Give some thought to selection process.
Not everyone have same career aspirations. While some people are always dying to work for the latest technology and challenging projects, there are others who are content at a stable work environment. Picking the person with right KSA (Knowledge, Skills, Attitude) is always central to good person-job match. In this case, you just need to put more stress on the Attitude part.
2. Choose the right lead
Team leads play crucial role in controlling the motivation and morale of the team. There must be an open and frank channel of communication with team lead and upper management. Ideally a person from the senior management should be made the owner of the team in formal organization chart. Team lead should actively try to foster a team-culture that suites the nature of the team.
3. Rewards
Rewards off course are key tool for managing motivational issues. Just make sure the person receiving the rewards understand that the nature of job was also taken into consideration in decision to reward. If this point is not addressed, it is likely that the person will not take this factor into account when perceiving internal equity.
Following Bell's suggestion, consider letting new or junior developers cut their teeth on fixes. Promote them from maintenance to the feature team based on their performance and ability.
Healthy competition is also a good motivator, but it must be managed to remain a positive influence.