Start with what you can control.  It’s easy to get paralyzed by thinking about how great it would be if everyone else would cooperate by doing xyz.

Congratulations on the books ... that’s great news! My advice would be “Run, don’t walk, run and get a copy of Mike Cohn’s latest book: Succeeding with Agile.” I enjoyed the pre-published PDF’s very much and I’m looking forward to reading the completed book in it’s entirety.

Thanks,
Kane.

Congrats on the books release.  My one most valuable piece of advice is to focus on values and principles of agile rather than the word itself.

Great to see the book published!

Advice: Education is the key to getting the team and the company to volunteer for Agile.  Discuss, teach, learn, study, argue together in a completely transparent way.  Then adopt practices and start doing with the key players transparent about expectations and goals.

Then do it again with the next practice.  And the next.  etc.  Each new adoption and change will come easier and produce more benefit.

Regularly ask the question:

When is the next sprint review.

The majority of teams forget about this key question, and even 2 days before the end of the sprint, people happily code away, while they should be busy validating the product and debug issues.

Mike

My experience is that people on the team need to be open to new ideas.

This is a simple first step, but it’s one that opens a lost of doors.

Quality is not negotiable.

When in doubt, raise the question: am I being kind to myself? The actions of true self-kindness will flow on to benefit the entire team.

Scrum is like a mirror, use it like one and see your product and your team for what it really is, not what you think it is.  It’ll transform the way you think about building anything.

Make the team responsible for drawing the burn-down chart. It will make the team more aware of the sprint progress (or lack thereof).

Think, always think before embrace a practice in your team. I too often see team that use a practice only because they read it on a book.

Congratulation for the book!

My advice would be to just Start, do retrospect to adapt and progress at your own pace. Change takes time in an organization so be patient and motivated.

Glad to hear news about new book about agile!

My suggestion would be to have a good grip on all practices all along project execution.  The practices that are started early in project tend to be dropped (or better would be to say - skipped) at later stages. Teams that start really well tend to give up some practices towards the end of the project and therefore often loose the focus and finally are as successful as they could be. So - be consistent!

my advice: try to build trust in your team-mates!

Adopt and adapt! Don’t get caught up in Agile tools—or even necessarily methodology—when you first adopt it. Instead, adopt the principles of Agile and adapt your process and tools as you go.

My advice would be to adjust agile to the team.
One can’t be blind to how the process works, and communication is key to ensure results.

My advice would be “If you want to succeed with Agile, make sure you as a team and each one of you as a person are committed to continuously improve, starting with yourselves,  as this is the heart of Agile.”

Congratulations on the book!

Congrats!

Advice: Focus on what’s most important: communication, feedback, simplicity and courage. Follow the practices, inspect how you’re doing and adapt to become even better as a team.

Realize that it is a journey.  Understand the core principles and make it work in your environment.

Congrats for the book ! My advice would be : when moving to Agile, don’t spend to much time preparing the move, but rather jump in the water and actually do it. Team will face some issues and fail, but will get a chance to auto-correct, which is at the core of the Agile Idea.

First of all congratulations for the new book
I’m looking forward to read it soon

My advice is:
Don’t be afraid to try.
Focus on delivering value to your clients bringing them close to you
If you fail quickly, that is a signal you are going well
Learn with your mistakes and move on.
A part from that TDD and Continuous Integration will also help a lot

My 2 cents: always ask!
Improving the quality of the communication makes a team agile: the only effective way I know is to ask.
Ask for help, for better understanding, for more details on requirements, for completing the commitments.
Ask to teammates, scrum masters, product owners, stakeholders, customers…. anybody can help you.
Better communication means better understanding that at the end means to be prepared for change.

Congrats for the book!

Advice: You need very good engineering practices in order to be able to be agile: Automated builds, automated tests, collective code ownership, refactoring, and more.  You will not be agile with agile project management alone.

My one most valuable piece of advice:

Don’t say Agile to your customer if he isn’t familiar with that, just try to take advantages from Agile and explain them in a very easy way.

It is not going to be quick, it is not going to be easy. Don’t give up!

When doing retrospectives. Focus on deciding one, and only one action (for improvement) in the following sprint. A action that is easy to confirm the outcome of. Its easier to have one improvement thing to focus on instead of multiple.

Keep your eye on the real goal (the product), don’t let your teams to fiddle too much with the tools instead of doing real work.

My advice:

Be reflective, open and prepared to learn.  Most importantly look at yourself, your behaviour and interaction with the team.  Encourage all the team to reflect.  Use what you learn from reflection to adapt yourself and the team.

You came with nothing, you’ll leave with nothing. Have the most fun of your life, be agile!

Focus on providing value to stakeholders and remember they come in many forms. End Users, Sponsors, Operations, and Fellow Developers are all in this together.  Take small steps and value few small things that stick over massive change effort that dissipate. Create small wins and persist in relentless improvements.
The road is long but well worth the journey, just don’t forget to go with sustainable pace and adore the scenery.

More from the humorous side of life ;)

3. We are the Team.
4. Team is legion.
5. Team does not forgive, The Team does not forget.
6. Team can a be horrible, senseless, uncaring monster.

and not directly scrum, but these come with the iterations:

31. CRUISE CONTROL IS CAPSLOCK FOR COOL.
32. EVEN WITH CRUISE CONTROL YOU STILL HAVE TO STEER.

p.s. Seriously, the interestinmg things that happen when you try to form a team, instead of using command and control patterns on people, was a bummer.

Ask yourself if you’re happy with your current development process.

If you are, go on with it.

If you’re not, you may want to give Agile a try.

Start small and simple. If you feel that something does nod fit into your development cycle, don’t do that, but try to gradually get as much as you can from Agile. Here what I’ve started with:

- Do TDD. I’m putting this first because this alone can reveal a lot of value enclosed in Agile and if you accept and understand this then you’ll accept and understand much easier the other things that forms Agile.

- Keep it simple - Agile does not mean expensive infrastructure and black/whiteboards, high-end CI server, sophisticate IDEs and project management software. You can start with basic tools like large sheets of paper taped on the wall, simplest paper cards, simple editor that you already use. You can start and succeed with things that you already have and love.

- Keep it energized - and because energy comes to an engineer from his/her little successes, I recommend using simple efficient technologies. Stay away from complex technologies that make the developer wait for test to finish, wait to compile, deploy or refresh the page. There is nothing that is killing the developer’s enthusiasm more than that.

- Open up to business people, try to understand them and keep in mind one simple thing: *we build the software to make their life easier*. Even if we build a product that we enjoy building because it seems cool to us, if it doesn’t help people, it’s not worth our effort and time.

- It’s good to know the unfortunate cases when people fail with Agile, but it’s not worth to take them as the starting point, don’t let them discourage you. Just try to understand what that did wrong, or what and *why* did not work for them.

Get to know your scrum colleagues better. Take them out for a beer/coffee.  If If you can forge strong communication links between yourselves it will lead to a smoother process.

As you begin to implement various agile practices, be sure to understand the goal of each, especially as it relates to providing business value. Don’t make the mistake of thinking that blindly following any one methodology will magically fix all your software development woes.

My advice: Don’t believe that everything you read on a single website (or single book!) is right. There’s no universally right or wrong way to do it. Play with it. Poke it. Prod it. Create your own version of ‘scrum’ that works best for you. (Then write a book about it)

My advice:

Don’t take any process related to Agile as given, but rather think on the value it gives to you, your team and your customers. If you don’t see the value, drop it.

My best one bit of advice: “since I cannot give you one bit of advice that will have the impact I want for your Scrum adoption, I recommend that you purchase Mike’s new book” :) Can’t wait to read the final manuscript!

To succeed with Agile you must change your organizational culture. The tools and techniques are important, but most important is a self-organizing team with good people.

Congrats on the book release. My advice would be: be open, embrace new ideas and don’t deny your mistakes but learn from them.

Define success, together as a team.

I love the following simple and wise advice originally from Jom Highsmith:

  1. Start sooner
  2. Build less software

- marc

Congratulations on new book, I’m sure it’s great as previous ones.

My advice is to blur boundaries between developers and testers (this is classic example but applies to all roles) as much as possible. Everyone on the team has to understand that success will come only if people will collaborate without “us and them” mindset.

Congratulations on the release of your book!

My advice:
Don’t bite of more than you can chew. Start small and celebrate your successes sooner rather than later!

Start by sticking with the Agile basics and most importantly keep it simple.
Go with a wall/cards instead of a tool until you have no choice.

Never give up communicating on what is really happening in your project. Even if you don’t agree with choices made, remain respectful and keep making visible what the consequences are when they occur.

Work hard, have a great time doing your work. Play hard, do it with your Team. Jell. Succeed.

Grow slow. Grow strong.

Start with Senior Management buy in, by explaining why and how this relates to them (make it ‘their’ problem too). Without their buy in, you will be running slowly through treacle as Scrum impacts almost all departments on some level, not just Development.

Congratulations on the book Mike.

Congratulations for your new book.

My advice is:

Do not try to follow the agile practices dogmatically. Learn why those practices are useful. Focus on values and principles more than you focus on practices.

Clearly identify the problems that you are trying to solve by adopting Agile and know what success should look like.

“It is not necessary to change. Survival is not mandatory” W. Edwards Deming

My advice would be “pick one practice at a time, master it, and then move to another one and so on. Don’t be afraid of tossing what is not working for you. Agile is more a way of approaching problems than a set of rigid practices”.

Don’t be afraid to try new things daily!

Congrats on the new book Mike!  Looking forward to the read, its on my Christmas wish list ;-)

Ask yourself everyday - how can I best SERVE my team today? (This applies to Product Owners, Scrum Masters and all team members)

Less (points per sprint) is better (than accumulating technical debt).

“Refrain from Agile dogma”

Too often I’ve seen dogma hurt the team & the company attempting to implement Agile. The approach alienates people and often dismisses valid problems that need to be solved within each unique scenario. There are no cookie cutter technology companies, and Agile is not a silver bullet.

Glad to see the book is published!  Huzzah!

My advice would be to continuously experiment with techniques that allow you to make incremental improvements towards the idealism of espoused in the Manifesto’s statements and principles.  Continuously implement, inspect, and adapt; if something doesn’t work, change it or apply something else that does.

Yoda has these words of wisdom: “You must unlearn what you have learned.”

Congrats, Mike.

Advice: get some narrow, end-to-end shred of your application in front of its customers, real users, test market, by hook or by crook, ASAP. Let the external-most feedback loop be as frequent as possible. Before we work on building the thing right, let’s get empirical backlog-grooming-practical evidence that we are building the right thing.

My advice for Agile teams:

Use the Manifesto as your guide. There is no “correct way” to implement agile, its about implementing smart practices/processes that work for your team in your environment. When you’re evaluating possible improvements, start by holding each one up to the Manifesto and see if it really would help your team accomplish one or more of the goals outlined therein.

My advice would be:
Don’t follow every rule you find on agile methodologies. Stick with workflows and proceedings you find the best to enjoy a communicative and productive development. Always keep in mind that the focus of Agile isn’t the product but the satisfaction of you and your client

Make sure the scope of your sprint is S M A R T

M A N A G E E X P E C T A T I O N S
Stakeholders need to feel engaged with the process, but not burdened by it or suprised by the outputs of it.

Don’t shoe-horn Agile in, focus on C O M M U N I C A T I O N - encourage feedback, ‘show and tell’ - T U N E as you go!

Congratulations on getting the book published.  My nugget of advice:

Work with the energy of the team – rather than solve the biggest problem that the team faces at any time, work out what can be solved with the energy available.

Make sure the team has a clear vision of the roadmap to product completion, so decisions can always be vetted against this ultimate goal.

Start where you are, learn, and adapt. Don’t get paralyzed trying to find the perfect solution at the beginning. You’ll get better with experience.

My single piece of advice would be that you need a reason to move to Agile in the first place.  If you are unsatisfied with how your team is working and need to improve you will need to be naturally motivated in order to be successful.

Teams must buy into the concept of constant improvment and be motivated and committed to changing their culture to succeed with Agile.

“Follow the book first!”

Learn Scrum by practicing it according to the book; after that: adapt based on experience. Everything is negotiable and adaptable, but only after you’ve gained experience. Don’t start adapting Scrum before you have experienced the value of each practice. They’re there with a reason!

My advice to people starting out with agile would be :

Don’t over do it and keep it simple

I would like to add to the Agile Manifesto the following sentence: “Agile people over Agile methods”.
It is very difficult even speak about Agile when developers/managers are tied to old beliefs.
Once again, as many other things in life, people are fundamental and I’m glad to perceive this from your “Table of Content”.
So, dear Team,
Are you going to use Agile methods? Then choose the right people. They are the key!

Thanks,
Nicola (aka “No Agile for Old Men”)

Don’t ignore any stakeholders, do a modest pilot, seed the team with agile/lean-minded developers, choose as short a sprint length as is responsibly possible, plan releases, maintain your backlog (with ROI), and act upon retrospectives, hold scrum-of-scrums, use story points and don’t track effort, publish velocity and burndowns, and maintain a sustainable pace.

Teams must deliver working software that accomplish with quality (no crappy code).

As a scrum master, trust your team to make decisions.  You can help steer away from icebergs but let the team manage themselves.

Know why you are willing to walk down this path.

Try to see the system as viewed by one end user (and I don’t mean “the customer” or “the product owner”). Most technical simplifications I’ve encountered comes from understanding what’s irrelevant to users, most serious problems I’ve encountered comes from not understanding what was important, and most analysis paralysis from considering too many stakeholders at once.

Trust the team.

Trust them to manage themselves, to make the right choices for the software and for their process, and to create a version of agile that works best for them.

A good agile teams, needs to be cohesive, resilient, highly compromised with the project that is involved and above all be conscientious that the failure of the project certainly will compromise all involved in project.

don’t be over-confident.  know where you’re at in the agile process and keep pushing it!

Keep people and their needs at the center of your project.

One word: Collaboration.

Foster collaboration with your customer, product owner, and the entire development team. If you make sure everybody is trying to reach the same goal and work as a true team the results of using agile will be much than what you read on the books.

The most valuable advice we can give to a team has to be about something they can take action. The content of the advice will also vary based on the team, environment and circumstances.

The best advice I can give is to bookmark this URL and use it as a reference for a collection of very good advices and hopefully one or more will help YOUR team to succeed with Agile.

My first advice would be: “Leave your comfort zone!”.
Agile will hurt in the beginning but the pain will not be caused but made visible by agile. Running away from the pain means stepping back into the comfort zone and prevent change.

My second advice would be: “Divide and conquer!”.
One step after the other because too much pain might hurt too much. ;-)

Know your problems, then learn agile.

Inspect and adapt is a great mantra. Apply it not only to the process, but the problem domain, organization & roles, the development domain, etc…

Congrats on the books!

My advice would be “Never give up!”
Using TDD + Coding best practices + Continuous improvement requires a lot of courage and persistence. May take some time but results will come.

Good luck for all ;)

Agile is not the solution.

But it will help you see your real problems.

Start by reading the book Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Implement what makes sense for your organization. Be consistent with the process until you have some experience to adapt.

Find some Agile evangelist. You’re not the first, and certainly not the last, to implement Agile. Use the resources that others before you have created and continue to create today. Use twitter to follow others who are excited about Agile; join online communities where they gather, attend their webinars, read their books, and blogs…etc. I think you get the point. It would be a shame if you didn’t tap into these great resources.

Congratulations on your book!

My first piece of advice is to keep the team small, focused, and multi-disciplined, with your IT and business team members physically together. I’ve seen several project teams that claimed to be Agile, but had decided to not follow this basic tenet.

My second advice is to include one new member on the team that is new to Agile, to spread training and experience opportunities.

Advice: Try. Fail. “No matter, try again, fail again, fail better.”—Samuel Beckett

Know why you want to change.

My advice is to try implement agile practices like you do TDD:
My advise to implement agile practices is to stick to the same principles as TDD:

1. Setup one SMALL expectation on ONE step on the way towards full implementation of the practice (write one small test first)

2. Do the simplest action that fullfills that expectation (make it green)

3. Evaluate your action and make it better (refactor)

4. Continue until you have achieved every step of the practice

4. Continue 1-3 until you have fullt implemented the agile practice

Good luck!

For a given point of view. In a company big enough there is some one holding that view. This includes the point of view: Agile is the reason for my cat getting cancer and dying.

If you want introduce agile methods, you’ll have to deal with opinions like that. Nobody said it would be easy.

“Failure isn’t about falling down
Failure is staying down”

c/o my favourite band, Marillion :)

Realize that whatever you set up with your new agile team will be a starting point. You will learn something new with every iteration. It is hard to resist the temptation to impose practices and techniques, but without the support of the team, the best-laid plans will be sabotaged from within. Start with what is acceptable to the team and the external stakeholders and then the job really begins! Process improvement one step at a time. Remember that even gently flowing water will wear down hard rocks over time.

Scrum is good, not your God

Do not affraid of changing your habits!

I think this is the key element of beeing agile.

Scrum is also a practical discipline like playing the Sax, practicing Judo and painting.
Learning, mastering and succeeding with Scrum is not different than learning and mastering and succeeding in Sax, Judo or painting: find for yourself a coach, train regularly and have fun!

Greetings from Stockholm

You need buy-in from a manager, or it will just fizzle

Feedback is the key to agility.  Incorporate as much into your process as possible, to discover errors as early as possible.

Most important thing to me are the people on the team:
If you can make them adhere to Agile principles, the hardest part is done. From there on you just have to fuel their energy and let their spirits fly - even if the outcome hasn’t been written in some Agile how-to book.

Don’t get me wrong - your books are just part of the fuel my team demands ;-)

Learn the Agile values and practices and continually introspect what work and what doesn’t in your particular environment.

Most important advice I’d give a team that wanted to succeed with agile?

Culture. It’s all about having an open, positive, and fearless culture. With that kind of environment in place, good things will follow. :)