Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
From doing Agile and Scrum are there any lessons you can pass on from your experiences?
Are there any approaches that work better than others?
Which of the many parts of the theories have you found the most important in real-world situations?
Are there any good books, tutorials, videos, guides, etc. available on common Scrum/Agile mistakes, lessons learned and best practices?
The most common mistakes with Agile are:
Using it to try to 'push' development faster in the short term.
Thinking of Agile as 'quicker' rather than 'more nimble' and 'better'.
Focusing too much on the technique(s) and not the reason for doing them.
Not getting key long-term estimation benefits by failing to look at velocity.
Not using good tools that support the processes such as Pivotal Tracker, Trello or Trac, etc.
The most common mistakes with Scrum are:
Not being consistent with the approach of same time, say day, same place.
A lack of longer meetings to complement Scrum and provide analysis for bigger picture reviews.
Forcing developers who are less comfortable in a group setting to be in one.
Suggesting quick solutions that lack analysis.
Senior developers dominating discussions, intimidating junior members.
Also I present:
Similar to Joel but for all jobs!
1. Are you well organized?
2. Do you have good production processes?
3. Are you actively making progress in my area?
4. Do you track defects?
5. Do you fix issues before making new ones?
6. Do you update a shared calendar?
7. Do you document needs?
8. Do you value focus?
9. Do you value good tools?
10. Do you test your ideas and practices?
11. Do new candidates do actual job tasks?
12. Do you share information freely internally?
13. Do you have retrospectives?
14. Are your scrums short and on-time?
1. Are you organized?
Do you have one system for stories and features (Microsoft Project), another for tracking bugs (Trello), another for tracking releases (a good doc spreadsheet) ? All these systems might be good, but the multiplicity of them is not good and it would be better for everyone to use one system, e.g. Trello or Pivotal Tracker (which is my favorite). Other items: Is an online shared calendar used by everyone? Are file shares and directories set up with good names and do they avoid duplicity of data? Does everyone know where to find the wireframes, the requirements and other important documents.
2. Do you have good production processes?
Are your production processes well documented? Have the documents been compiled by multiple parties and also reviewed by others? Are roles and responsibilities clearly spelled out? Do you have documented procedures for emergency situations?
3. Are you making demonstrable progress in my area?
For the area that you'll be working in, the progress being made currently? How fast is that progress and are there any major issues? What evidence of the of progress can be shown in the project tracking system, recent releases, dates of recent changes, etc.
4. Do you track defects?
Do you encourage everyone to enter defects in a commonly used system. Does the company base performance metrics on the number of bugs entered / resolved? This can be very counter-productive.
5. Do you fix issues before making new ones?
How large is the current list of bugs? How long have items been there? Is the list growing or shrinking and at what rate?
6. Do you update a shared calendar?
As with other tools this makes co-ordination easier.
7. Do you document needs?
Even in an Agile environment you can still benefit from documenting requirements.
8. Do you value focus?
Do developers have the ability to work in quiet and isolation in order to be able to be productive?
9. Do you value good tools?
What tools has the company spent $ on. What machines? What screens?
10. Do you test your ideas and practices?
Does the company do prototypes and get input from industry experts?
11. Do new candidates do actual job tasks?
Are candidates asked to do tasks during interviews that they would actually be doing in the course of their everyday job?
12. Do you share information freely internally?
Is it an open culture?
13. Do you have retrospectives?
This is an incredibly important part of Agile, taking time to review what you've recently done and what worked well and what didn't.
14. Are your scrums short and on-time?
It helps to be rigorous and start on-time, not 5 or 10 or 15 minutes late. It's also important to be done in no more than 5 or 10 minutes. Any detail or extended discussion should be taken 'off-line' and done after scrum is over.
The most common mistake is that organizations want Agile to change their business, and the goal is not a better product, but a successful transition. And it is wrong.
It's like training a soccer team to pass a lot and possess the ball. They may have a lucky victory, but in general they'll play nice, but loose: their goal is to pass and posses not to score. On the other hand if a team is trained to score goals, they most probably going to win, and in order to do that they have to pass and posses the ball.
This books addresses Agile and Scrum adoption mistakes. Agile Adoption Mistakes You Must Avoid http://amzn.to/GAjml8
The biggest problem I've seen with Scrum in general is that its treated as the least agile of all the agile methodologies. People adopting it tend to like it because it has a lot of rules, and they feel comfortable with that as it's the same as the old systems they're trying to get away from. You see, agile is about what works for you and your team and the kind of work you're doing. There are no descriptions that are perfect for this combination, the best you're going to get is examples of what worked for other teams.
So, remember to always follow the Agile Manifesto and think of all the methodologies as guidelines, ones that can and should be broken if you feel like it. Never treat them as fixed-in-stone sets of rules that you must follow.
A good guide to see if you're falling into the old traps is to remember the half-arsed agile manifesto. See yourself following these babies and you know you're doing it wrong/
