8

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?

  • This is a very broad question, you might want to state in wich direction you are asking. Or formulate a spezific problem you are facing. I don't know about any books, but the internet is full of success and mistake stories conserning agile: (google search results in 240.000 hits bit.ly/GFMPNb) – Huibert Gill Mar 22 '12 at 12:43
  • 1
    Although I tend to agree that the question is too broad, I believe knowing some books about the topic still might add value for Agile / Scrum newbies. – Tiago Cardoso Mar 22 '12 at 14:36
13

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:

The Durrant Test.

Similar to Joel but for all jobs!

To the company in question:

Summary:

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?

Details:

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.

  • 1
    Unlike the Joel test, this test isn't specific and measurable. The Joel consists only of facts, while this test gives room for possible bias by talking about "actively making progress", a "good production process" ,or "being organized". People can have different opinions on these. If these are fixed, it would be a rather useful test. – ONOZ Apr 17 '12 at 8:51
  • Updated to try and address some of these issues. – Michael Durrant Apr 26 '13 at 23:44
1

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.

1

This books addresses Agile and Scrum adoption mistakes. Agile Adoption Mistakes You Must Avoid http://amzn.to/GAjml8

1

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/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.