List of agile best practices [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

I am trying to define which agile practices we are going to use, and I am having difficulty defining the list of agile best practices. I would like my list to be more from a technical point of view (the engineer's angle of view), and should define how SW engineers should approach the development. The list should be related to the management as least as possible.

If it matters, we are programming in c++.

It is fairly easy finding lots of best practices, and this is the list I managed to form so far :

1. Refactoring
2. Small release cycles
3. Coding standard
4. Collective ownership
5. System metaphor
6. Planing game
7. Whole team
8. Scrum daily meetings
9. P开发者_如何学运维air programming
10. Test Driven Design
11. Behaviour driven development
12. Continuous integration
13. Code and design reviews
14. Active stakeholders
15. Document late
16. Extensive use of design patterns

We are already using some of the practices from the list. Some we are not going to use.

Are there good agile practices that I could add to the list?

PS I can add a small description of the practices, if requested.

EDIT

As I said, we are already using some agile practices (mostly the practices that proves to be the best) :

1. Continuous integration - this is very good practice. Getting the fast feedback on the latest check-ins is very useful. Having a down time because someone broke a build can be very frustrating, especially if it last longer.
2. System metaphor - it helps little, because having descriptive class and function names helps understand the code better
3. Code standard - we created the coding standard before getting into the coding. Using uniform code style is good, because anyone can take another's code and work on it like on it's own.
4. TDD - before started coding, we set up the environment to easy create unit tests, but only until recently we started adopting the TDD principles. I personally tried it several years ago, and it didn't go so well, but now I love it. Unfortunately, not all team members are doing it - only half team.
5. Scrum daily meetings - we tried daily meetings and they didn't go so well. As well as on my previous job, daily meetings usually turns into 30+ minutes discussions. I guess we missed good scrum master (or leader, how is it called?)
6. Refactoring - we did refactoring, but only if someone from the team creates a change request. We didn't do it like on purpose : "Lets sit now, and reduce our technical debt".
7. Small release cycles - right now we have huge release cycles (6 months), and for next release we are planing to break the cycle into 4-6 inner releases.
8. Code and design reviews - we did the initial design review (like 5 years ago), and few designs reviews of some minor sub-components during this period. We did code reviews of some classes
9. Document late - we did it for this release. Only required documentation means writing documentation less and more fun coding. Developers are loving it :)
10. Use of design patterns - we are already using design patterns where appropriate.

Because of the structure of our organization we can not use other practices, but as you can see the list is long, and you can not pick everything. Also, now we are only 4 SW developers, each maintaining approximately 80 kLOC and working on new stuff. Therefore we can not do for example pair programming, or collective ownership.

---

First, go read the Twelve Principles of Agile Software.

Second, figure out from what you know how to achieve the principles that are most important to you.

People constantly make the mistake of expecting Agile development to be a Silver Bullet or a rigorous set of processes that you need to adhere to that will make your software development successful.

That's not what it's meant to be. The fact that you already have a list of 15 "Best Practices" scares me a little. Don't take it too seriously and don't over-think it. If you find that you missed something...get it in the next iteration.

---

This text summarizes all agile best practices (with links) :
Requirements
- Product Vision / Vision Statement
- Product Backlog
- User Stories
- Use Cases
- Usage Scenarios
- Personas
- Planning Poker
Requirement Prioritization
Design
- Architectural Spikes / Spike Solutions
- Domain Driven Design
- Emergent Design / Evolutionary Design
- CRC Cards
- Design by Contract
- System Metaphor
Construction
- Coding Style / Coding Guidelines / Coding Standard
- Test Driven Development
- Behavior Driven Development
- Pair-Programming / Pairing
- Refactoring
- Collective Code Ownership
- Daily Builds / Automated Builds / Ten-Minute Builds
- Continuous Integration
- Code Reviews / Peer Reviews
- Software Metrics / Code Metrics & Analysis
- Source Control / Version Control
- Issue Tracking / Bug Tracking
- Configuration Management
- Frequent Delivery / Frequent Releases
Testing - Unit Testing
- Smoke Testing / Build Verification Test
- Integration Testing
- System Testing
- Exploratory Testing
- Test Automation
- Storytesting / Acceptance Criteria / Acceptance Testing
Process
- Timeboxing / Fixed Sprints / Fixed Iteration Length
- Release Planning
- Iteration Planning / Planning Game / Sprint Planning
- Sprint Backlog
- Task Board
- Definition of Done / Done Done
- Daily Stand-up Meeting / Daily Scrum
- Velocity
- Sprint Review / Iteration Demo
- Value Stream Mapping
- Root Cause Analysis / 5 Whys
- Burn Down Charts / Burn Up Charts
- Big Visible Charts / Information Radiators
- Retrospective / Reflection Workshop
Organization
- Small Team
- Cross-Functional Team
- Self-Organizing Team / Scrum Team
- Colocated Team / Sitting Together / Common Workspace
- On-Site Customer / Product Owner
- Scrum Master
- Sustainable Pace
- Move People Around
- Scrum of Scrums

---

I'm in the middle of reading "Succeeding with Agile" right now. In chapter 2, Mike Cohn offers a dire warning against establishing "best practices" of any kind:

"When transitioning to Scrum... collecting best practices is dangerous. Like sirens singing to us from the rocks, best practices tempt us to relax and stop the effort of continuous improvement that is essential to Scrum... Although team members should always look to share with one another their newly discovered good ways of working, they should resist the urge to codify them into a set of best practices..."

He goes on to quote Taiichi Ohno, of Toyota:

"...there is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the 'best you can do', it's all over... [if we establish something as] the best possible way, the motivation for kaizen [continuous incremental improvement] will be gone."

Attribution: Succeeding with Agile: Software Development Using Scrum, Mike Cohn, 2010

---

A couple of things which are really important which you could add are:

1. Self Managed Teams - referring to "The best architectures, requirements, and designs emerge from self-organizing teams"

2. Retrospectives - referring to "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly"

3. Simple Design Solutions which minimize work done

---

Making a list of best practices seems like BDUF for an agile transition. If you want to be agile, try getting there in an agile fashion.

What's the worst problem with your current process? What can you change to address that problem? Try it and see how it works.

Rinse and repeat.

And do all of this as a team.

EDIT:

Some things are hard to put sensibly in comments, so I'll expand on some of the commentary here:

I think the problem is that some people refuses to write unit tests, but in my opinion, unit tests are providing bigger safe net. Not sure what can be done about that.

Poor test coverage is really a negatively stated solution and not an actual problem.

If you have bad test coverage, then you're likely delivering software with bugs or where it's difficult and time-consuming to make changes without introducing bugs. These are problems.

If people are refusing to write tests, either they don't believe there's a problem, they don't believe writing unit tests will solve it, or they don't care.

The best thing to do about this is to get together with your team and decide what the problems are and agree on things to try to improve.

If you have team members who aren't interested in improving, that's a bigger problem. You should still try to address it as a whole team, but it's difficult and you may need some management help.

As I already mentioned, we are already successfully using some agile practices, but maybe there are new and better ways of doing things. What I am trying to do is to re-evaluate how we are doing things.

Good. That's basically what I'm suggesting you should do, but do it as a team and focus on solving identified problems instead of trying to make a big list of best practices.

---

I believe your list is fairly complete. You could add "clear and fixed scope for each iteration", as that's I have often seen problems with in practice - though one could argue that it's just part of "small release cycles".

Also, I would list "small release cycles" and "refactoring" as separate points - they are fairly independent.

At any rate, I would not overly worry about "missing" part of agile. One important property of agile methods is that they are not all-or-nothing - you can start with a part that works well for you, then ramp up. Some practices do depend on each other (e.g. refactoring and collective code ownership), but most can be used independently.

---

A few other ideas to add, though some may be implicit from other practices you have:

• Burn down charts
• Story boards
• Sprint Review
• Product Backlog

Remember that each may be customized in its own way and this is an important aspect as it isn't necessarily a good thing to get too religious about following a practice if it isn't useful for your situation.

---

Sprint Reviews are different from Sprint Retrospectives, at least to my mind. The Review is where what was finished in the sprint is shown to others, typically stakeholders, to get feedback and update the product backlog with new items that may come from seeing the product. The Retrospective is where the team meets to discuss what went well and what can be improved for the next sprint which is slightly different to my mind.

---

Scrums every given time period (daily, weekly, etc) and the sprints that occur as a result.

Not obscure, but worth a link to an explanation anyways.

---

"Agile" or "Agile Software Development" isn't a single method. It's an umbrella term covering just a collection of "values" that you might choose to hold. Two different methods can both be "agile" and yet conflict with each other when it comes to practices you should or should not do.

There isn't a clear cut definition of "agile" - so it's not possible to make a definitive list of "agile practices".

There is a definitive list of the basic Extreme Programming Practices (i.e. the things you have to do to meet the basic definition of "doing XP".)

There is also a minimum number of things you have to do to be doing Scrum (although that's not so useful because it says absolutely nothing at all about specific engineering practices.)