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
Generally, I have learned that stakeholders (in general) are parties interested in the project - development team, testing team, QA team, management, customer (of course) etc.
But now in Scrum, it says that the stakeholders are the ones who validate the product and the product is done for them, based on their needs. That would imply it means just the customer. Is it right or I misunderstood, is a development team really a stakeholder?
http://www.scrumalliance.org/articles/21-contracts-for-implementing-scrum
Stakeholders are parties with an interest in the product being
developed and/or the Scrum process. They might include suppliers,
customers, the business owner, subject matter experts, or product
support.
http://thescrumblog.blogspot.cz/2011/04/stakeholders-and-feedback-in-scrum.html
The Scrum Team:
A lot of people forget that the Scrum team is a major stakeholder for the project
Well,
Tecnically Scrum Development Team is part of stakeholders : like Product Owner or the guy(s) who pay(s) for the project.[ the boss, investors etc]
But the Real Criteria For identifying a StakeHolder is: [ with the danger of over simplification of "happy" and "sad" terms ]
If the project is not succedded who will be "hurt"? Or if project is
succedded, who will be "happy"?
So even end users are stakeholders. :-)
And if investors really does not care success of project [ can such investors exist? well humans are irrational and yes they may exist because of some politics], they are just "stakeholders" on paper not in real.
The definitive guide to Scrum is the Scrum Study Guide. It does not define stakeholders, even though it does use the term stakeholders 4 times in the document.
Scrum Study Guide - http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf
Generally however, a stakeholder is anyone with an interest in the project. This can include investors/board, management, end users, development and anyone else who is either funding, using or building the product.
Frankly I believe you to be misunderstood as you have mangled multiple Scrum roles into your definition of a "stakeholder".
The classic definition of Stakeholders is that they are people with legitimate interests in the project. Stakeholders are NOT always product owners and they should not be confused with a Product Owners role in Scrum.
The product owner, helps define the backlog of the scrum team, sets priorities of units of work and communicates progress to "stake holders". These units of work are first "validated" with the Product Owner, and usually again in a sprint ending demo / wrap up of the iterations work to "stakeholders".
Customers or users are who your're building software for. They can also be considered "stakeholders" however I would not do so. I personally like to keep a clear line drawn between stakeholders of the project "support / sales / business executives / etc" and "customers / users".
If your just getting into Scrum i would highly recommend the following book:
http://www.amazon.ca/User-Stories-Applied-Software-Development/dp/0321205685
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 5 years ago.
Improve this question
Based on this Scrum Sprint description, Sprints are known to be 30 days long, but can be as short as one week. How does this fit with continuous deployment. With CD you release completed stories right after they pass integration.
Is it possible to have a 2 week sprint, but instead of "delivering" the completed stories at the end of the sprint, you just show that they are already delivered? You may have actually released them throughout the sprint.
The problem is that integrating and releasing throughout the sprint doesn't let the team plan out the sprint. It allows management to push the team to release release release, cut corner, and push out code.
At the beginning of the Sprint, the Team needs to come to an agreement with the Product Owner which items they will produce during the Sprint (whatever the length). This happens in the Sprint planning meeting, which is called that for a reason (PLANNING is involved).
During the Sprint, the team delivers the promised items--if they promised to integrate items and put them into prod, that's what they do. There's nothing inherent to Scrum that says when items can or cannot go into prod--it's up to the Team and the Product Owner.
A basic idea in Scrum is that nobody outside the Team (including the Product Owner) is allowed to change which items the Team will work on during a Sprint, once it has started.
If Done means in production, ship it.
Why can the team not plan? They know that shipping is part of the done criteria for any PBI and, as such, the sizing and planning of the Sprint regardless of length should take this into account.
There always exists the chance that management will push for a faster pace at the expense of the team's definition of done, but the team, Scrum Master, and Product Owner (Scrum Team) are obligated to work with management to solve the source of that push.
So here is the result of the discussion on Scrum.org trainer list (so far, I'm sure others will respond). I must say I agree with what was said on the list and find fault in my previous answer as I had forgotten a very important angle on a simple point.
As you might recall though many don't, a Sprint is expected to have an overarching, somewhat fuzzy goal. Many or most, but not all, Product Backlog Items exist in reaching the goal. The easy example I often use is: We want to Increase the Social Networking presence of our application. PBIs may range from showing a Twitter feed, to Liking products, and some Google+ integratione, etc.
The goal gives both a guiding light to why we are building these things, but it also allows the business and team wiggle room in deciding if a sprint was a success if we are unable to complete some of the PBIs. For instance, if we complete the Twitter feed and Facebook Like integration, but unforeseen API stability issues keep us from solving Google+ integration the business may still find success in the sprint because we have in fact "Increased the Social Networking presence" in our app.
This is an easy and natural angle to take as team members, because it gives us an out. Something we are always desperate for by habit in our high pressure environments. The really important angle is from the perspective of the business and I forget this being a coder by trade.
If we ship the Twitter feed when it is done, then ship the Facebook integration when it is done, but then fail on the Google+ integration it may be that the business feels we've missed the mark. Now this is a contrived example, but think of it as something very important like a multi-channel marketing campaign with Sweepstakes, Online games, Text message lottery, etc. Missing one or more of these could mean the business opportunity has passed, because they revolve around the Olympics or something. Businesses do work in this manner.
A continuous flow model might be great, because they see things happening when they never used to, but it's not what Scrum is aiming for which is providing the business with a well oiled machine with a cadence.
Short answer is No. The process model you are describing is more like Kanban than Scrum. With Kanban, the team releases items as soon as they pass through the final stage - in your case this is the Integration stage. With Scrum, the PO has to decide at the end of the sprint whether to release the increment or not. Releasing items mid-sprint is not a best practice in Scrum.
I feel I now understand that Scrum is not agile, in the sense that continuous deployment is core to agile, and Scrum is about a cadence of release points about 1 - 4 weeks part with a product owner that decides at the end of the sprint, not in a continuous mid-sprint manner.
In fact, wikipedia states that "Scrum is ... often seen in agile software development", implying not always, and certainly not synonymous.
I suppose pre-released software development, or non server based software that has a natural release cycle could be agile to the point that CI is done, and still be managed with Scrum.
Scrum is just between Waterfall and Agile, then. Much better then Waterfall, and closer to Agile, but not Agile.
Waterfall: few big long sprints
Scrum: managed smaller sprints
Agile: continuous sprinting
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 lead a team of six programmers, and we are presently implementing a number of agile development practices. I'm very interested in Scrum, however it seems to assume that your project will have multiple developers. Most of my projects are smaller, and involve a single developer. We run 3 or 4 such projects in parrallel at any time.
From reading Schwaber, a lot of the benefit of Scrum seems to derive from teams self-organising to achieve a complex task. If you have a single developer doing all the work, will Scrum deliver much value?
Scrum might be more than you need as a single developer, but if you have a stake holder and a QA person then Scrum can still be helpful. Remember they are apart of your team, and should be at your standups to trade information with the team.
If you are truly alone there are other agile practices that might make more sense to you. For example, Kanban might be a better fit. You don't have iteration overhead, retros, sprint planning, etc. You just have a backlog that you pull tasks from. This works well as a way to organize your work, allows stake holders to adjust priorities, and works well for a single developer or small team where you can break up work without a lot of need to synchronize between developers. Maybe you have a product built that only has small features that doesn't need a lot of architecture being built to support new features. Or lots of small projects that are independent say for advertising firms, etc.
The single most important benefit of Scrum that is there even if there is just one developer is not the daily sync (meeting), but rather the limitation on context switches. While working in sprints this single developer can concentrate on given stories within his (presumably short) sprint knowing he won't be interrupted or pushed to do something else before finishing this.
Less context switching == less waste == more productivity.
BTW - Kanban offers less overhead than Scrum, but it is easier to circumvent and force developer to context switch. This can be a benefit but can easily become a problem too.
I think that the value you may get can come from scrum or other agile concepts.
For example, instead of a weird standup meeting, have the one developer tell you why he has taken x desicion for the y task. You may or may not be able to suggest things (depends on your background as a developer I guess), but the fact that the developer is hearing his own explanation might be useful for finding bugs or dead-end reasonings.
As a professor of mine once commented on asking yourself a question aloud: "If you ask the universe for an answer, it will give you one"
While, as others have pointed out, the daily standup may be weird, there's still value for an individual developer in adopting a scrum-'like' process.
Timeboxed, potentially releasable, iterations and a stack-ranked backlog can only help an individual developer keep focused on actually getting something done instead of endlessly ratholing.
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
What kind of characters can promote the person more likely to be a leader in the team ?
Also, what do you think the responsibilities a leader should have?
It depends on what exactly you mean by "team leader" ;-p
I've seen places where there is a distinct split between the technical lead (who might have more accountability for technical decisions, design issues, the "go to guy" for coding snarls; etc), and the development lead, who is primarily a facilitator, with two main jobs:
resolve any non-coding blockages that arise
act as the main liaison to the client/customer/user-champion/whatever
i.e. anything to preserve those few precious golden hours of coding. They might also do some coding on the side, but that isn't their primary job.
Main skills of a technical lead:
experience of the subject, product, APIs, language, etc
understand impact of changes to the above
ability to make technical decisions
general code problem solving
accountability
good at explaining technical subjects
a "perm"
Main skills of a development lead:
communication
people management
knowledge of the client/etc
time accounting
ability to steer the development focus
Main qualities team members are looking for in programming team leader:
Technologically savvy.
Understanding of business domain.
Available and approachable.
Fair.
Gets along with people (good manners).
Main qualities management looks for in a programming team leader:
Commands respect of the team.
Business savvy.
Gets along with people (good manners).
Loyal to the company and company management.
Trustworthy.
Gets things done.
Gets others getting things done.
Technologically savvy.
Understands software development process.
Main qualities programming team members look for in other programming team members:
Not a jerk (has some manners).
Pulls own weight (reduces entropy, instead of contributing to it).
Not work shy.
Main qualities management looks for in programming team members:
Able to turn cash into working software which is worth more than the amount spent.
Any leader should have following qualities:
He should be technically sound
He should be able to delegate work
He should be able to show the way when people get stuck
He should not very hesitent in trying something new
He should be a good listener, respect other people's opinions and a good conflict resolver
He should be respected by all the team members
In short, the team leader should be the person who can give answers to all persons within and outside the team. (Even though that answer could be: you should ask <name> about that.) Thus, the Team Leader would be a person with good communication skills and enough experience to find the answers he needs. If he lacks technical knowledge, then he should at least know proper sources to quickly find the knowledge he's lacking.
And, of course, read the other answers to see the things he needs but more specified. :-)
Being a Team Leader means you'll be blamed for anything your team does wrong, but then again, you get praise when your team performs above expectations. Unfortunately, it's an ungrateful job since you'll have to deal with many failures (read: bugs in the product) all the time before things finally succeed. Being able to deal with criticism is the most important trait you'll need because you're the most hated person if your team's project is failing. (Because everyone will blame you for this, even your team members.)
But if you can make the team's work a success then WOW! :-)
The leader has better technical or communication skills than the rest of team members.
The responsibilities a leader should have are those that make the team members know what their responsabilities are.
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
We are trying to run SCRUM for a small development team (three and a half developers) working on an on-line application and we are having trouble getting time from non-development resource e.g. product owner, user testing, etc.
I'm working on a business case for getting more non-development resource and for it to be more responsive to our requests for their involvement.
Current situation:
The product owner is a team of 5 people, half of whom are across the Atlantic from the development team (which is better than the previous situation where there was no owner at all)
The product owner "team" only meets, virtually, twice a month
There is no dedicated user testing or QA resource
The fastest time to complete user testing was 3 elapsed weeks, for about 2 man days of testing
We're working to a monthly sprint
Specific questions:
How much time per week should the product owner (if they were a single person) be spending on their product owner role?
Would you expect the product owner to be available "all day every day"?
How much dedicated testing/QA resource would you expect to be available per month?
I've tried Googling for "authoritative" answers, or just any reports on team resource levels, but have not been able to find anything.
Does anyone know of anything like this so my business case won't just be "I think...." but can have references to expert opinion and real world statistics?
How much time per week should the product owner (if they were a single person) be spending on their product owner role?
I would say that about a day per week should be fine on average based on my experience with a team of 15 DEV+QA and one Product Owner.
I would also strongly suggest following the proxy product owner approach, or create a requirements architect (google Dean Leffingwell requirements architect). This is in essence what we did, as our Product Owner didn't have the bandwidth to spend that time on the project.
Would you expect the product owner to be available "all day every day"?
of course thats the ideal. It also helps if there is a proxy that IS co-located.
Without that, I would strongly urge to setup an SLA of time to answer questions related to current+next sprint via EMAIL. e.g. return by end of business day or something.
How much dedicated testing/QA resource would you expect to be available per month?
As answered above, it depends on the type of project and the amount of developers / BAs on the team. I would suggest having at least a 1:1 relation between BAs and testers, on the logic that the amount of QA required is a strong function of the amount of requirements specified.
Since you are talking about an online application, I assume there isn't a very long regression/integration cycle, so a relation of 1:3 to developers can suffice. I see testers as an important influence on the requirements and usability not just bug fixing btw.
Another factor is whether you intend to adopt Agile engineering practices e.g. TDD, Unit Testing, Continuous Integration, etc. If so, the testing resources will be much more focused on test definition, usability, performance/load testing, rather than regression.
One way to see what is the bottleneck is to adopt some sort of Kanban board which visualizes the workflow. On that board you can see where the bottleneck is. Whether its in the PO stuff, development, or testing. If you are using a single scrum team with a regular Task Board Chart, you can easily get this information by adding a column for "In Testing" and "In specification" (so overall you have - Pending -> In specification -> In DEV Progress -> In Testing -> Pending PO Approval -> DONE).
If you see that too many of your sticky notes are stuck in a certain column/stage, you know where to look for a problem. Show this to your management, its empiric and much better than any information/rules of thumb seen in other projects, or at least a very good complement to that...
I doubt you'll find any authorative answers for these questions, as they're almost entirely dependent on a specific situation.
Regarding your questions:
In my experience a product owner may be full time involved on a project, to a brief meeting every few months.
For your type of project, from the details you've given, I would not expect the product owner to be available all day every day, more likely they'll be available for one or two meetings every week or so. (1 hour meetings.)
The amount of testing depends on where the project is, in it's lifecycle, however this may be done by other developers, BA's, projecct managers and users, so it depends on your companies process.
For your size team I would say 1 full time QA resource might be useful.
(Depending on how good your developers are.)
You can't have an owner of a project that's a team, as you're finding it just doens't work. You have a couple of options, my favourite would be to declare independence - they don't want the responsibility of being the owner - you take the responsibility yourself. You clearly understand the problem, try grabbing control, send a few pithy emails outlining the new structure - do NOT ask for permission, just do it that will shake them up a little.
Other answers - you won't get an owner available 24x7, you have to work around the owners schedule, but you can demand to know that schedule in advance.
QA - for 3.5 developers I'd like between .5 to 1 QA people dedicated, I'd expect between 0 and 1, with it being much more likly to be 0, if you can't get a dedicated tester go straight to the users - you are the new owner remember, build a brains trust of early QA users and subvert the organisation.
BTW - answers based on 50+ projects in 20 organisations.
I am a certified SCRUM Master and following is my analysis on your situation:
Points To be notes:
SCRUM does not allow 'a half developer' scenarios, developers should work dedicated on the project on hand.
Multiple product owner is a bad situation to be in. There is a person required to have a clear vision about the project. Are you considering clients as Product owners?
If you are tweaking SCRUM then u are not doing SCRUM and doing SCRUM-BUT.
Suggestive Answers:
How much time per week should the
product owner (if they were a single
person) be spending on their product
owner role?
You can have a proxy product owner within the team who is responsible to drive the product development and create proper communication bridge between original product owners and team.
Ideally product owner should be a dedicated person, but as per your situation some who can decide the tasks(business analyzed clear requirements) to be taken into this sprint, and prepare for the tasks for the next sprint within your given time can suffice.
Would you expect the product owner to
be available "all day every day"?
Not necessarily, but should be present to explain any doubts about tasks by any means of communication.
How much dedicated testing/QA
resource would you expect to be
available per month?
Throughout the whole sprint. In, SCRUM everyone is called as 'developers' and should be present through out the sprint, this in-term increases knowledge sharing and brings up overall team performance.
HTH
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
Considering the vast amount of digitized information sitting in each department of a large organization, is it a worthy goal to refocus information systems development away from linking individual systems and start considering a single infrastructure that aspires to be flexible and extensible enough to meet all the current and future requirements of each department?
For example, sales has a CRM package but would like to integrate with a custom-built system that the legal department uses. Both refer to the product database that is managed by the engineering and business development departments. Business rules across departments abound.
This web of dependencies is messy- so I am wondering if there is any best practice in dealing with this. Is a single "system to rule them all" a practical approach?
Does this type of goal amount to a net positive for the business, or have you experienced net negative effects?
It would obviously be an iterative development process but should some pieces get rolled out without a full spec + implementation, or would it be better to run a parallel system and cut over at a certain time?
I still haven't mentioned the business requirements of the finance department... :)
I've worked on a number of these... at early stages of just trying to get all the players in the same room to actually building out something that was "agreed" upon. No matter what happens, who does it, how it comes about, etc, etc, it's painful.
The problem within an existing organization is that each group - sometimes department, sometimes product team - has developed their own tools and methods for getting the job done. No matter how inefficient or out of date it might be, it's theirs. If you can get these people willing to check out the system, that's a starting point.
The next problem you'll run into is that each team does things a bit differently, has different jargon for the same things, and wants to store/interact with the information a bit differently. While this doesn't seem like a huge thing, it is.
The complexity compounds with each and every group you add to the mix. And if you think "well, I'll start with this group and add more and more groups as I go!", it doesn't quite work that way. Once you launch it with one group (sales?), the other groups will see it as the "sales system" and be adverse to doing it.
Trust me... there are reasons why ERP-type system runs into the 10's of M's... it's not all technical, lots has to deal with the willingness to put up with this crap.
As soon as you can construct a development organization that everyone who has profit-and-loss responsibility can agree will fairly balance everyone's priorities and understand their needs at least as well as the people under their direct control do, and will allocate resources as efficiently and responsively as they can acquire them from elsewhere, then it would make sense. But I'm not holding my breath.
When you have one monolithic big-#$$ mainframe/etc, that becomes more do-able. However, in my experience, I fond that each department has its own priorities, wants and needs. Quite often, they are not compatible with each other. If you try and make these things fit together, you can never get total agreement on the end product, and probably never server your departments to the level they require.
This also leads to a secondary problem where the departments build their own ad hoc systems in secret (probably in MS Access or Excel); that you discover years down the line when the maintainer quits/retires/is_fired, and the department discovers it needs some kind of maintenance.
There's also a timing issue. You now end up with multiple departments waiting on the upgrades for another department before their can get their own. Sorry, F&A - you can't have your tax update until engineering gets their fizz-bang enhancement in, an they are 2 months behind schedule already.
I think it is saner to have multiple systems dedicated to the task at hand. If data needs to flow from one department to another; that's where glue code and interfaces come into play. Or in the worst case situation, you just add it to a humans task list. "Clerk Jane, on Monday, you are going to print report X and send it over to Dept. Y through inter office mail."
In short:
an organisation in a growing market has better things to spend it's money on than this kind of global optimisation of costs
in a stable or contracting market, it's unlikely to be financially viable unless it leads to real savings: i.e. job losses
the people who would lose their job if it succeeds almost certainly have an effective veto over it's success.
Take a look at the concept of Enterprise Architecture, for which multiple frameworks exist in order to solve exactly the issues you mention.