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.
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.
Congrats on the book, looking forward to reading it.
My advice is this: Make decisions, and then adjust as needed. Don’t allow the pursuit of perfection to prevent you from getting started on a good idea you have in-hand. Then measure the impact, and improve.
My advice:
Remember that it is all about the team (people) and maximizing teamwork (communication). Together you must share successes, failures, and the goal to work with the customer and create a great product for them. That goal must take priority even if that contradicts with plans or process.
Congrats Mike on another great book!
Wow, what a deviously clever way to get a superb collection of advice on a single topic of interest to the readership! Nicely done, Mr Cohn!
AgileMan’s advice: Define success in terms of things that you can measure, and then measure them! It’ll probably turn out you set out to measure the wrong things initially, but if you keep adapting that practice you’ll eventually get to the right place. And remember: if success were easy, everyone would be doing it!
Lots of great advice already above. My one piece of advice would be to learn how to leverage the power of the retrospective – it is the single biggest opportunity you have to rally your team around the Agile precepts (inspect, adapt, refine, validate/check, etc.).
Keep track of your ‘what could be improved’ list Sprint-to-Sprint; always follow up on what you committed to change, track if those changes stick (and if not why they didn’t) and keep a list of previous suggestions that you didn’t get around to implementing. Shave the list down when it gets unwieldly – keep it relevant. Watch for items that come back once they’ve been dealt with, etc. This will give you a good gauge of how your team is truly coming along from a cultural standpoint, which will in turn result in improved productivity/velocity.
Do the simplest things first and rest will come as melting ice-cream in the corn where you want to grab it fast before it false down.
Be agile and win!
Shafraz
Always remember that all of this is about delivering Value to the Customer. That’s the prize, never take your eyes off of it, never forget that’s the whole point of Scrum.
If you do everything else ‘right’ in your agile process, but forget to focus on actually delivering the value the customer needs most, to that customer, you fail. More often than not, when teams fail with agile, it’s because they ‘took their eyes off the prize’ and got bogged down in process or practice, or some other minutia. Fail to deliver and you’re a lot less likely to continue working for that customer, no matter how perfect the rest of your process is.
Conversely, you can technically ‘fail’ in many other areas, but as long as you manage you deliver value to the customer, you succeed. That means you are more likely to get to keep working for that customer. You and can then focus on improving in the areas where you ‘failed’ and hopefully deliver even better in the next iteration.
That’s my one thing.
Tightly coupled with remembering to deliver value, is to be highly aware of just what represents ‘value’ at what point in the project. For example, early in a project, the most important thing might be to be able to get feedback on potential approaches to solving the problem. In that case, 5 quick and dirty ‘proof of concept’ prototype quality products trump one high quality, highly maintainable elegantly structured product. In that case Quantity is truly of more value that ‘Quality’. So yes Virginia, quality IS negotiable in some circumstances. See These two excellent blog posts by Kent Beck on this topic http://www.threeriversinstitute.org/blog/?p=251, http://www.threeriversinstitute.org/blog/?p=252.
The point of this example being if you get all dogmatic about ‘quality is not negotiable’, ‘zero technical debt’, and insisting on perfectly maintainable code done with methodical TDD, and SoC/SRP, LSP, Mocks etc, you will be doing great agile practice, but FAIL to deliver to the customer the value they really need at that time, and thus very likely FAIL all while doing great agile practices and perhaps even delivering a high quality product.
–Chuck vdL
My advice would be: Start with a retrospective, to find out what your greatest pains are. Pick a practice to alleviate the worst, apply thoroughly, and don’t give up. Then fix the next problem…
Don’t be disheartened if it seems you’re going backwards after moving to agile; improvements will happen if you keep at it and it will pay off in the long run.
I would urge anyone interested in adopting an Agile approach, regardless of method and/or practices, to become very familiar with the Agile Manifesto and associated Principles. Some level of method or practice “tailoring” usually occurs in any given adoption effort. Understanding the Vs & Ps can prevent tailoring the benefit out of the practice(s) being modified. At the very least, knowing what the Vs & Ps mean can alert people when they are making changes that could limit/derail their adoption effort so they can decide if it is worth (or how they could best go about) pursuing given that the changes would have to be made.
Lead people toward agile.
To paraphrase Peter Drucker, leaders make sure the right things get done while managers make sure things get done right. Be a leader not a manager!
My personal experience is that software development, like almost everything, is a people-sport. Find the natural fit between agile and the people on your team!
You won’t be agile overnight and different projects will reach different levels of agility. Keep moving towards being as agile as possible!
If you believe agile is a better way to develop software, evangelize its benefits. As Guy Kawasaki says, “Sales is rooted in what’s good for me, evangelism is rooted in what’s good for you.” The road to agile is so much easier if the people on a team want to travel it. Show people the benefits of agile!
Great news on the book.
As an organisation, we started using Agile about 6 months ago and my piece of advice is:
Don’t use pieces of Agile methodology and when it does not work out say “Agile doesn’t work!”
Agile relies on all components to streamline business processes so you either need to go balls to the wall or not at all.
You need to make sure that your clients/stakeholders understand the real meaning of agile. Language has a strange way in manifesting itself. For most agile is about being quick and building a product in a shorter amount of time. Its important that they understand its not about being done sooner but a better product sooner than other methodologies allow.
Congrats on the book!
Remember we value “individuals and interactions”. It is about people and conversation. Make sure your practices, tools, and environment support conversations and doesn’t hinder or replace them.
As an example, one team was using planning poker and focused on the number and forgot that the disussion about the differences is the real value.
To truely succeed, agile teams need agile clients. I’ve heard a lot of software developers talk about having daily scrums, doing sprints, maintaining the backlog, etc all of which are very important and are usually the first things that get set up when teams first start using agile. In my experience, one of the areas of agile that is most easily overlooked is working with the client to help them understand what agile is all about and more specifically what their role needs to be. Many clients want to provide their input up front and then say “the developers handle the rest, call me when it’s finished.” If the client is unwilling or unable to give regular feedback and interact with the team the you won’t truely succeed with agile. That’s not to say that using agile processes internally is of no benefit, it is enormously valuable! However, if the client isn’t on board and willing to commit the time they need to take part in the process then you will (at least partly) fall short.
Stop thinking about tasks. Focus on the stories. If you’re used to waterfall, you’re used to thinking about specific tasks and how long they will take. But just about any meaningful discussion in an agile project has to focus on stories and sprints and things that are higher level than tasks. It can be really hard to let them go if you’ve been estimating and planning around tasks and the hours they take, but if you don’t let them go then you will never truly become agile.
Congratulations Mike – looking forward to reading it
Advice: Your implementation depends on how well you sell the values that Agile brings.
Remember:
“Agile is not a silver bullet, but it will show you where the werewolves are.”
Transparency and the willingness to see your faults and adapt are at the core of being truly successful with agile.
Congrats on the book!
Iterate. Reflect. Repeat.
S tart
U n
C overing
C ertain
E xasperations
E veryone
D islikes
W ith
I ts
T ime
H onoured
A pproach (and)
G et
I ncorporating
L ittle
E volutions
Have the passion to please your customer,
Have the restraint to deliver only whats needed,
Have the humility to accept your mistakes like gifts,
Have the courage to own and constantly re-invent your process.
For me, I find that there is one quote that sums up all things Agile…
“So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product.”
The one quote encompasses working as team, continuous integration, iterations, reducing work in progress, and so on.
Unfortunately for me you may have to send my book to Tom DeMarco as the quote is his, from the article “Software Engineering: An Idea Whose Time Has Come and Gone?”.
Being Agile takes wisdom, passion, courage, a desire to be better and openness, especially to change as we plan a little, do a little, study/check how we did and adapt; while we collaboratively and adaptively develop and deliver commercial or operational value iteratively and incrementally.
Keep the team focused on the stories in sprint. Every day review what they have committed to complete during that sprint so the team can focus on just that work. Keep asking the question: Are we on track to finish all the stories?
Congratulations on the release of your book!
My advice would be:
Do one week iteration, do retrospective, improve.
Does the product user have control and responsibility? To expand: Is the user getting what they want? Are you trying to get as close to what they want with every sprint?
My advice is something that I feel stretches well beyond the Agile world. I believe we’d all fair better if we took this one to heart… Be appreciative and open. Take the time to listen and understand. The challenges faced/voiced by you and your colleagues are real and often represent major opportunities for improvement – avoid being quick to dismiss what others are saying.
To borrow from Covey: “Seek first to understand, then to be understood.”
Sorry… fare better… Not, fair better.
I think the one thing most likely to drive success is to conduct regular retrospectives. Get a facilitator for them if necessary, but getting the team to find continuous improvements is my one piece of advice.
Hi Mike,
How about this variation from an old quote, to give to your agile wannabees as a mantra:
Dear , please give me the humility to accept what I do not know, the courage to experiment with what I have learned and the wisdom to know the difference.
Joakim
congrats on the book! Advice: Know your users and include them constantly. That is how you gain crediblity and buy-in.
keep on doing “Plan – do – reflect”
Congratulations on the release of your book!
My advice is: Make work enjoyable. The team should have pleasure and satisfaction on develop in agile way.
That’s my piece of advise:
“Don’t be blocked’
This should be turned into the scrum advice board, it’s great and we should keep it going, I love it!
My advice, there is only one winner and that is the team as a whole! So put the team first and work together, listen, support, grow and collaborate!
Afterall Scrum is all about PEOPLE!
Retrospective is key, you can follow all the approved Agile/Scrum guidelines to a T and still not be successful. Listen to the feedback from the team and incorporate it into future sprints. Agile is more of a journey than a destination.
Remember that becoming agile is a journey not a destination and to succeed you must embrace change, accept it requires learning and continuous improvement on the way. And above all enjoy what you do.
Fail fast and fail visibly. It is the only way to learn and improve.
Congragulations on your book !
Advice: People-Process-Tools of a company defines a company, the word AGILE implicitly means-change, adaptation, open-communication, transparency,ability to manage scope creep, and of course the Agile Manifesto principles,
IF we can INCORPORATE these Agile terms in the People-Process-Tools of a company in a linear fashion and by a step-by-step approach, success is not far off.
Pledge and commit to being absolutely open and honest with each other as a team going into it. If you can’t agree to that on conversation #1 then your setting yourself up for failure right out of the gate. The dysfunction deamons will emerge soon enough and start to get you in all the wrong ways!!!
Reflect at regular intervals and use the results to improve.
Keep remembering…
We iterate to continuously build a better product *AND* We iterate to continuously build a better team!
Think of people first. When in doubt, the answers are in the team.
Agile is about self-managing. Therefore my best advice to a team to succeed with Agile would be to manage themselves by organizing the current work well, handling technical challenges in a disciplined manner, consciously improving your own skills, and regularly reflecting over the course of the project. It’s a bit vague, but in order to apply each one need to elaborate it in a particular context.
If I was in a position to provide the most valuable bit of advice to give to a team wanting to succeed with Agile, I wouldnt neet to go out and buy Mike Cohns “Succeeding with Agile” – I would be publishing my own book ….
Yours sincerely,
A Business Consultant wanting to succeed with Agile and willing to learn
Communicate. Don’t forget, people matters not processes
A beauty that I see in agile is in the feedback, feedback, feedback.
Because of this we can direct more energy into doing the right things, instead of just blindly doing the wrong ones.
My advise to the team is to consider the project as a game where they are in the driver seat and do not report to any one. Having passion can create marvelous results.
Is there any fundamental difference between “agile” and “lean”?
“Ideas does not matter, it’s execution that counts”. So many people have good ideas, but fail to plan properly. We sit together and get more innovative ideas from the teams, but its the EXECUTION that counts. At the same time, always remember to celebrate every milestone – successes and failures!