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).
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
My team is making the transition to Scrum.
I am facing an issue I still not found on the various Scrum resources I've been studying: how to manage training?
I express myself by example:
my team has 4 developers, 2 of them know nothing about Test Driven Development
the project must be done using TDD
Should I create a backlog item "Study TDD" and use the first sprints so that the untrained developers learn TDD?
Or should I remove the developers from the project until they completed the training? Which is the best practice in this case?
Just send them to the training, and continue your sprints as normal. While they are in training they won't contribute to the velocity, the same as if they were sick or on vacation or just having a bad day. The velocity isn't a goal so much it's an indicator.
You can create a story for training if you want, but it isn't necessary. If creating the story helps, by all means do it. Don't do it just because you think you're supposed to. I've been on teams that liked to track non-product tasks, and teams that didn't. Do what your team decides to do.
In your question you wrote:
the project must be done using TDD
I hope that's because the team decided that, and it wasn't something that was decided for them. The whole point of scrum is to build a team that can make these decisions for themselves.
Well, I will answer YES.
you need to create back log
you need to define test cases and follow TDD
you need to do stand-up meetings and daily follow up
you need to define a team member as scrum master who have best understanding
further, you can engage an online training of transformation expert
Like, I know these guys regarding Agile/Scrum Transformation. http://sparklegenius.com/solutions/agile-transformation/
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 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 5 years ago.
Improve this question
We develop products and want to use SCRUM for development. We start with business case, high-level business analysis and technical outline that all contribute to and form the backlog items.
So after a month or so, we have the high-level features captured in the product backlog, keeping in mind it might change. So now we should decide on the team...how should I do that? How to tell whether 2 or 6 are needed, what is the best practice?
Usually SCRUM goes like this:
Depending upon the backlog and complexity of tasks a development team of 4-8 individuals is created which typically includes designer, architect, developer, tester and a scrum master (tasks like: analysis, design, development, review, testing & technical documentation).
You can decide on sprint cycle's length including a separate planning period
In planning period you assign tasks to individuals and the effort estimates based on availability of resources and time
After planning, you track the progress of tasks and update your backlog list accordingly
As SCRUM is supposed to be self organized, there are times when you might need some interaction from project managers or domain experts.
After each sprint cycle, ideally there should be some dedicated time for sprint analysis which can give inputs to next planning phase.
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.
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 9 years ago.
Improve this question
How many people actually write an SDD document before writing a single line of code?
How do you handle large CSCI's?
What standard do you use for SDD content?
What tailoring have you done?
I certainly have. Historically and on recent projects.
Years ago I worked in organisations where templates were everything.
Then I worked other places where the templates were looser or non-existent or didn't fit the projects I was working on.
Now the content of the software design is pretty much governed by what I need to describe to get the idea across to the audience.
"before writing a single line of code" there wouldn't be a a lot of detail. The documents I produce before I start coding are meant to get the idea of what we need to build across to the affected teams and senior management so they introduce high level architecture, functionality, technologies, risks and scope. Those last two are really important. The rest is to show other teams where you need to interface with them and to leave managers with a lingering notion that cool stuff is happening.
Most big software companies have their own practices. For example Motorola has detailed documentation for every aspect of software development process. There are standard templates for each type of documents. Having strict standards allows effectively maintain huge number of documents and integrate it with different tools. Each document obtains tracking number from special document-tracking system. They even have system (last time I seen it was in stage of early development) for automatically requirements tracking - you can say which line of code relate to given requirement\design guideline.
I would suppose that most people who write SDD documents and use terminology like CSCI have to be using a specific software development methodology and most likely are working for some serious government customer. They usually tend to take their preparations quite seriously and the documents are ready and approved before any development starts.
In an Agile process the development and the design document could be developed in parallel. It means that there will be plenty of refactoring to be done but it usually delivers very good results in the end.
In more formal processes (like RUP) a SAD document is mostly created during the elaboration/prototyping phase based on the team research.