Succeeding with Agile: Software Development using Scrum is now shipping. To celebrate, I will be giving a copy of the book to two readers of this blog.
To win, enter as a comment to this post the one most valuable bit of advice you would give to a team that wanted to succeed with agile. I will pick the one bit of advice I like best and send the author a copy of the book. I will also pick a second winner at random from those who submit. So, you’ve got two chances to win so let’s hear your best one bit of advice.
I’ll run the contest through the evening of 11 November. (How about through 11 pm on 11/11?) I’ll pick the winners on 12 November.
Good luck.
Also, this post officially kicks of my 20-posts-in-10-weeks commitment. I’ll be posting here a lot more frequently over the next 10 weeks sharing short ideas from Succeeding with Agile.
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.
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.
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.
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!
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.
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 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.
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)
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.
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.
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.
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.
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