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
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 3 years ago.
Improve this question
I work with a small team (4 developers) writing firmware and software for our custom hardware. I'm looking into better ways to organise the team and better define processes.
Our Current Setup
Developers are generally working on 2-3 projects at a time.
We have projects that work in an iterative sort of way, where a developer is in regular contact with the customer and features are slowly added and bugs fixed.
We also have projects with fixed delivery dates, and with long lead times, final hardware might appear only a few weeks before delivery. The fixed projects are usually small changes to an existing product or implementation and the work is somehow intermingled.
We are also moving from consulting to products, so we are occasionally adding features that we think will add value, at our own cost.
The Issues
We have a weekly meeting where proportions of time are allotted to each project. "Customer A wants to test feature X next week", so the required time is allotted. "Customer B is having issues with Y, could developer P drive down and take a look?", etc.
When we're busy, these plans are very loosely followed. Issues arise and lower priority stuff gets pushed back. Sometimes, priorities are not clear to developers so there is friction when priorities appear to change. The next week there will be a realisation that we're getting behind on project Z and we all pull-off some long days.
I'm told that this is all quite common for a small start-up in our industry, but I'm just looking for ways to limit the number of "pizza in the office" all-nighters.
Developers are generally working on 2-3 projects at a time.
Multitasking is incredibly inefficient. Switching the brain from one task to another requires time for the gears to change over.
When we're busy, these plans are very loosely followed.
Then why create plans at all?
Is it all possible to dedicate just one developer to one task / product / customer? So developer P is the only one who talks to customer B? (Certainly the developer would need to document exactly what he's doing in case he gets hit by a bus, but he should be recording issues and roadmaps anyway.)
The next week there will be a realisation that we're getting behind on project Z and we all pull-off some long days.
If there had been only one developer on project Z anyway, he wouldn't have been distracted by customer A's problems.
Don't think in terms of a pool of developers serving a pool of customers, think of one developer for a given customer. (This can make vacation planning a little tougher, but if you're constantly pulling all-nighters, you aren't spending enough time away from the office anyhow.)
I'm told that this is all quite common for a small start-up in our industry, but I'm just looking for ways to limit the number of "pizza in the office" all-nighters.
Aren't we all.
"Customer A wants to test feature X next week", so the required time is allotted.
Allotted by whom?
Do you create your own schedules? If not, the only response to management creating a schedule for you is all-nighters.
Realistic non-all-nighter schedules will bother management. Until you can prove that your customers want a better schedule with fewer all-nighters, there isn't much you can do.
The only way to reduce the all-nighters is to get stuff done sooner. But if the hardware doesn't arrive sooner, there isn't much you can do, is there?
Two thoughts: drive quality and improve estimates.
I work in a small software shop that produces a product. The most significant difference between us and other shops of a similar size I've worked in a is full time QA (now more than one). The value this person should bring on day one is not testing until the tests are written out. We use TestLink. There are several reasons for this approach:
Repeating tests to find regression bugs. You change something, what did it break?
Thinking through how to test functionality ahead of time - this is a cheek-by-jowl activity between developer and QA, and if it doesn't hurt, you're probably doing it wrong.
Having someone else test and validate your code is a Good Idea.
Put some structure around you estimation activity. Reuse a format, be it Excel, MS Project or something else (at least do it digitally). Do so, and you'll start to see patterns repeating around what you do building software. Generally speaking include time in your estimates for thinking about it (a.k.a. design), building, testing (QA), fixing and deployment. Also, read McConnell's book Software Estimation, use anything you think is worthwhile from it, it's a great book.
Poor quality means longer development cycles. Most effective step is QA, short of that unit tests. If it were a web app I'd also suggest something like Selenium, but you're dealing with hardware so not sure what can be done. Improving estimates means the ability to attempt forecasting when things will suck, which may not sound like much, but knowing ahead of time can be cathartic.
I suggest you follow the Scrum Framework. Create a Scrum Environment with an enterprise product. Have product Teams working on the features for their own individual products, which is a part of the combined enterprise product. If you have the resources have a production/issues support and infrastructure Scrum Team. If the issues are coming your way too quickly, have the infrastructure Team try following Kanban or Scrumban.
The Scrum Framework in itself will solve most of your problems if adopted properly.
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
The context is as follows: Enterprise software developed without enough direct customer involvement. We did not develop this software for a particular customer but to fill in a market gap. We worked the core requirements with major customers only, more customers jump on now. Mandated deadlines, requirements changing, little time to design. Fun time! :)
We got the first release out of the door. Then we got second release out of the door (luckily in a more organized fashion)
Most problems that the sustaining engineering is facing for both releases are what they call 'design bugs' rather than good old code defects.
In general these 'design bugs' are such that a feature or part of a feature behaves as designed but that behavior is not what some customers want the product to do. It is not that all customers have these problems - each customer is different and what is enough for one is not for the other.
This makes me wonder about several things and I could really use an insight from y'all with more experience.
Here are some esoteric questions:
How much do you think is this a common phenomenon in product lifetime?
How much do you think did the context contribute to this?
What is/was your experience and context?
This is absolutely common that needs differ from client to client and that they want to drive the product in different directions.
There are three options for any given change:
1) You don't do it - they've bought product software, they have to live with the product. I wish Word did somethings different but I paid a couple of hundred pounds for it rather than having a bespoke word processor built from scratch so I have to live with it.
2) You branch the product and have two different versions - as often as not this is the worst thing to do. As a software house your model is dependent on many clients contributing to a common code base. Having multiple versions significantly increases costs (every bug fixed twice, two manuals, etc. etc.) and breaks your business model. Again, if they want bespoke software built exactly to their requirements then they need to pay for that - you don't get bespoke software at package prices.
3) Customisation (potentially as an option / module / configurable setting) - this can work but you really need to think about whether it's the right thing to do for your product. Each extra options massively increases the number of ways in which the code can interact and the number of tests which have to be carried out so there is a significant cost attached. In the enterprise space you will have to accept that clients will make demands in this area but you need to accurately assess the consequences and costs (one off during development and on-going for support) and make sales and management aware of them.
But essentially they all come down to the same thing - product software, even on the enterprise level, is far far cheaper than having an in-house team (or consultancy) build something bespoke. That price advantage comes with a downside - it's that you don't get exactly what you want and that the business needs to flex to the software sometimes.
It's not usually a popular message with clients or with sales but you need to work out which market you're in (product or bespoke) and remember that when making decisions.
In terms of the other two bits of the question - I don't believe the context created it at all. The root of it is that organisations are different. Unless you have all your clients the same, it was always going to be a problem at some point. Maybe it's a bit worse than it might have been but probably less than you think.
My experience in this area: I've been on both sides of the fence. I've been a development and / or project manager commissioning enterprise (and non-enterprise) third party software products (portals, finance systems and travel booking systems) and I've worked for two software houses developing them as a development manager (which is currently what I do).
Enterprise software developed without
enough direct customer involvement
in such cases, this will be a common phenomenon in product lifetime. If the customer is not involved and you don't know what and how he wants things, you'll be up for quite a bit of disappointment when you deliver the product and you find out his reaction.
How much do you think did the context
contribute to this?
I think it's the main cause.
What is/was your experience and
context?
Similar context, up until about half-way across a project's development period, when delivering an intermediary product, I found out that many of the customer's expectations were quite different than what I had in mind. I guess it was a good idea to send something intermediary for approval, this way I had much less to modify than if I were to send a final product that would not meet customer expectations, so I suggest you keep a connection with the customer from time to time, and get him to approve features before you move on to new ones. This way, when the final product is ready, it'll be what the customer has seen and approved step by step all along.
It depends how long-lived the product is: the longer the life-time, the more evolution is possible and/or required.
For example I helped to sustain one software product from 1991 to 2003; and at the end, it was hardly anything like at the beginning:
It started as an assembly TSR for DOS, implementing modem-sharing for small (e.g. lawyers') PC-LANs.
It ended as a distributed service for NT, implementing least-cost fax routing for several telcos.
It was sold throughout this time, several releases per year; it was what customer wanted, but the customers (and their needs) changed over time, as did the underlying O/S, the competition, etc.
This is why you create API's. I've also seen enterprise level applications that allow users to create their own vb/java scripts behind forms and inside reporting tools. Yes, embed a reporting tool writer and don't try to make all of them yourself.
Enterprises are notorious for their desire to have massive amounts of features in every app. Even within the same company, you can get multiple ways of doing the same thing. I their defense, time is money, so when you save a 1000 users a click, it can add up. On the other hand, they also have people with too much time on their hands to think of every possible piece of data they may ever have to track in the entire lifetime of their company and will want them all in your app. They have the money and are set in their ways a lot longer than say a startup.
When you deliver something the customer did not want, you have failed with requirements engineering. Since this is the first stage of software development, and design, coding and testing are based upon it, bugs in the requirements are the most difficult and costly to fix.
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
Currently, my company utilizes agile as its development principal. I was approached by my boss to determine some methodology for determining the amount of work a project manger does on a given project in flight. To be honest, I can't really think of anything fool proof.
I guess the best question is how do we assess how busy, on a day to day basis, a project manager is?
Remember that ANY metrics you can come up with is most likely going to be gamed.
[ Do I get a badge for on-topic link to Joel On Software? :) ]
Having said that, you can try a union of the following approaches:
Developer feedback!!! (e.g. a good PM's feedback would be "I had problems X, Y and Z and he made them disappear"). Not so good for measuring how "busy" a PM is but really good for measuring how effective he/she is.
Volume and rated clarity of project plans (easily gamed)
Rate of change of project plans (easily gamed)
Amount of meetings/meeting time (easily gamed)
Success rates of projects (on timeliness vs. % of features delivered vs. customer satisfaction). Not easily gamed but devil's own work to normalize this across projects.
Timesheets will measure the amount of work in one sense (you can see how their day breaks down and so on) but not I think in the sense you want.
Ultimately I don't believe there is a useful metric for Project Managers in this sense, but I don't think that's an issue.
I think ultimately you should measure project success rather than "busy-ness". After all, why do you care how busy the PM is if they deliver successful projects?
One PM may spend half a day putting together a risk log and mitigation plan which contains 20 risks, another may spend 2 days putting together one which only has 5 risks but none of those numbers are any more useful as a metric than lines of code. The key thing is not how long you spent doing it, how many risks you identified, how big your mitigation plans are, but whether you actually managed risk on the project successfully.
You're better off looking at what a Project Manager is meant to do, which is to deliver projects on-time, to budget and to customer satisfaction (which I'd use as the ultimate measure of quality rather than defects).
After all, do you measure how "busy" the CEO is? Or is he just judged on the profit the company makes?
To do this:
Time - The only way it can really be gamed is by massively padding estimates and plans and this can be minimised by reviewing the plans and estimates and having all relevant parties agree them (developers, PM, client). The other side of this is that the PM must agree to the plan rather than have the implementation date foisted on him or her. You might want to measure this on either the overall implementation or each milestone.
Budget - Measurable but gameble. For most development projects the key thing her is honest timesheets from the developers and the best way to ensure this is to make it so the PM is the PM but not their line manager. That way the developers have someone to fight their corner (a technical director for instance) if they're being pressured to fill in timesheets to keep the budget down. Again the PM should agree the budget, it's not reasonable to expect him to deliver on something he's told you is unreasonable.
Customer satisfaction - Hard to measure so I'd suggest that you keep it simple and go with a straight forward post project review with the account manager and marks out of 10 for communication, delivery and whatever else is important. It is subjective but ultimately so is customer satisfaction.
But a lot of it depends on the company culture. For some organisations the key thing will be billable hours, others developer satisfaction will be part of the mix.
I am trying to understand WHY you have been asked to estimate the amount of work that a project manager does on a project.
At best it is just a request for a rule of thumb, otherwise it indicates that your boss just don't know the first thing about running a project. Even when projects looks very similar there will always be something unique about a project:
The team is not identical (teaching
the new guy the ropes takes time)
The spec might vary just a tiny bit
(and that tiny bit might double the
workload)
Even the season might influence the
outcome
and so on and so forth
Each and every condition on the project might change the workload of the project manager, so it will always be a subjective assessment.
I would suggest you use the same Burn Down and Level of Effort that you use for the developers. A PM's task in an Agile environment is a bit different (and from shop to shop it's different), but the PM should be able to provide a list of tasks, etc. I'm thinking positive and seeing it as your bosses approach to determining how much availability the PM has.
Most project managers equate responsibility with status, so a project manager who has spare capacity is quite likely to volunteer to take on a new responsibility, because it's in his/her own best interest. In all but the most functional organizations it's often better to be visibly overloaded, for that heroic look.
It's more likely to be in the organization's best interest to slightly under load its project managers, so that there is some spare capacity available should something start to go wrong. A project manager might well choose to apply his/her spare capacity in some constructive way in any case. Excessive politicking or other unconstructive activity is a good indicator of someone who could be more constructively deployed. Even on agile projects, workload tends to be uneven across a project cycle - e.g. delivery is often a management-intensive activity - somebody who is continuously heavily loaded probably has too much to do, and may be ignoring or hiding a serious problem.
If the next level of management conducts regular project reviews, pays attention to how many problems are being escalated, whether the project reports correlate with the news from the grapevine, and does some basic estimation on workload projections for each project manager, then the organization should be able to run a reasonably efficient system.
Managers tend to be political and psychological animals. Any methodology that doesn't take that into account is ignoring reality, so a good methodology for this problem is likely to be based more on observed behaviors than on hard numbers.
Excuse me if I am being to purist, but the tag and the question calls for Agile. What would be a project manager in Agile? You might either be trying to asses the work being done by a product owner or a scrum master?
In any case, both roles perform several tasks that are hard to measure, so probably your boss is looking at the wrong picture.
For instance, a scrum master is "The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent". Basically is a coach and a facilitator. Blocking disruptive requests or distractions created by higher levels of management by negotiation or persuasion to follow scrum practices is one of the skills commonly used by scrum masters. Several of these soft skills are hard to measure as "work" since they do not involve working on a computer or producing a report.
I think a the metric that your boss would benefit most from is more related on how effective the team is and how a scrum master is described to facilitate the work of his team-mates. DVK then has a very valid point, the metrics you create can be "gamed", so it is best to trust that your managers are busy if your projects are progressing and your teams are happy and work as a team.
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 9 years ago.
Improve this question
I'm trying to determine some of the markers that indicate a project of limited resources.
In my experience a project becomes a ‘limited resources’ project because someone was desperate to sell a solution to a client. The results is a tight budget, features are culled and SDLC processes are cut to a minimum. These short-cuts are taken so the company has some chance of making a profit or even breaking even.
This is a list of things which I have seen go hand-in-hand with a project of limited resources:
Bare minimum amount of time allotted to QA
Strict bureaucratic process for off-spec work
Change request budget may be small or non-existent
Formalised processes get dropped in favour of using time for development
No time available for value-add QA like content checking (e.g. grammar or spelling errors in text).
Can’t do any content management or data entry for client
Have to go for ‘good enough’ coding solutions
No time allowance for hallway usability testing.
no budget for writing user documentation or manuals.
Generally no time for technology research before coding
No time to produce a risk analysis document
A production check-list may be used instead of a project schedule.
The is no time for a programmer to fill their ‘actual’ times vs. estimated times in the project schedule.
Progress updates given to clients may be less frequent or very basic
Less time is available to spend on understanding the clients business domain
Programmers may have to work unpaid overtime.
No time allotted for a project post-mortem
What other sure signs are there for a limited resources project?
===
EDIT
i will try clear up some of the confusion with an example. this is what i mean: the client is given a proposal/quote saying their project will cost $20k. the client then comes back and says "sorry, my budget is $16k maximum". the boss says "make the proposal $16k - we want this work".
so, effectively, you have to do a project with less budget then it should have. there are boundaries where it becomes ridiculous - if the client was to say "my budget is $4k" then you couldnt possibly do it.
and yes, sometimes a tight budget can become so silly that it was a bad business decision to accept the project in the first place (i.e. doomed project).
i understand that there is no such thing as a project with unlimited budget. often business people make the decision whether a project should be undertaken (a business person often isnt a project manager).
What you are talking about is not a 'limited resources' project, but instead a rushed and unplanned project.
A few items in your list I take issue with:
Strict bureaucratic process for off-spec work
Change request budget may be small or non-existent
Actually, these should be the norm for most projects. Who's requesting and paying for the changes, you or the client?
Can’t do any content management or data entry for client
No budget for writing user documentation or manuals.
If that's not part of the contract, why are you doing it?
Have to go for ‘good enough’ coding solutions
At some point, you have to stop at 'good enough', or else you are going to be polishing from now until the end of time.
Something I would add to your list are:
Office supplies become scarce or go under lock and key.
Corporate supplied food/beverages disappear
Down time disappears. 100% of your time on your time sheet must be dedicated to project work.
The printer/photocopier is running full-bore printing other staff member's resumes.
The Boss' door is shut for 90% of the day.
Quite frankly, I've never heard of a project that had unlimited resources. Even the government will put the brakes on something after a while.
So, from a pure logic perspective, all projects have limited resources.
Limited resources? All projects that I know of have limited resources:
time
developers
budget
Outdated or obviously beta documentation which doesn't jive with whatever release of the product on site, or documentation which looks like it's been down through several generations of Xerox copies.
No onsite installation or support. Depending on the size of the system being implemented, a company in good shape might send one or more of their developers to oversee the implementation, whereas a company that's tight might offer phone or email support only in a more "fire and forget" approach.
Continuous occurences of new,
forgotten features, assumed as
"obvious" and "implicit" by the user,
never stated in the requirements,
leading to discussion Bug vs. Change
Request.
Waterfall model adopted instead of an
iterative approach.
Customer protesting on the costs of
fixing, saying something like: "If
you have bugs, it is because you
didn't do your job right", not
accepting the tripple constraint
effects on quality when cutting
time/budget.
Pressure for lower prices for
maintenance and support activities
after project deployment in
production.
Pressure for adopting a fixed-price project (outsourcing) to transfer financial risk together with timeline risk.
"Under-priced projects"
If I understand correctly what you mean, you really are talking about projects where the resources available to the project are not appropriate to achieve the results that were promised to the client.
I can think of four ways for this situation to arise:
Wrong estimates when preparing the project plan
Requirements creep
Reducing the project budget without reducing the project scope
Inadequate resources (staff skills, computer resources, etc.) for the project scope
When people in the project become aware of the situation, they really have two options: cut costs or cut scope. Cutting the scope can be a hard sell and may endanger the project viability, so most of the time people opt for cutting custs, especially since cost can be cut in many ways without atracting the attention from the higher echelons:
Unpaid overtime
Reducing quality
Eliminating documentation
and so forth.
In fact, you may even look good as a project manager when you start cutting costs, since cost containment is one of the project manager's responsibilities! I assume that what you want is to find ways to diagnose an under-funded project. I think that instead of developing an extensive list of symptoms, I would strive to identify a general condition.
In my opinion, there is a general condition that allows to pinpoint an under-funded project. For most projects, staff is the biggest cost - or at least the second biggest cost that can be managed by the project manager. Whenever you find an experienced manager taking measures to reduce staff costs and those measures were not part of the original plan, then you can be sure you have an under-funded project.
Regards,
using the information you guys so kindly contributed i was able to pull it all together and write an article
ill put a link here in case someone in the future is looking for help on the topic:
Surviving An Under-resourced Project
--LM
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
I new to Scrum and while I understand the team concept behind the Sprints, I imagine there still needs to be a guardian for the team who minimizes the interference from Product Owners who are not conversant in software development. What are your successes, and what horror stories have you lived through?
Update:
I am looking for the balance between coding to implement business process vs creating the appropriate architecture for a client. If the product owner is from the business unit there has to be guidance as to what amount of time should be spent on data model, etc.
Definition:
By "out of control" product owner I mean typically some one from the business unit who aggressively sets time frames while having no real technical ability to create that estimate. Typically this person will say: "I need those screens before the next meeting with the Operating Committee next week, so prioritize those work products first. We'll tackle the database after we talk to Operations."
Great answers everyone. Thanks for the good input.
The responsibilities are very clearly defined in Scrum - the Product Owner defines backlog items and prioritizes them, the developers commit on how much they can do in a Sprint.
So, a Product Owner simply has no authority at all to set estimates. Of course he can still say that he needs something to a specific point in time - that simply happens. But it's still the developers who will say whether it can be done. And if it can't, they have to work out together on how to change the scope or whatever else can be done to get the needs of the PO fulfilled as best as possible.
Now, how exactly the SM should act in a situation where this doesn't work smoothly depends a lot on the specific situation. I'd rather see him facilitate a good relationship and communication culture between the PO and the team than have him shield the team from the PO, though.
"there has to be guidance as to what amount of time should be spent on data model, etc."
Right. That's what prioritization is all about. You define the work, you prioritize. You work according to the priorities.
What can get out of control?
Redefining the work before anything gets done?
Redefining the priorities before the work gets done?
The solution is the same. Break the work into smaller pieces so something gets done before there's an opportunity to make a change.
If you have short (2-week) sprints, it's not possible to be out of control. If you go for slightly more practical 4-week sprints, then you have a small chance of getting into trouble.
The product owner is supposed to be the one that shields you from ambiguous or varying customer requirements.
The product owner must not give the estimates.
I don't think it's a question of "out of control".
"I need those screens before the next
meeting with the Operating Committee
next week, so prioritize those work
products first. We'll tackle the
database after we talk to Operations."
There is nothing inherently wrong with that statement by itself. If your app is properly abstracted, then your DB is separate anyway. The main problem with UI first is more psychological: The non-devs will assume that most of the work is done if they see screens and go bonkers when things "slow down". However, here's what I think your real problem could be:
The person you have flagged as a Product Owner is not owning the product, and so isn't taking on enough responsibility.
The product is the whole thing, not just the "functional requirements" (to borrow terminology). Your SM needs to have a sit down and be adamant that the PO needs to not try to push off understanding the scope of the behind the scenes work that needs to be accomplished. Once you're PO starts to look at the entire scope, then they can actually be your representative to the broader stakeholder community.
Ultimately, your SM is the one in charge of enforcing process. They should act like it.
I've used Agile at two different shops, both times it works well. I don't see how an out of control anything can ruin the system. Before the sprint, you plan all the tasks you will do and guesstimate how long they will take (always round up). Then you can figure out approximately how much work can be done during your sprint.
Most shops use 4 week sprints, and 6.5hrs of workable time a day. When a sprint has been set, you don't introduce new tasks and only unplanned work that creeps into a sprint is fixing bugs in the features you are adding, of course that is suppose to be included in your guesstimate time.
If you want a more specific answer, you need to define what you mean by an "out of control" product owner.
I have two things to say.
You probably have some kind of R&D manager (that is not necessarily scrum master) and that is not a product owner).
This guy can and should (I think) "protect" developers.
We were in situation when we had such a guy, and it worked pretty well. He helped us with getting non-functional stuff in the backlog for instance.
Now we don't have this guy. Our manager is scrum master. And he does pretty good job protecting us as well.
Though...the problem here is that generic scrum master has no official power, so he cannot say "you are not going to press them this much", but he of course can and should talk if he sees that teem needs help.
The team itself and product owner also evolve with time so that they start to care more of each other. Product owner understands when the team just does not commit to more or says "we need some time for non-functional stuff now".
But then - again - it's nice of course if there's a separate R&D manager whose main responsibility is taking care of developers...then it will be more balanced I think..
We also have support department which borrows developers for support tasks. Sometimes it is difficult to agree what is going or is not going to be done for this or that customer (because support wants it all).
For this case R&D manager - a very good idea too..
Ideally, I like the idea going completely lean so that developers don't need a manager or shield...but I don't know whether and how it works...:)
I agree with S. Lott. Short sprints are better. Short user stories can help to. We try to limit our user stories to 2 - 4 days max.
Make sure that all your user
stories are well defined and that
the owner in agreement with them.
Once a sprint has started, insist
that new tasks cannot be added to
the current sprint, but they can be
high priority in the next sprint.
Shorter sprints make this much
easier.
Also, in order to remove the
imposition of artificial deadlines,
you really shouldn't deliver items
from the current sprint until the
beginning of the next sprint when
possible.
The hardest part about agile development is discipline. Once you have a disciplined team and scrum master, the users get used to it and things move much smoother. I'm not sure if you use any software for project management, but take a look at Rally. They have made some major improvements over the past year or so.
The iteration (Sprint in Scrum) scope should not be changed during the iteration. That's why only one iteration is planned at a time. As S. Lott pointed out, the shorter the iteration, the sooner the Product Owner will be able to get new things planned.
The Scrum Master role is to isolate the Team from such pressure and shall say to the Product Owner that new requests have to wait for the next iteration.
Now the Product Owner role is to maximize the value of the work the Team produces, so if there is a new top-priority item, which could not wait for the end of the current iteration, it is still possible to replace items with similar estimate and that have not been started.
This should be the exception, not the rule.
Stick with the clearly defined rules of engagement then you(SM) can rather spend the time leading your team.
An agile team is Consist of Developer, Business analyst ,Tester ,DBA ,Scrum master and Product owner.All are working as one feature based team.
Agile methodology is here to help business to accelerate the faster product development. The product owner can define the priority and change the priority of it. Actually, it is a Scrum team ,who estimate it including (SME, Developer ,designer ,tester…. Everyone).Each team member brings a different perspective on the product and the work required to deliver a user story and one sprint comprises with big and small user story. If Scrum team feels that it can't be done within sprint then it needs to be a divide into the small chunk of the user story and estimate based on the stack trace involved to developed it.
i.e. If Product Owner(PO) want the specific user story need to finish first but if that story included the multiple changes (i.e. Frontend and backend including database) and it can't complete in one sprint , Scrum team can follow below key rules:
Key Elements :
Divide into the sub-user story based on stack track
Estimate each user story related to this
Scrum master should Informed the Product Owner about the timeline
to finish this user story based on team current team velocity
Product owner should be mature enough to understand the timeline as it
can't be completed within the sprint.
If Still PO has the problem for priority ,He/she can consult the
Scrum Master/Coach.
At a glance, Agile is more for helping business but need to take care that
it won't overload scrum team . As it is a regular process for
iterative development.