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
How do you deliver Potentially Shippable Code at the conclusion of each sprint when the broader project spans multiple sprints?
As Sklivvz said, your question is not very clear, but you mention in one of the comments:
However, if a project comprises of multiple stories that only make sense as a unit and are too numerous to deliver across a single sprint, then how does that work?
Stories should follow INVEST.
The I in INVEST stands for Independent which means that your stories should not have dependencies between sprints. You should break them down smaller enough so that they can be developed within a sprint.
Potentially Shippable, does not mean you have to ship, but the product owner can always have the choice to ship. For example, if the product you are developing does not meet the features of a Minimum Viable Product then your product manager might not want to ship. However, it is better to release early (and often) so that users can give feedback about the features. Perhaps the initial set of users are internal to your company or from friendly customer.
It's not clear to me why not!
The idea of agile is that your project has variable scope but pre-determined timings. So you time box everything and make sure that at each time box things are either finished or excluded.
In this sense, you have shippable code at every time box boundary (iteration). If your units of work (stories) span multiple boxes, then your team will make no progress until they can ship any unit. Of course, for this precise reason your stories need to be as small as possible.
A project can run for any number of iterations, until there's valuable things to do.
In other words, an agile project must have variable scope and by definition it should be possible to wrap it up at every iteration.
It can be delivered by being deployed on staging environments for customers to play with, or it can be delivered by being packaged into an installer which allows for it to be deployed on any location desired.
It would need to include any changes needed in such environments - such as new config files, db schema changes etc. These should be bundled as part of the deploy package (as manual steps, or better automated steps).
Of course - there is no one answer. Determine with the other members of your team (remember that this includes DEV, QA, Business and 'Customers') in this project what it means to deliver this /Potentially Shippable Code/ to your team. Then deliver it that way. Then discuss how that worked out. Then improve upon it.
Do time-boxed experiments, reflect on what happened, adapt/improve and determine another experiment. That is, IMNSHO, 'Agile'.
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 3 years ago.
Improve this question
I have friends who have asked me to make websites and most are very small, usually I don't bother with a technical plan but one friend in particular clearly had goals larger than my own and the project is dragging on forever. If I had made a spec before the project I feel like this wouldn't have happened and our relationship would be as solid as before.
So my question is, how can you tell how small is too small? How do you tell when the project you're embarking on is going to end up in a guilt-ridden scope creep nightmare?
If you are going to be charging money (or don't want to be stuck doing the project forever), a project plan is always a good idea. Even if it's just a one-pager outlining what the web site will have (how many pages, any special features) and who is responsible for what. You should factor in that you'll spend 20% of your time (or whatever percentage past experience has taught you) on documentation or non-coding type work, you can give a better estimate of the effort needed. If it's a friend, you might want to tell them that you'll do the first X hours for free, but after that your rate is $Y per hour. Also, keep an accurate log of the time you've spent so that you can show them the amount of effort that is involved. Also, keeping an accurate log helps you estimate future projects.
As you may have already figured out, no project is too small to have at least an informal, written plan. Even if it's just a features list.
A project that does not need a plan is a project that does not need to be even started. In my opinion everything needs a plan, what changes is the extent of that plan. A plan could be just a list of deliverables and some deadline attached to each one. A more robust plan should include time charts, cost, phases, communications howto, dependencies, etc. So I think everything needs a plan, the contents of the plan is what changes depending on the project complexity.
Dwight Eisenhower on planning:
In preparing for battle I have always
found that plans are useless, but
planning is indispensable.
It seems the same in many software projects: you'll find that your plans need to be continually updated and that your first plan was quite different from what you finally completed. But that's okay, it's much better to put some planning in up front than to try something by the seat of your pants.
Agilists try to accommodate such changes in plans by breaking longer term plans into small "sprints" of 2-4 weeks. They'll have more details on the near term sprints, and fewer details on the longer term goals.
You'll especially want to be more detailed and precise if the project is bigger, if you are doing this for an external customer, or if you're attempting something new for you. It's less important (though not unimportant) for smaller projects and types of work you've done before and are very familiar with.
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 12 years ago.
Improve this question
You work on an important project that contains 7 independent modules, and you do not have enough time to finish the project in time. In front of you is a choice: to complete 3 modules in full or to start work on all the 7 modules in parallel, but not complete any of them within the planned period. Which strategy you choose?
Explain the situation to the manager, let him decide. That's why he's there.
If you're in charge, then you need to consider all possibilities. I'd say, focus on what the customer will need in the first turn, and complete the second-priority functionality afterward. If possible, talk to them, explain and try to reach an agreement. The customer may have a different opinion on what he will need the most and give you direction to focus your efforts in.
Whichever is better for a customer/business. If it's possible to have all 7 "feature" in semi-complete state -- then go for it. If they prefer 3 polished "features", go this way.
It depends on what your customer values.
Are the modules really independent? Are they really needed in full, or can they provide value even if implemented partially?
A useful strategy is to implement vertical slices accross the system or even a module, not horizontal layers of modules. Implement one end-to-end feature/use case/user story at a time. It is these features that bring value to your customer, not modules (unless the customer is an odd one valuing modules and not features). This way you get something useful ready for testing and release, and your time is not spent on writing code that is not used by anyone. However, when adding new features, you need to keep on refactoring the codebase in order to avoid the stovepipe system anti-pattern.
In any case, implementing the 7 modules only halfway there is not the answer. Whatever you do, do it right the first time. ("Right" being of course context-dependent: different standards apply for throwaway prototypes, life-critical production code and everything in between.)
Complete the 3.
Then they can be released for testing to the client, and you can get to work on the other 4.
That very much depends on your development model and the customer requirements. In an agile environment I'd rather show the complete product (even with unfinished/mocked parts), so the customer gets an impression of it in its entirety and can give you early feedback on the unfinished modules.
If there are clear, precise specs however, then delivering the 3 finished modules is probably a better idea.
Client has a clear picture of exactly what he wants, and my job is to show him something that will attract his attention and give me additional time to complete the project.
Each module requires one month of work, but after three months the client decides whether to continue the cooperation or not.
The user interface is the only thing that interests him. I can not explain to him that I spent two months making engine if he does not see it on the screen.
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 4 years ago.
Improve this question
We have a pool of technical resources consisting of some front end developers, back end developers, graphic designers. Those resources are separated from clients directly by one or two account people per client.
Requests from clients come in through the account people and get sent to our synchronization manager. The synchronization manager keeps track of all client projects and has a basic idea of the workload for each resource. His job is to assign work to resources based on priority of the project and the resource's familiarity with the project (to some degree). Currently, the majority of this data/logic is handled in a complex excel spreadsheet. We revisit the schedule every week on Monday so that people have a clear idea of what lies ahead for them.
This type of system works ok for linear projects that have a longer duration, but starts to fail when there are lots of little projects/tasks happening concurrently. Many times, tech resources are "lost" when updates come to the schedule mid week. Not to mention when there are "urgent" requests that supersede the existing schedule.
How do you handle assigning workload when you work with multiple clients on a daily/weekly basis? Is there any software that you recommend to help with scheduling / determining resource availability? Please keep in mind that priorities and projects change frequently, with us not really knowing what is going to happen 1-2 weeks out from the present.
Sounds to me like the classic consulting conundrum: hitting that sweet spot where the fewest resources generate the most revenue.
The first question that comes to my mind is: how much pain is this causing? Grumbling from amongst the developers? Complaints from upper management? Furious clients? The solution should match the level of trouble caused.
The simple fact that you can't know the unknowable when it comes to schedule interruptions means that, in large part, there is no software fix to this problem. You have to build in enough room for those unexpected demands ahead of time and be ready to reassign on the fly.
It also bears mentioning that the seat-of-your-pants model, in which developers jump every time a client says boo, is a choice. It doesn't necessarily have to be that way if everyone is willing to consider other options.
Use an issue tracker such as JIRA
Personally I would take a look at using a Scrum board. This can be accomplished with a physical wall, PowerPoint slides, or Bugzilla.
Try the following:
1. Assign each tech to a cell
2. Assign each tech x amount of job/task give each job/task a priority level.
3. In the slide/wall create your different stages of To Do, Test, Very, Done and have the developers move them across the stages to give greater visibility of the tech and the projects.
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
Given a situation where you have 2 projects that in total will provide enough work for a month for 6 developers in a ratio of 2:1.
Is it better to assign developers to each project and then they work on that project for the whole month or is it preferable for the whole team to work each project in turn?
What reasons do you have for your opinions?
Edit
To clarify, they are entirely separate systems.
It depends a lot on how related the two projects are. If they have a lot of similarities, I would say tackle them as two projects within one large group.
If they mostly unrelated from a code and architecture standpoint, it would make more sense to split into two teams for the duration of the two projects, perhaps cross-training some of the developers as is possible.
If you're an Agile shop, just run two concurrent iterations.
If the projects are in separate systems I believe it is wise to separate the developers working on the projects since humans are not entirely great at multitasking because our context switching skills are slow. So either they work one project after another or split up the team to each project.
The answer to this really depends on a lot of factors. If you're 100% certain that you won't lose a developer, and that no one will go on a long vacation, then splitting it into specific teams has some advantages. OTOH, if you don't know that for sure, it might be better to have the whole team work on each project.
Next, you have to consider deadlines - will running the projects sequentially increase your risk of missing a deadline on either one, and if it does, is that risk acceptable?
Of course, there's always the potential for developers to step on each others' toes. 2 man-months (yes, I know it's a myth) of work split amongst 6 developers is a little over one week's work per person - if that's reasonable for the size of the project, then that's fine. However, there is a limit to the size you can split the work into and still make sense.
Answer those questions for your project, and that should give you a decent answer.
I think that in the case of unrelated projects you will have a far better efficiency if you split your developers across projects. This is because there is overhead in communication, if you double the number of developers on a project you don't half the time it takes.
However if your developers need to learn both systems eventually then this overhead needs to happen at some point. time constraints should dictate whether that occurs during or after the project.
I would split them into 2 teams assuming that there are enough developers to cover each project (Each project gets 3 developers and 3 developers is enough for each project). I don't think it's effective to put more developers on a project than is necessary.
Edit:
This is not taking into account all the many other factors that go into this type of decision (developer productivity, skill, availability)
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.