RallyDev.com
Mon 1 Mar 2010
78 Things I Have Learned in 6 Years of Agile Coaching
I have been an Agile Coach for over 6 years now. I’ve learned a lot during this time, and I’m still learning.
Here are 78 things I have learned so far:
- Number of people to whom you ask to describe “Agile” = Total number of Agile mental models + or - 2
- Distributed teams need love and a ScrumMaster at each site
- A foosball table may be one of your best Agile tools
- Geography is more than a timezone issue; it needs infrastructure support
- It’s massively worth the effort to stay engaged in the Agile community through local events, online lists, conferences, and casual meet-ups
- Having a Product Owner is non-negotiable
- Avoid Cargo Cult Scrum at all costs!
- Agile teams need to have fun
- The best Agile teams and companies rely on Servant Leaders
- Embracing a real Agile culture is often more than one team can create on its own
- Agile development can only cut costs if you are willing to spend time and money on it
- A great approach to agile maturing and scaling is Flow Pull innovate guidance from Lean
- Burndown charts are about the team commitment to doneness, not about individual performance or time tracking
- Ensure your sprint backlog reflects the delivery of product value
- Escalation doesn’t serve either the Agile or Lean community in continuous improvement of practices
- You need to have more than checkbook buy-in from your Executive to be successful
- Mature your Agile team practices before attempting to scale to more teams
- Not having a clear signal to end your stand-up can lead to problems
- The Lean principle on Flow guides Agile teams on how to tighten up their practices
- Get everyone in your Release Planning meetings if you want true commitment to the Release’s vision
- Command-and-control ScrumMasters reduce the intelligence of their teams
- Co-located teams move to being high-performing, high trust teams far easier and far faster than non-co-located teams
- Frequent communication through site visits, IM, Skype, email, Facebook, Yammer, video conferencing and other technologies help distributed teams gel and feel the love
- Agile teams invite healthy conflict in order to become great, enduring teams
- Velocity: it’s about the team not the individual
- Kanban is helping teams find new measurements for constant flow of value - so let’s pay attention.
- No product owner or too many product owners add up to the same Agile adoption smell: no definitive decision on ranking or acceptance
- A Product Council is an effective way to manage stakeholders and minimize backlog churn
- Story points help teams separate calendar hour and number of team members from the story’s complexity, effort, and doubt
- Stories have relative sizes to one another; only tasks take on effort estimates
- A well-written story (small, about benefit to a role) doesn’t lie; requirements do by their shear volume of content
- A product backlog is ALWAYS ranked
- A product backlog is not a task list; tasks only appear after estimating and planning by the team
- Agile improves the quality of life for employees
- Great teams are made of collaborative team members
- Agile doesn’t create the messages it exposes them
- Pair programming raises team awareness and code integrity
- Use consensus, not forced compromise or command and control, to gain full team commitment
- Effective team meetings require structure and discipline
- Commit to Agile values and principles; your practices will follow
- Transparency is an Agile virtue not a punishment
- Agile is about commitment not tools; tools support those commitments and make them visible
- Product owners who make their decisions in a vacuum are not Agile
- Agile teams invoke respect and kindness even in stressful times
- Teams that don’t retrospect are not Agile
- Retrospectives are not about blame
- Retrospectives bring continuous improvement of process and working agreements
- If you don’t have team working agreements, create them now
- If you don’t hang your team working agreements on the wall, put them up there now
- Aggressively cap your utilization capacity until you know your velocity
- Blog your Agile experiences; more people want to hear them than you think
- Test driven development doesn’t just create better code; it creates better conversations that create better acceptance
- Agile Architects and Product Owners work side-by-side to rank product backlogs
- Give your Agile teams a break such as a “hackathon” built into the cadence of the team’s release schedule
- High capacity utilization is deceptively evil
- Quality is everyone’s responsibility
- Small increments quickly inform us about our work and produce feature sets faster
- Lean has had a great impact on my Agile language
- “Hiring the best” can be yet another cliche in Agile
- Hire wisely not cheaply
- When hiring new members, team consensus is a must
- Use 5 levels of planning: Vision, Product Roadmap, Release Planning, Iteration Planning and Daily Planning
- Release planning is one of my favorite Agile activities
- Teams and stakeholders invite release planning to see beyond the next iteration
- FYI, good brainstorming requires lots of post-it notes and sharpies
- Pay attention to your facilitation skills so that you don’t takeover decisions and don’t let others do the same
- Keep Agile meetings focused, stick to the purpose and timebox
- Turn your electronics off in Agile meetings; focused meetings are productive and end on time
- The biggest cost cutting lever in Agile is prioritization
- Don’t be afraid to try new practices; your velocity and quality may thank you
- Agile is useful beyond software; take it up and out the organization
- Old tools stand in the way of new tricks; MS project is not the way to go Agile
- Team identity is important, individual heroics are dangerous
- Individual appreciations in retrospectives are a great way to create space for the growth of Agile team trust
- Agile maturity is NOT about a CMMI-like maturity model
- The war between Agile and Waterfall is over; get on with your continuous delivery of valued items
- Agile asks us to slow down in order to speed up; just do it
- I love Agile.
This is far from a comprehensive list. I still have plenty more to learn about Agile. I’d love to get some insight from you about what you would add to the list.
What have you learned in your experience practicing Agile?
About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.
It is hard to be agile without (fast) CI
Small set of commonly agreed rules (working agreements) are needed for CI to work in distributed agile.
Definition of DONE needs to be commonly agreed and understood for all teams in distributed agile.
Great post Jean !!
Defining what is DONE is very important . I have seen that traditionally , DONE means development competed with unit testcased and ready for QA. It needs to be redefined and clearly communicated when you start a team.
Definition of Done! How could I have missed such an important aspect of what I have learned that is so important about Agile.
Along with the great comment about CI, I need to change the name of my blog article to “80 things I’ve learned about Agile in 6 Years”.
Who else can send me ideas to get us to 101? :-)
Thanks!
Jean
I really appreciate this post. I’ll print this list and put it on my wall :)
I also agree with Hannu that you need a definition of DONE that was build by the team.
This is a nice list! Seems like you’ve learned a lot – I love the agile process for development and project management. and i do have to agree that a fooseball table is a fantastic agile tool to have :)
Nice post Jean, I am going to share it with others. This is a great list to use when coaching.
Excellent summation (though, re: # 41 I believe the word is “sheer,” unless you’re discussing wind or hair.)
I concur, although a heavy weight of requirements often shears project’s probability of success.
[...] importance of team agreements was recently reinforced in Jean Tabaka’s post on 78 Things I Have Learned in 6 Years of Agile Coaching (which is a great [...]
Love the post. I’ll be sharing it with everyone in the office. I hope you done mind if i pass some of it off as my own! Keep the great post coming…
[...] Follow the link…. [...]
“In fact, “waterfall” is a straw-man term, coined and used by those trying to promote some new methodology by contrasting it with a silly alleged traditional approach that no competent methodology expert ever favored.”
So please, stop this mention of waterfall, unless you plan to actually present a rigorous definition (that you will have to invent).
Royce’s original paper stated the process should be done at least twice, recognizing even then the value that iteration has in SW development. Few people have actually read it, unfortunately.
“…silly alleged traditional approach that no competent methodology expert ever favored”
There are lots of these still in practice out there. Even their practitioners refer to their own process as “waterfall” or “waterfall like”
@Jim – yang needs a yin, all learning comes from conflict and connection.
Things I’ve learned:
- Teams that don’t continuously learn eventually fall apart, no matter how mature they are.
- Frameworks, methodologies, processes, and thinking patterns are all just tools to deliver value. When the tool becomes more important, the customer will lose.
- Agile words don’t an Agile team make
- Committing to Agile doesn’t imply leaving good business and engineering sense at the door. If you’re not capable in those areas, your “Agile” will become the next scapegoat for failure.
- Without a culture of discipline, Agile (or anything else) will fail.
- Teams that cultivate commitment to one another and to real value will do what others’ only dream of.
[...] This post was mentioned on Twitter by sweigarts, Tech Pit. Tech Pit said: For agile enthusiasts, this is a really great article – 78 Things I Have Learned in Agile Consulting – http://ow.ly/1ENXh [...]
Item 2 “Distributed teams need love and a ScrumMaster at each site.” caught my eye as my company has distributed teams. Question: Does this suggest that the scrumMasters at each site “co-master” the team? Where can I find additional info on this?
Jim, it’s hard to know if Tech Republic or writer Shelley Doll who posted there is a competent methodology expert, but Shelley has been a prolific writer there and both defined and favored the approach in the post at: http://articles.techrepublic.com.com/5100-10878_11-1046507.html
I might add,
Refactoring is cheaper than reuse.
It didn’t take agile to teach me that making code reusable takes three “uses” – you don’t begin to get reusability right until the third. There’s a rule-of-thumb that’s pretty widely known to that effect. But yet many of us kept trying to architect for reusability instead of letting architecture and reusability emerge – until agile pointed out the foolishness of doing so from a different angle.
[...] This post was mentioned on Twitter by Jennifer Bleen. Jennifer Bleen said: http://www.rallydev.com/agileblog/2010/03/78-things-i-have-learned-in-6-years-of-agile-coaching/?elq=4d4ded28740149a89c5dbdebf19915a0 [...]
[...] This post was mentioned on Twitter by Centripetal Software. Centripetal Software said: 78 Things I Have Learned in 6 Years of Agile Coaching – http://bit.ly/a9jDfc [...]
We learned that Agile helps control scope creep, which had always been a problem before we went to Agile. Our Agile teams now do a fantastic job of defining and controlling the scope of a release and an iteration.
Jean, thanks for the post! I suggest a few additions:
* Effective team members practice self leadership.
* The organization’s personnel practices must support instead of hinder teams, servant leadership and Agility in general. Remember the old adage “You get what you measure.”