Top 10 Lessons Learned From 10 Years in Agile

I recently had the chance to catch up with Robert Holler, the CEO of VersionOne, an Agile tools and training company that recently celebrated their 10 year anniversary and a new release of their agile platform.  Robert and his colleagues got together earlier this year and discussed the lessons they had learned through ten years of insight into agile software development.  "Hopefully we've learned more than just ten lessons," Holler told me humorously.  He said that these were just many tiny lessons boiled down to 10 big ones and without further ado, we got right down to discussing the insights…

1.  Simplicity is Sophistication.  

Given the complexity of software and the people that make up software organizations, there needs to be a constant focus on simplicity and cutting out what isn't absolutely essential.  Agile, while conceptually simple, is quite difficult. For all but very small teams in a room, it’s more about organizational change and complex communication networks than changing to Sprints and daily stand-ups. It also requires multiple, different business functions to change the way they work together; including business stakeholders, product planners, developers, testers, etc.Agile, while conceptually simple, is quite difficult. For all but very small teams in a room, it’s more about organizational change and complex communication networks than changing to Sprints and daily stand-ups. It also requires multiple, different business functions to change the way they work together; including business stakeholders, product planners, developers, testers, etc.  

Holler also said that when they were building their agile platform, it would have been easy to fall into the trap of building little extra features for each unique customer request, but they didn't.  It reminds me of a programming language that tries to solve every problem - they gradually become a nightmare to use.  

2.  Define your Rhythm.  

What are you doing on a daily basis so you don't have to have a ton of ad hoc meetings?  That's the main question you need to ask yourself in order to start cutting down on wasted meeting time.  Don't have someone ask a question and just start a meeting, wait until the predetermined meeting times.  It will force people to be better prepared for them and to get their points out quickly and concisely.

3. Agile is Fundamentally About Discipline.  

Holler has heard Agile described as undisciplined or ad hoc.  Sometimes even 'Cowboy Coding'.  He said that truly agile teams are exactly the opposite.  The truth is that agile teams are only successful when they thrive on automation and are very disciplined. The best agile teams display much more discipline than most other teams, especially in the areas of planning, unit testing, test driven development, continuous integration, and test automation.

4.  Software is Hard to Scale, Agile is Not.  

Skeptics suggest that agile does not scale well.  In truth, it’s more that software development does not scale easily – especially if a shift in organizational mindset hasn’t taken place or if there a lack of discipline. Agile is as good as anything at scaling to multiple teams, projects, programs, and portfolios.  Focus on business goals not the little things.

5.  Think of the Big Picture.   

Start big, and then start to think about individual features and bugfixes that you will complete.  Systems thinking is important here.  Long-term agile transformation success requires a consideration of the system as a whole before making changes to its parts, or else the change will likely be fraught with risk.

6.  Lose the Religion  

Initially you should try to be an agile purist, but do what makes sense for you.  It's important that you distinguish between compromises that must be made, and other cases where you just need to be more disciplined.  

Apply agile practices internally and see which ones survive.  NASA, for example, would need to do all it's iteration and testing on the ground and understand that refactoring can't take place anymore once the software is launched into space.  You need to adapt agile to your need.

Your dev team might also operate on different cycles than the business side, so you need to work with that difference in rhythms and get both sides as close to agile iterations as possible.  This can also make it tough to do automation, but most devs find it beneficial to have some agile practices rather than none.

7. Continuous Focus on Business Value.

Many agile teams get caught in the weeds of a technical story's delivery and velocity at the expense of overall business value, company and project goals, and customer experience. Learn from this mistake -- don’t do it.  People in the team need to focus on the bigger picture in order to minimize project confinement.

8. Agile - It's Not Just For Software Anymore.

It's actually conducive to the agile transition of a development department if other parts of the organization (Ops, Business side) can also make transitions in their teams to being more agile.  It's easy to find success stories of agile methodologies in business units, system administration, and even design/UX.

9. Continuous Planning. 

Winston Churchill said "Plans are of little importance, but planning is essential.”  Plan on a daily basis if possible so that the adaptability is inherent in the day-to-day workflow.  Keep your focus on maximizing value.  Product roadmaps must be adaptable to the tactics of agile, but roadmaps remain an important mediator between tactical trends, and the long-term vision for the product.

10.  Doing agile and being agile aren’t the same.

Sometimes you don't do "Agile" but some people as agile as you've ever seen.  You should be doing agile but you should also 'be agile' which includes things outside "agile."  These are the little things that individuals do each day to be more efficient.  

Hope these refresh your view on what it means to be Agile.