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.
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.
[...] piece of advice is the following: “Know why you are willing to walk down this path.” Once you know, you’ll be able [...]
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.