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
What approach did you take to describe the benefits of SCRUM to clients / business units who do not have a technical background? Please list any analogies you thought were useful. Finally, how did you address the concerns that the Waterfall camp had?
I basically go around about risk reduction and ROI, since these are the main things people at the higher management level care about.
Using a incremental process significantly reduces the risk of wasting money on something that's not gonna be useful, because the customer helps steer the product development in the right direction through series of planned feedback cycles. The #1 reason for project failure according to the CHAOS research is lack of customer involvement. So why not use a process that eliminates that risk?
Also, with a incremental process you start delivering something in a much shorter time than when using a waterfall approach, which effectively increases the ROI (return on investment), since the customer starts benefiting from the product after one or two months, instead of waiting 6 to 12 months in a typical waterfall project.
You can also mention improved customer satisfaction, team self-improvement and self-management, which reduces the administrative overhead, improved employee satisfaction.
An additional point is protection of investment - with traditional approaches, a system typically "ages" with time, its value decreases, and maintenance costs rise until it's no longer feasable to maintain it. With an Agile approach applied well, the code should be maintainable and extensible indefinitely.
Here is a good, short video on all three points: http://www.youtube.com/watch?v=OWvSnYjqOTQ
I would mention the benefits of focus. Because the guiding principle of sprints is functional focus and shipability, all details (e.g. ergonomics) need to be taken care of, whose fixing would otherwise be postponed under pressure in more global approaches. You don't have it all but what you have is solid. Non technical people appreciate that because it reduces risk from their point of view: it injects honesty and trust, together with interactivity, in the dialog with clients.
Related
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
We are a team of 30 people, consisting of business managers, developers and software testers.
Our developers are on different projects that have partially different - partially the same products. They help each other where ever they can. As we are all in the same room this is quite easy.
Now I asked why we do not use Scrum.
One answer I got is: Because we are all in the same room and we are helping each other. This goes quite quick and so we might not need scrum. Some of our products are developed only by 2 people. So this would be kind of weird to have a standup meeting with only two of us. Also our colleagues come to work at different times and some are doing home office sometimes.
Is it true that in such a setting Scrum is not feasible or does not bring any value to the company?
Hope for your comments, ideas, thoughts...
Best,
Marc
As literature states (see here) ideal Teamsize is between 4-8. Smaller Teams should use XP.
My persional Opinion is, yes do scrum, even if you are a single developer!
Scrum is about your customer and team and about the way how they communicate. You always talk about your team. But even more is important how is the communication with the "customer/stakeholder", how is the project management done. If you have a customer involved than have a look at these processes if they are also that good as within your dev team. Most of the problems of softwaredevelopment lay here (requirements specifiction, customer expectations, being in budget/time...)
Some aspects you loose not using scrum (and therefore I would suggest using scrum even in a team of 2). You also have to not pick everything but only theparts you like
Backlog (what is planned in the next x weeks) and its documented!
Burndown Chart (where are we standing at the moment)
Continouus improvements (in Scrum you capture impediments, you reflect what was good and bad..)
Daily Scrum (makes even sense for a single person reflecting what I did and do the next day! and what problems happened.)
Most other apsects of scrum...
I am currently starting to implement/use all this for me as a single person/developer and I can only say it makes my work and me better as a programmer. And I am even saying this, being my own customer and PO (I develop my own products/business for me)! And even than it makes sense. The advantage is, that this is with scrum all extremely lightweight (no overhead).
The Scrum Guide suggests a team size of 3-9 people.
There is a reason for the lower limit. Teams smaller than 3 people have less interaction and may lack the skills to deliver a potentially releasable increment in a sprint. It can be a challenge to keep the Product Owner engaged when you have a very small team.
My personal experience is that 4 people is a more realistic lower limit due to the impact of holidays and other absences on a team.
It is also important that a Scrum team is consistent over time. One of the benefits of the Scrum approach is it lets us calculate the capacity of the team and this is complicated by frequently changing team members.
Team members working from home and having different core hours should not be a major problem when working with Scrum. This is common in a lot of Scrum teams and can be mitigated with careful synchronisation and the use of technologies such as messaging applications and voice/video conferencing.
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 2 years ago.
Improve this question
I am Computer Science student, but there is no particular provision or course for learning game programming in our college. I have been studying allegro API for the past year. But I am still unsure how to apply physics in games and realistic games. Its overwhelming and lack of resources is quite confusing.
I think the best thing you can do at this point is simply start making games. They may not be complex or realistic, but getting some experience under your belt will set the stage for learning more complex things. I would disagree that there is a "lack of resources", a plethora of advanced game development tutorials are a web search away. I think the problem here is more related to those resources seeming "overwhelming", as you said.
If your experience studying computer science is anything like mine was, you likely spend a lot of time studying relative to a small amount of time actually doing. Use your interest in game development to get practical experience doing something that interests you. The important thing here is to complete games. When working on simple games, its easy to stop as soon as the bare minimum feature set is completed (I've got a paddle and a bouncing ball -- my pong game is complete!). Take the time to create a title screen, add sounds and music, can work out bugs.
As you gain confidence making smaller games, you'll have a better basis for learning more advanced concepts. It's not a matter of being 'smart' enough to understand complex tutorials, its a matter of being able to retain and absorb that knowledge because you are able to immediately apply it. College computer science teaches a ton of knowledge, but, at least in my experience, a large portion went to waste because I wasn't regularly applying it.
The bottom line is: just develop things. Make games. Even the ones that seem simple will end up being more complex that you expected, and as you progress you will gradually assimilate more advanced knowledge. Look up advanced concepts as you need them, not because you anticipate needing them.
That being said, here are a smattering of tutorials I really like:
Entity Component Framework
Programming Game AI by Example
Procedural Terrain
Collision Detection
Of course, don't try to read these all at once. Read these and similar tutorials as you need them, and in the meanwhile, just keep on developing.
And of course:
Allegro5 Tutorials.
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
Does the product owner actually vote on the size of the story in Scrum or is it just Dev/QA?
I was wondering, because it does not really seem like having the product owner vote is productive.
In "classic" scrum, the team decides on the estimates and commitments of a story without the PO. The story in the backlog is discussed by the team and the PO and then agreed upon by the team.
EDIT : as nuqqsa and xsAce pointed out, the presence of the PO can be helpful during the estimation session, as he can help clarify the exact requirements and thus make the estimation more precise, but he does not take part in the actual estimating.
The Team (Dev/QA in your question, but anyone who's committing to the Team's iteration delivery (designers, documentation writers are some I've seen) comes to a consensus on the size of each story, and the overall size that can fit into the iteration.
Scrum Teams generally use a 2-phase planning meeting; discussing prioritized stories with the PO, estimating them (which may reveal inconsistent understanding by Team members and/or the PO) using a non-timebased unit (story points, t-shirt sizes, etc.), and then when an agreement has been reached about what will fit into the iteration, breaking the stories down into tasks, and estimating them in the 2nd phase. (It's permissible to renegotiate the iteration commitment if there is dissonance between the the 1st and 2nd phase estimates.)
Hopefully, instead of 'voting' (estimate with the most votes wins), the Team is coming to a common consensus of understanding and effort, so that everyone can commit equally. If it comes down to two next-to-each-other-estimates-on-the-scale-being-used that the Team can't come to a complete consensus on, the larger one wins.
There is an inherent conflict-of-interest with the PO participating in the estimation process. If s/he really thinks the Team's estimate is out-of-whack, then perhaps they do not share the same understanding of what's being asked for, and a few minutes should be spent gaining additional clarity.
Remember the 3Cs of the User Story 'card' -- Card, Conversation, Confirmation. The Card is a promise of a Conversation between the PO and the Team. The PO absolutely needs to be part of that Conversation (can't have it w/o them!), and the PO and Team need to understand and agree upon the Confirmation (acceptance tests) needed.
The Dev/QA decides on the size of story and the associated estimates. Product owner shares the prioritized product backlog with the team and the team decides which items they can complete within the current sprint.
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
Which organisations are best suited for use of Scrum methodology and why?
Scrum is not a development methodology, it is a project management methodology. Scrum is about managing workload and resources, and removing impediments to progress, and surfacing results at regular intervals to the whole team (including stakeholders).
Think to yourself:
could your dev/project teams benefit from a daily or bi-daily catchup meeting?
when you have design or project meetings, do the wrong people hog all the attention?
do you need to draw a distinction between various stake holders in a project?
could your team benefit from an iterative process, where "releases" are done frequently (i.e. every 3 or 4 weeks), and bugs and features are carefully prioritised against each other by the product manager?
The smallest team we have that uses something scrum-alike consists of 3 devellopers (2 full, 1 part-time), the stakeholder and the scrum-master ('secretary'). It works very well and we are planning to switch other small project teams to this method soon.
There are some 'points' you have to keep in mind:
We have the project status in an excel table under revision control, that is updated at least after the very short daily meeting.
The review and planning meeting is scheduled biweekly on a given day and will not be moved until all participants agree.
In all metings we break down the tasks from backloglist to smaller ones of max. 2 days of work, depending on the task type (concept, prototype, product etc). This proved to be the most valuable means to get reliable estimations!
If the stakeholder needs an status update or needs to adjust priorisation he can have a look at the excel table and change it, so even if he's not participating the planning meeting he has enough impact on project devellopment
The most important influence on management style is that you have evidence on what a given change would cost and what you can achieve until a given date (thing of a release date or a fair trade).
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
EDIT TO IMPROVE CLARITY
Scrum suggests that you split your development into a number of sprints. Each sprint being a fixed duration. At the end of each sprint you ask the client if you should release the software. If they say yes, you perform a Release Sprint, during which you do all the tasks that you woud like to do contineously, but are too expensive, such as external user testing, performance load testing and sign off, burning CDs (if relevent), writing user centered documentation and so on
In my current project we have just performend our first release sprint. We found we lost a lot of the advantages of scrum such as the burndown (as a lot of things were fixing minor tweaks or temporaraly removing security from the site so the load testing could happen), a clear goal as to how much work was to be done next etc. Basically the relase tasks were too close to firefighting to be easaly trackable via normal scrum tools.
What methods have other people used for during a release sprint, and what pitfalls did you find that should be avoided?
Actually, I prefer this tool. It does task-tracking, burndowns, burn-ups, and is useful for project notes.
But to answer the question, tracking hours-remaining on a burndown should still work. It'll still tell you whether you're going to get all your release-sprint tasks (bugs/tweaks) done in time for launch. If the answer is "not all of them", then it's time to get the product owner in to do some prioritisation, and kick some of the tasks out of the sprint.
We're using a kanban board with scrum. Each product item is represented by a post-it note on the whiteboard. Its really obvious during the daily standups where everyone is with each of their tasks, and we can see how many tickets we have queued up in the 'pending' area on the board compared to the 'done' area at the other end.
Your goal should be to get to a point where you don't need a release sprint to deploy to production:) But with that said, what are you doing in your release sprint? There are still tasks to be done, but they are even more predictable than developing code. I've never seen a difference in how the burndown/planning works other than it usually involves adding people to the team from ops. That of course can be its own problem. Maybe you could give a quick idea of what a release sprint looks like in your organization.