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:
Agile is great, but don’t forget the customer goals!
“The principle of scrum is iteration”: so simple yet powerful as a framework for effective adaptation of product as it is produced.
Establish a culture of learning and adapting. Encourage complete transparency and trust. Sometimes you may need to remove people to achieve the correct environment. Judge teams on the “what” they do and not on the “how” they get it done.
The key message is that agile methods are about creating a dialogue among all of the stakeholders involved in delivering a software product, tearing down walls that have historically stood in the way of delivering high quality products on reasonable timelines.
Congrats on the book. I am a fan since User Stories.
We have introduced agile development in our University five years ago, here are some tips from working with students in an agile process:
- Discuss on the definition of done, try to get things done but take a few iterations to learn what can be done in one iteration and finally keep developing in a sustainable pace.
- Always deliver your product even when the customer is unhappy, he has the right to see where you spent the money on. Adapt, learn and improve.
My thoughts on this is a combination of some success story with some projects with stakeholders providing references to this success story followed up by continuous educational campaign. This will eventually make an effective way if implementing it
work on yourself. success comes when all members of the team express opinions passionately and hold them lightly, grant trust to others and work to earn trust from them.
all of the process stuff is important, but those two actions by individuals create the interactions that enable collaboration.
Don’t sprint too fast, because you’ll get too tired too soon. Run with usual pace and you can run the whole marathon and on time. And by the time you finish running it, you’ll find out you like it so much that you’ll just keep on running. And you’ll get better every time.
My # 1 piece of advice: Have fun with it!
Don’t just commit halfway to Scrum or take just the things you like. It takes tough decisions, tough arguments, and sticking to your guns to get there, but you will be rewarded for your perseverance with a team that believes in the process and you for taking them there.
Don’t expect to be able to do Scrum *exactly* as it says in the book/course. Be committed to the principles and the ceremony, but be adaptable too. The peculiarities of your organisation will shape your adoption of Scrum and vice-versa. Above all, persevere, it’s a never-ending voyage of discovery.
Relying on the tools very much could hurt the first value in Agile (individuals and interactions over processes and TOOLS)
Before using Tools (sending mails to each other, using TFS or version one to track stories and bugs), always remember what would you have done before using this tool ? in other words how would you communicate with your team/PO/Customer before using the tools?
For example when you have a question to PO/customer share your question with the team first.
Always have a Task Board on the WALL (not just using a software to make it for you) so everyone can see at anytime just by a look what goes on with everyone.
so if anyone finish a task , everyone can see that without the need for waiting for DailyScrum to see the progress is happening.
My advice would be:
“Always keep in mind the business value of your actions, and don’t get caught up in unimportant side issues.”
Improve interpersonal communication skills. Develop people first.
We can find lots of self-called agile teams planning sprints, writing stories and guessing story points without having their individuals actually talking to each other.
Most people who develop systems tend to be more introspective, so making them to ‘come out’ from their inside universe turns out to be the greatest challenge.
To succeed with Agile, expect failures at some point.
Everything is not going to be as expected, so don’t hesitate to embrace change !
One thing about Agile (“Doing Just Enough”) that can be extrapolated to life too is
“Think Just Enough”
-do not make assumptions and imagine the future…
This is reduces a lot of “Worry” in life !!
All problems in commercial software are people problems!
“Just code like hell”
Advice to team:
“Talk to and trust each other”
“Deliver what you commit to”
Guess that’s 2
Additional advice to management:
“Make sure the team has cross-functional membership”
“Trust the team”
Base your development on facts/insight, set clear goals and measure the results (success/value) of your development. Then adapt on the basis of the results.
Advice to team:
Get a team of developers that are commited to work they do. Start iteration development at all, keep focus on incrementally delivering value to the customer want and wrap it into iterations. As you progress keep improving and reviewing the process and make everyone on the team involved in it.
Agile brings a new dynamic into your organisation, and in some cases pretty fundamental changes. You might experience a worse-before-better outcome, whether real or perceived. Is your sponsor/budget holder/senior manager willing to accept that? Be ready to do a lot of hand-holding, evangelising and advocacy on your first project. It ain’t easy, but it’s definitely worth every drop of sweat and tears.
Developers need to recognize “it’s not about you.” Devs can get so wrapped up in competing with each other, advancing themselves out of fear of losing their jobs or appearing uninformed they won’t ask questions and go blundering onward. It’s not about you. Check the egos at the door and recognize that the team works together to advance a project. Practice saying “I don’t know” and “I’m not sure” and “Let’s ask the rest of the team.”
Gather relevant metrics. Feed them into the retrospectives.
Keep an open mind and actively participate. Remember your team is smart and can overcome any obstacle encountered in making the change to Agile. You’ll get back everything you put into it and more. Have fun.
Create trust among you, this is the basis for all great achievements.
My piece of advice:
Think about now!
When working with a new team discuss what they feel are the most appropriate agile practices and standards they wish to implement – this forms the basis of the teams social contract. Iterate and update the contract on an ongoing basis as the team gains confidence and experience. Social contracts are a great help in facilitating team buy in.
The most important part of any process is the retrospective. The team needs space and time to reflect on their software development process, and more importantly, on team development and interactions between team members. Successful teamwork requires open communication between all team members to maximize synergetic effects. My advice for an agile team is: don’t be shy to talk about any problems you may have (including conflicts with each other) – remaining silent about problems doesn’t solve them, only known and open problems can be solved. If in doubt, ask a neutral person to facilitate retrospective meetings and coach team members in communication techniques.
Believe in what you are attempting, be passionate about it, and people will follow you and so will success. We started with 1 person going to a conference, buying a handful of books and dong what I said.
Good luck.
To succeed in Agile, start with the right people.
I’ve been watching your writing for quite a while…
The best advice i can give is “Dont give the fish to a man, its better teach him how to fish!” Im using this Agile guideline for some years and i always get a smile off my team and the customers.
“Beware of the dark side” .
Thanks for everything.
Focus on principles, not practices.
Shortest Advice Ever: drink the kool-aid
long version:
do it, keep doing it, keep doing it, even when you think it’s crazy. get professional help to get started, even if only advisory. experience is valuable and will help get you off to a fast, effective start. start with a single project & a single team (not a tiny project, but not a company killer either). then, grow out from that one success, seeding other teams and learning as you go.
i’m late, but i figured i would post anyway.
as a blog poster, i want to post my advice, so i can share what i’ve learned with others.
[...] You posted nearly 200 bits of advice in response to the contest to provide your one best tip for “succeeding with agile.” Everybody here is wonderful and we generated a pile of great advice for anyone stumbling across the [...]