Agile Development Blog

On March 19th, I was fortunate enough to be able to attend 1 day of the  Engineer’s Without Borders (EWB) National conference.  EWB is an international organization founded in 2002 by Bernard Amadei, my Engineering Geology Professor from the University of Colorado.  EWB-USA has 250 Chapter organization, 12,000 members and 350 ongoing projects; it uses college students and professional engineers to address engineering problems in developing nations.  (Take a look at their Projects section of their web site to search and see some of the great work done by these great volunteers, Chapters and Sponsors.)

In addition to browsing projects, talking with students and sponsors, I was able to catch Bryan Willson from Colorado State University give the Plenary talk.  It was very inspiring blend of my favorite topics; great engineering, sustainability, global change, social entrepreneurship and agility.  His group at CSU has built a number of social enterprises to help commercialize solutions for the large-scale global change.

These three areas of commercialization include:

1. 2-Stroke Retrofit is a fuel injector kit that reduces CO2 in two cycle engines by 90% and increase mileage by 35% for the 100 million engines in the developing world alone
2. Clean Cookstoves are solid fuel cookstoves that can reduces CO2 by 75% and increase efficiency by 35% for 600 million solid fuel, including wood, dung and coal, stoves in India, China and Africa
3. SolixBioFuels – A system for growing and turning algae into bio-fuels that is 7 times more effective than open ponds.

All three of these stories provide proof that commercial mechanisms, social entrepreneurship and Agile Product development can change the way our global society runs.  His team created these innovations by seeing the large-scale systems, collaborating across boundaries and creating something new, not just trying to solve a problem in the current broken system. Finally, his call to action for all the EWB members was to be the eyes, and ears on the street with regard to these solutions in the developing world.  For folks in the Agile Community, you can think of the EWB engineers as the proxy to the customers.  It is not that Mark’s team does not have a test lab, work in small batch cycles or reach into the field to see their products in action, but at the scale of 100′s of millions and scope of these global issues you need all the feedback you can get.   What a great partnership!

I encourage you to explore the EWB, SolixBioFuel and Envirofit webs sites.  I would especially like to thank Cathy, the current Director of EWB-USA, and Bernard for inviting me to attend this amazing conference.  I look forward to future collaborations.

On April 21 in Atlanta, the Lean Software and Systems Consortium will come together for its second US conference.  Last year’s event in Miami was “amazing” according to Jean.  So this year, Rally is exhibiting, I am speaking while Jean and Aaron are running the open space on Friday.  The price per attendee goes up by $250 on March 31st, so if you do intend to go, REGISTER now.

At our booth, Rally will be demonstrating its product support for highly-visible Kanban, WIP/Cumulative Flow reports, and cycle-time  metrics. Join Alan Atlas, Jean Tabaka, Aaron Sanders and Craig Langenfeld in our booth.

I will be presenting an experience report titled: PDCA: Beyond Simple Inspect and Adapt. On spring break this week, I’ve been thinking more about the details of my talk. Here is my abstract and outline for those of you who might consider attending:

Lean and Kanban focus on practices of continuous flow of product delivery. Plan-Do-Check-Act (PDCA) is a Lean discipline that moves beyond inspect and adapt of Agile team-level processes.  At a corporate level, PDCA provides guidance for strategy as well as problem-solving work. In 2009, I led Rally’s move to PDCA for the company’s strategy process at both the annual and quarterly levels.  My primary guide was Pascal Dennis’ “Getting the Right Things Done”. In this experience report, I share Rally’s PDCA first year of adoption: where we started, how this impacted our corporate behaviors, and where we are now. I want to share Rally’s story to compel participants to embrace PDCA and get good at it. I ask each participant to come with its organization’s #1 goal and success criteria. I will close with a planning A3 exercise from Pascal’s book .

Outline

1. What brought me here—background on why I am passionate about sharing my organization’s overall Lean story including the addition of PDCA, A3’s and concurrent set-based development.  This talk focuses on PDCA as the critical step in increasing structure and discipline in strategy execution.
2. Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
3. Benefits — Mature your strategic planning and execution environment to handle the complexity of increasing speed, agility and scale and to gain alignment, pull and innovation.
4. Where we were and what was not working
   1. The context at Rally was based on a couple of key concepts:
      1. Core Values, Core Purpose, Sandbox and BHAG from Jim Collins
      2. 3 to 5 Quarterly Rocks, success criteria and Scoreboards from Gazelles
      3. Rock team structures  – cross departmental and story based
      4. Facilitated, highly collaborative cross-departmental meeting of 30+ managers and above
   2. What we noticed
      1. Rock work as a second or third job
      2. Wisdom of the Crowds to help fix over-reaction and group think
      3. Too much on the fly, not enough backlog grooming
      4. Highly critical, non-cross departmental initiatives were de-prioritized
      5. ORID process added to keep from jumping too solutions, but the data was not visible enough
5. What we decided to do about this:
   1. Explanation of PDCA — A brief overview of PDCA in general and then specifically what I used as guidance from the Pascal Dennis book, “Getting the Right Things Done: A Leader’s Guide to Planning and Execution”.
   2. Our initial experiments with A3 process the year prior — Working with our Ops team and product marketing teams on problem solving using real data
   3. First quarter — How we kick-started Rally’s company-wide adoption of PDCA . I describe our “Mountain Team” and their transitional role.
      1. Defining Rally’s True North
      2. Creating our second level tree with current and needed metrics
      3. Socializing these throughout the company seeking feedback in anticipation of our annual and quarterly planning
      4. Started new experiments based on quarterly planning decisions
   4. Next Quarter – Review new experiments, discussed learning and drive A3’s into the planning process
   5. Mid-course adjustment by Mountain team, in middle of the quarter – What we discovered working and not working
      1. The rocks were all dependent on each other.
      2. Had to run Rock of Rock team meetings to steer to a final solution
      3. Coordinated release planning would have
   6. Final quarter – We worked to expand the plan. We took the Mountain team’s True North and feedback to drive our PDCA for Rally’s Annual Corporate planning by:
      1. 1. Taking company-wide feedback into our Annual planning to collaboratively drive cross-department A3 creation around each branch of the tree
         2. Mountain Team retrospective over the course of year 1 that helped create a planning rock team.  The Mountain team’s role as a transition team ended.
   7. Year 2 – Doubling down our efforts to go from amateurs to intermediates —Changing our process to institutionalize A3’s and PDCA as our strategy execution approach:
      1. Quarterly rocks moved to a world of pre-defined from developed on the fly
      2. Quarterly planning moved from ad-hoc based on yesterday’s weather to more programmed based on True North and meeting the target metrics
      3. Strategic planning worked to validate annual True North in the context of long-term planning, shared vision development, cross-boundary collaboration and larger systems
6. What we learned and what you should do about it
   1. The cycle of adoption is a year, quarterly cycles work to improve the process, but it is hard to make leaps on a quarterly basis.
      1. Year 0 – Introduce Lean thinking (A3 in our case)
         
      2. Year 1 – Introduce PDCA (Novice)
      3. Year 2 – Invest or abandon (Your choice)
         1. A3 is now the language for problem solving
         2. Making sure we are solving the right problem (aka slowing down to speed up)
   2. Do not have a overall guidance team steering the continued PDCA process – it is owned by the “team”
   3. Putting pressure on the organization to get more clear about our economic models to mature from “Theory-based decision making toward the right solution,” Now “Data-driven decision making toward the right problem”
   4. Where to start – The Strategy A3 an exercise
   5. What is next? – We call it the Innovative or Lean Organization. Seeing large systems, collaborating across boundaries and creating your reality.
      
7. Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
8. Call to Action – Introduce the language of A3’s through problem solving or Strategy A3’s
9. Benefits — Help build a company of problem solvers to focus your efforts on the critical few things.
10. Where I hope you go with this: Great companies build great software, great experiences and work on creating win/win scenarios.
    

I’m traveling this week to Rally’s Agile Success Tour in San Diego.  I love attending these events because they’re a lot of fun and participants seem to get a lot of value – getting out of the office for a half day is a great way to learn and think about how you can get started or get better with Agile.  Plus, the Rancho Bernardo Inn is pretty nice place to spend a day.

The site of Rally's Agile Success Tour - the Rancho Bernardo Inn

But my day job is as a Product Owner, so I’m still trying to keep up with my team while on the road.  And this trip has been a good reminder of the challenges of working remotely.  Here are seven things I’ve remembered that make a big difference if your team has remote members:

1. Actually log in to your chat client. 
Instant messaging is a great way to quickly make contact with people on your team, but if everyone isn’t actually logged in to chat, you often can’t reach the best person.  If I want to talk to Fred, but I can’t reach him, I’ve got to make a decision – do I wait, or do I interrupt Jason, a developer on his team?

2. Dial in the bridge. 
If you’re having a meeting, and you have remote team members, make connecting to the conference bridge a habit, even if you don’t think anyone remote is going to be attending.  Plans change; something comes up such that someone who was going to be in the office is out.  If you don’t connect the conference bridge, remote employees will either give up, or frantically try to catch local participants on IM in the hopes that someone brought a laptop to the meeting.

3. Check in and out on the phone. 
Assign someone in your meeting to remember the remote team members during the discussion.   And make sure you check in with the people on the phone before you hang up at the end of the call.  (Give them a few seconds to unmute before you assume they’re gone!)

4. List your cell numbers.
At Rally, we have a Google spreadsheet that lists office and cell numbers for everyone.  I’m rarely at my desk during the workday, so cell is the only reliable way to reach me.

5. Skype your standups.  
In our team room, a couple of the machines have Skype running.  When you’re remote, video goes a long way to improving connection with the team.  Showing some video of the absurd furnishings or the view outside the hotel room makes it fun.  This morning, I had some bandwidth issues and could only use voice – it didn’t work nearly as well.  Also, with a team like mine, a remote employee who doesn’t enable video for an early morning Skype session will invariably be subject to baseless accusations of not wearing pants.

6. Leave Skype running for a few minutes after the standup is over. 
Often interesting conversations pop up in the 30 minutes following this meeting.  As a PO, I often overhear useful bits of information at this time, and it makes it easy for people to ask me questions they might have forgotten during the standup.

7. Update your stories. 
This morning, when I logged into Rally, it looked like a ton of work was in progress.  Turns out, my team just hadn’t updated their tasks and stories.  Often Rally is the window your remote team members have into what’s going on.  If you don’t update stories, you can end up with unnecessary confusion.  Fortunately, we cleared it up in our daily standup meeting.

These were the things I remembered this week.  So what tips do you have for making life easier on remote team members?

On the road to Agile adoption, I often get asked, “how do you get teams spun up on Agile fast?”  The short answer is to just do it. The long answer is that I believe there are 3 options. 1) Rally and other Agile coaching organizations offer programs that place a coach in your team to help with preparation, planning, estimating, setting norms, committing, tracking, daily stand-up, demonstrations and retrospectives. 2) You can take the DIY approach,  but watch out for the unintended consequences.  3) Finally, I think there is the intensive practice approach.  Let me give you some examples:

A Sprint Per Day for the First Week

While speaking and attending Agile Vancouver in 2008, Linda Rising facilitated a fishbowl exercise with a custom development firm in Vancouver.  Given they were starting and stopping projects and reforming teams all the time, they had developed an approach to speed the team through the formation process and inculcate new team members (employees and customers) to the process.  The would run a scrum sprint every day for the first week.  This intensive process would allow them to work through tons of issues in a very intensive week.  I would call a form of this preparation over planning.

A Sprint Every 90 minutes for a Weekend

If that is not fast enough for you, how about a sprint every 90 minutes?  That is what the folks at SnapImpact did last weekend in Boulder at their SnapCamp (based on the notion of Startup Weekend).

I heard about this from one of the organizers and fellow Sprint Triathlete Dave Angulo.  Dave is co-founder of the non-profit SnapImpact, a guerrilla non-profit that has a mission to “Make Doing Good Easy.”  They developed an iPhone application and WordPress plugin to simplify how people learn about volunteer opportunities near them.  It takes feeds from HandsOn Network and soon All for Good. It is cool, I’ve been playing with it for a year.  Anyway, ran into Dave at a CTO lunch in the TechStar’s bunker today and he told me about the wild success they had with 90 minute sprint process through the last weekend.

To give some background, SnapCamp was the kickoff effort for developing v2.0 of All for Good, the platform which powers http://serve.gov and a number of other sites. It’s the largest single repository of volunteer opportunities in the world. Version 1.x was pushed into production quickly and, while it is up and running, there have been a number of technical limitations which have frustrated All for Good’s partners and limited the platform’s usefulness. SnapImpact offered to develop v2.0 of All for Good because of the close alignment of the two organizations’ missions and their desire to have a more comprehensive list of opportunities for their iPhone app.

Dave - We started the weekend with dinner on Friday night to allow time for everyone to meet each other, learn about each other’s backgrounds, and have a shared group experience. We had people from all over the country as well as a great local contingent. Some were die-hard SnapImpact volunteers, others had only heard about us recently. The dinner allowed for folks to get to know one another in a casual setting without having to do it in between trying to get work done.

Saturday morning, we laid out the business problem, context, and goals for the weekend, then I announced we would do 90 minute sprints. The business teams (we had marketing, UI, and product teams as well), would adhere to the same schedule. The beginning of the first sprint for dev was spent laying out four areas of technical problems and having the team self select into what tickled their fancy. Everyone then got to work. I moved between the teams to discuss possible technologies for them to consider and dive deeper on the problems they needed to solve. The volunteers then took over and by the end of the first sprint everyone had a handle on their problem areas. Most even had a initial plan of attack.

Everyone has heard of Forming, Storming, Norming, and Performing. With 2 days to get work done, we had to get them to performing as quickly as possible. The dev teams were all about 3 people in size with differing skill levels and familiarity with the technology stack we were using. The 90 minute sprints forced a tempo which required the teams to get to performing quickly – no one wants to report out nothing was accomplished. Yes, some of the progress initially was small, but these were hard problems to tackle in a weekend. I had one team who’s requirements were being developed by the business team through the weekend, some sprints the deliverable was “received requirements from business and developed a response.”

By the end of Saturday, all of the development teams had produced something which was merged into mainline for the other teams to pick up. That was huge and everyone could see the bar moving.

Sunday started with a review and then everyone picked up where they had left off. The development teams reformed and started working before we even had the morning review. The pace on Sunday kept accelerating, merges occurring after every sprint, until late afternoon, when we started winding down.

I have run many volunteer projects. The SnapImpact team had actually completed one earlier in the week involving several hundred people with BDNT, and it’s absolutely critical volunteers feel like they are moving the bar. Given the scope of this project, it was going to be very easy to have volunteers lose sight of the progress they are making and give up. The 90 minute chunks with progress review and planning helped ensure the volunteers didn’t lose sight of the progress we were making that weekend. As project owners, we had goals of our own on what was going to be delivered at the end of the project. The sprints allowed us to keep moving in the direction we needed to go as well as identify trouble areas.

Dave – Training – One decision I made was to use a relatively new technology stack, Scala/Lift, for the framework. Instead of holding a formal training session for those unfamiliar with it, I made sure there were experienced people in each group and let training happen “on the job.” I think next time it would be better to do a short training session, as given the pace, sometimes that training disrupted forward progress. Just the basics, so when a concept was discussed it wouldn’t be completely foreign.

Deliverables – We got sloppy during the reviews and didn’t nail down specific deliverables for teams. At times, it caused teams to lose focus during the sprint. The reviews were every 90 minutes, so the lack of focus was caught sooner rather than later.

Insert more fun – Because the tempo was so high, I’m not sure folks had as much fun as they could have during the event. I’m a big believer in fun being central to any successful project and I think teams could have bonded a little more and we may not have been as exhausted by Sunday afternoon. There was some fun, we just needed more.

Dave – Our goal was a beta of existing functionality by the end of the weekend. We’re very close to that now, but some decisions made during the weekend prevented accomplishing that goal. The SnapImpact team is continuing development and once the existing functionality is in place we’ll start working on a host of new feature requests from the business team. We’re entering all of that information into Rally now and beginning the planning process. Folks will see v2.0 at http://allforgood.org in June.

Dave - Preparation started weeks in advance. My role in this project is CTO and VP of Engineering. So, the 3 critical things I needed to accomplish before the weekend started was making sure I stacked the deck in my favor with some talented people, had a toolbox ready with possible solutions to the technical challenges we would face, and had stakeholders present to make decisions.

Given the new technology stack, I needed to recruit folks with some very specific skills. To enable that effort we recruited the leader and founder of the Lift project, David Pollak. He helped us motivate a few people with experience using the technology. We also had the SnapImpact team actively recruit their friends. The result was a very high quality team capable of getting the job done.

When the teams started work, they would spend too much time investigating everything unless I gave them a starting point. By bringing some ideas (not solutions) to the table to solve their problems, it helped define their playing field and allow them to make a decision quickly. Implicit in this was understanding the known business problems that needed to be solved.

We knew we would hit roadblocks during development waiting for business input on implementation details. So, we made sure to have some present the entire weekend. One of the stakeholders even brought a developer who was using the existing system. We embedded the dev in one of our teams working on implementing some external interfaces. Yes, that really accelerated the implementation decisions. Also, the stakeholders were really disappointed with certain aspects of the existing system. We had ideas to resolve those issues, but needed to ensure they met the stakeholders needs.

Thanks Dave for the great details on this event and example of agility at work!

Once upon a time, Frederick Winslow Taylor and W. Edwards Deming lined up across a ping-pong table and went at it.

“There is only one correct way to do any job!” said Taylor, smashing one of those real curvy, tricky serves at Deming.

“Let people contribute in the best way that they can envision,” retorted Deming as he calmly returned the serve from 8 feet behind the table.

“Employees are evil and lazy!” screamed Taylor as he sliced a murderous shot high into the air, the backspin causing a local singularity in the spacetime continuum.

“The success of the company is good for all, and people want to succeed,” offered Deming, backhanding a low shot with sideways spin just over the net.

“Managers are the ones that know the answers!” shouted Taylor, cutting his forehand all the way across the table.

“Hmmmmm,” said Deming, who could be a very thoughtful guy given the right circumstances, “the people closest to the problem are more likely to come up with a correct answer.”

“Supervision!”

“Empowerment.”

“Punishment!”

“Trust.”

And on and on. They never did finish the game.

Here’s the interesting thing: we’re still playing this ping-pong game.

Here’s another interesting thing: many people don’t seem to know it.

Many people make the mistake of viewing Scrum and Agile and Lean as sets of practices. “If I do kanban, I’m Lean.” “If I do sprints, I’m scrummy.” “If I do BDUF and most of my projects are late, then I’m waterfall.” (Oops, well, the last one is actually true, but the first two aren’t.)

The thing is, you’re not Lean unless your company commits to the two pillars of Lean: continuous improvement and developing people. You’re not Agile unless you create and foster self-organizing teams. You might be doing a lot of Agile practices, and you might even get better results than you used to, but you won’t be Agile. If you accept this limitation and you are doing Scrum, then you will be doing ScrumBut.

So I smile to myself (I think it’s to myself) when I hear management say things like “We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all. Lean and Agile fit into the framework of Deming’s System of Profound Knowledge. Plan-driven, hierarchical command & control methods descend from Taylor. You can’t follow both at the same time.

Really? Yes. Would those managers supervise and micromanage some employees while supporting and developing others? Would they dictate commitments and solutions to some while allowing others to determine their own fate? Would they trust the people on the Agile projects and punish the ones on the waterfall projects? Would they hold individuals accountable on waterfall projects while holding teams accountable on Agile projects?

Of course not.

What they will do is treat everybody the way they always have. They will beam with pride when teams gather in their little circles every day, and then they will dictate to them that the manager is actually still responsible for delivery and ask for lists of who will be assigned to which task in the next sprint. They will refuse to make priority decisions and instead direct people to work on multiple projects at a time, and they might even decide just how many design documents each team should have. They will do this because that’s how un-Agile projects do it and for some reason this makes management require it of all teams. (What has always seemed odd to me is that they won’t demand that waterfall teams release an increment of working software each month because the Agile teams do it. So I guess it only works one way.)

And they’ll wonder why this Agile thing gets so much hype, since it really doesn’t seem all that different from what they’ve always done. And really, the results aren’t that great.

You can’t be both Agile and not Agile. You can’t be both Lean and fat…er…not Lean. Not at the same time.

If your company is not fully committed to agility then you won’t achieve it, and your results will be a self-fulfilling prophecy of unrealized potential.

About the Author: Alan Atlas is a Soul Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

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:

1. Number of people to whom you ask to describe “Agile”  = Total number of Agile mental models  + or -  2
2. Distributed teams need love and a ScrumMaster at each site
3. A foosball table may be one of your best Agile tools
4. Geography is more than a timezone issue; it needs infrastructure support
5. It’s massively worth the effort to stay engaged in the Agile community through local events, online lists, conferences, and casual meet-ups
6. Having a Product Owner is non-negotiable
7. Avoid Cargo Cult Scrum at all costs!
8. Agile teams need to have fun
9. The best Agile teams and companies rely on Servant Leaders
10. Embracing a real Agile culture is often more than one team can create on its own
11. Agile development can only cut costs if you are willing to spend time and money on it
12. A great approach to agile maturing and scaling is Flow Pull innovate guidance from Lean
13. Burndown charts are about the team commitment to doneness, not about individual performance or time tracking
14. Ensure your sprint backlog reflects the delivery of product value
15. Escalation doesn’t serve either the Agile or Lean community in continuous improvement of practices
16. You need to have more than checkbook buy-in from your Executive to be successful
17. Mature your Agile team practices before attempting to scale to more teams
18. Not having a clear signal to end your stand-up can lead to problems
19. The Lean principle on Flow guides Agile teams on how to tighten up their practices
20. Get everyone in your Release Planning meetings if you want true commitment to the Release’s vision
21. Command-and-control ScrumMasters reduce the intelligence of their teams
22. Co-located teams move to being high-performing, high trust teams far easier and far faster than non-co-located teams
23. Frequent communication through site visits, IM, Skype, email, Facebook, Yammer, video conferencing and other technologies help distributed teams gel and feel the love
24. Agile teams invite healthy conflict in order to become great, enduring teams
25. Velocity: it’s about the team not the individual
26. Kanban is helping teams find new measurements for constant flow of value -  so let’s pay attention.
27. No product owner or too many product owners add up to the same Agile adoption smell: no definitive decision on ranking or acceptance
28. A Product Council is an effective way to manage stakeholders and minimize backlog churn
29. Story points help teams separate calendar hour and number of team members from the story’s complexity, effort, and doubt
30. Stories have relative sizes to one another; only tasks take on effort estimates
31. A well-written story (small, about benefit to a role) doesn’t lie; requirements do by their shear volume of content
32. A product backlog is ALWAYS ranked
33. A product backlog is not a task list; tasks only appear after estimating and planning by the team
34. Agile improves the quality of life for employees
35. Great teams are made of collaborative team members
36. Agile doesn’t create the messages it exposes them
37. Pair programming raises team awareness and code integrity
38. Use consensus, not forced compromise or command and control, to gain full team commitment
39. Effective team meetings require structure and discipline
40. Commit to Agile values and principles; your practices will follow
41. Transparency is an Agile virtue not a punishment
42. Agile is about commitment not tools; tools support those commitments and make them visible
43. Product owners who make their decisions in a vacuum are not Agile
44. Agile teams invoke respect and kindness even in stressful times
45. Teams that don’t retrospect are not Agile
46. Retrospectives are not about blame
47. Retrospectives bring continuous improvement of process and working agreements
48. If you don’t have team working agreements, create them now
49. If you don’t hang your team working agreements on the wall, put them up there now
50. Aggressively cap your utilization capacity until you know your velocity
51. Blog your Agile experiences; more people want to hear them than you think
52. Test driven development doesn’t just create better code; it creates better conversations that create better acceptance
53. Agile Architects and Product Owners work side-by-side to rank product backlogs
54. Give your Agile teams a break such as a “hackathon” built into the cadence of the team’s release schedule
55. High capacity utilization is deceptively evil
56. Quality is everyone’s responsibility
57. Small increments quickly inform us about our work and produce feature sets faster
58. Lean has had a great impact on my Agile language
59. “Hiring the best” can be yet another cliche in Agile
60. Hire wisely not cheaply
61. When hiring new members, team consensus is a must
62. Use 5 levels of planning: Vision, Product Roadmap, Release Planning, Iteration Planning and Daily Planning
63. Release planning is one of my favorite Agile activities
64. Teams and stakeholders invite release planning to see beyond the next iteration
65. FYI, good brainstorming requires lots of post-it notes and sharpies
66. Pay attention to your facilitation skills so that you don’t takeover decisions and don’t let others do the same
67. Keep Agile meetings focused, stick to the purpose and timebox
68. Turn your electronics off in Agile meetings; focused meetings are productive and end on time
69. The biggest cost cutting lever in Agile is prioritization
70. Don’t be afraid to try new practices; your velocity and quality may thank you
71. Agile is useful beyond software; take it up and out the organization
72. Old tools stand in the way of new tricks; MS project is not the way to go Agile
73. Team identity is important, individual heroics are dangerous
74. Individual appreciations in retrospectives are a great way to create space for the growth of Agile team trust
75. Agile maturity is NOT about a CMMI-like maturity model
76. The war between Agile and Waterfall is over; get on with your continuous delivery of valued items
77. Agile asks us to slow down in order to speed up; just do it
78. 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.