Which one is better? The one that works better for the team. That is the entire point of Scrum. Enable your teams to organize around practices and tools that work for them, and stay out of the way.
It really doesn't matter what your Agile coaches like and don't like. Their opinion can be used as a basis in your team, but the bottom line is to use what works....
Should I let them take the test devices home?
For several reasons:
Insurance: company property on company grounds is covered by the companies insurance. Company property in the hands of an employee damaging it after hours on private grounds? Might be insured. Or not. You would need to figure it out.
Availability: If employees come in one morning and ...
Why Agile Practices Generally Favor Face-to-Face Solutions
[A]fter speaking with Agile coaches it appears they don't like this virtual solution because it breaks the real interactions promoted by the Scrum framework.
According to one Wikipedia entry, 2/3 of all communication is non-verbal. In an agile context, this means that in-person interaction ...
Forget what you have and start with a retrospective
There is little point in pushing any tools, process or framework unless people are bought in to their use and the reasons behind their use.
Book a retrospective with the team and talk through issues. Chances are, if you don't think things are working as well as they could be, other people feel the same ...
The point of having scrums is to facilitate intra-team communications. From that point, having a physical board is beneficial because it forces people to be in the same room and communicate face-to-face. Remember that something like 75-80% of communication is composed on non-verbal cues, so if you are trying to do things virtually when you don't have to you ...
The answer mainly depends on whether you have enough phones so that if people are using them outside the office nobody in the office will be searching for a phone (and can't find one because all of them are at home).
So if you have lots of phones, you can allow them to go home, otherwise, you probably want them in the office all the time, unless there are ...
Yes, if they test with it
For a simple reason. You need to test your apps beyond the idealized conditions of your testing lab.
I can't tell you how many Really Bad apps and websites I have used when the app was clearly only tested on the latest hardware, with an all-internal-router gigabit pipe to the servers, and never "in the wild" with cellular data ...
You are definitely in a tough position, and I applaud you on trying to make things better for your group. One thing I'd suggest is that you not try to tackle everything at once. Look at the specific problems you face, decide on which ones to tackle first (maybe based on how easy it is to convince the rest of the team, maybe based on which ones you can get ...
I was managing a team of five developers and we started out with CI using CruiseControl. I am hard-pressed to think of a situation involving more than one developer where it would not be advantageous to do CI. Hudson/Jenkins is a good platform and we later moved to it.
Also, you get A LOT more bang for your buck if you are doing CI against a build system ...
Check your task bar, top right there should be a pull-down menu you can select type of filtering. You will want to filter by "Date Range", you will then be prompted to enter start date and end date of the range.
I don't know how to get to this through the menus.
The Purpose of CI for Project Management
While the question as originally posed isn't really an ideal fit for this site (e.g. it's more about development practice than about managing projects) it is nevertheless a useful question when properly framed.
The Value of Automation to a Project Manager
From a project management perspective, real-world projects ...
In Scrum I have seen physical task boards used for the following:
Holidays and planned absences (can be as simple as post-its with names and dates)
Burn-down or burn-up charts (updated daily)
Team's definition of done
Team's definition of ready
Product roadmap (giving the team a longer-term vision for the product)
Also, the task board doesn't need to be ...
I am a developer of Eylean board tool which offers UI perfection and variety of core features.
Task board, burndown reports, cfd reports, lead/cycle reports, time tracking, excel import/export, fully customisable board to match any process, TFS integration, templates, Outlook integration.
Server/Client based software, so you can deploy ...
These are all excellent ideas. What you need to be careful about is how you present them. Not, for example,
I can't believe you IDIOTS aren't doing source control!
(I'm exaggerating for effect here)
I've read about some organizations that have implemented source control, and they've really been able to save time and money ...
It might be worth just using a physical board initially until you understand what features you might want from a software product (or even whether you really need software).
As far as other tools go, I quite like Agile Zen. You might also want to take a look at Mingle and Rally.
We do this the other way around:
Requirements are handled in confluence (the wiki part of the atlassian suite).
In Jira, for each requirement, one or more Epics/Userstories are created, but only for the next 2 or 3 milestone releases.
Back linking from jira into confluence is done with a simple HTML link (confluence does autolinking if you cut and paste a ...
I've worked on teams using both methods, sometimes at the same time. Others have mentioned the reasons for preferring the real world scrum board being about physical interaction and in-person communication.
Personally, I prefer virtual scrum boards for several reasons.
First, as you mentioned, distributed teams or even simply working from home days. In ...
Don't use any software right now. It will only constrain you.
What you need is:
A large wall
Several packs of 5x7 Post It Notes (Staples or Office
Several packs of regular Post It Notes
A roll of blue painters tape
A butt load of Sharpies and colored markers
**Planning Process- Agile Product Planning Outline
I've shared a detailed white paper ...
You're solving the wrong problem. If the scope is ambiguous and uncertain, then you need to pursue a type of contract consistent with that situation. Do not enter into a contract when no one knows the scope where you share or take fully the cost risk. Simply say no. Enter into a T&M contract, where you can never lose money due to uncertain scope. If ...
In SharePoint 2010 there is a list template called "Project Tasks List". This will then easily synchronise with you MPP file.
But be careful - if you customise your list, not all data types synchronise with MPP properly.
Probably not the answer you were looking for, but -
While I'm sure they may be something out there that incorporates all of those items, I question real usefulness of it. You're talking about a single program or suite that does correspondence, document tracking, scope definition, estimate development, proposal submission, project tracking/gantt charting, ...
Don't be constrained by your tools. If your tool doesn't do what you want, refactor the information you plan to display.
Define Audience Expectations
In order to deliver the right view, you have to decide what's important. Adjust the presented information accordingly.
For example, for an executive meeting, I might choose to provide only major ...
Sticky Note planning will be with us as long as people get up during a meeting and start to draw on white boards without thinking. As long as people wave their hands in meetings. As long as they walk up to the projector screen and point at the slides.
This goes to the same reason hand written notes are the number one recommendation for note taking. Our ...
Cross-Functional Teams, Trust, and Risk Management
There are really a number of issues buried in your question. Let me try to address them sequentially, although the order isn't actually important.
An agile team must be cross-functional, but that doesn't mean that everyone one the team has the same skill set or level of access. As long as the team has all ...
I think the answer to your question is a disagreement with your basic premise: updating tasks with estimated hours is not necessarily a "Scrum best practice."
Part of the point of Scrum is to use accurate and empirical data to provide accurate estimates of the amount of work that can be accomplished. In my experience, the best practice is to use User Story ...
It sounds like you're operating in chaos, with purposeful loose change control. I am not sure a tool or method is the right solution but rather resetting expectations on what you are able to forecast and promise by way of delivery. If you are in constant flux in terms of your timeline and cost accrual against specific projects, there is no way you can ...
TLDR: It's the Product Owner (PO)'s responsibility to communicate the needs for the product to the Development Team in a format that they can use.
I'll address your provided Pros for spreadsheets:
All the specifications are in one place and not scattered along multiple stories.
It's simple enough to make a filter in JIRA that will give you a report of ...
Make a rule for them to ask for it every time and explain why they need a device at home.
This will stop them from making a habit of taking devices home for no reason and will give them an option to do some testing outside of work when necessary.
We can narrow down your question to how to share information?. The fact this piece of information has been found over the internet or somewhere else doesn't matter (as long as the source is properly documented).
Based on it, I believe you already know the answer... that's the basic idea of a Wiki. The most important thing here, however, is not to have a ...