One of the primary reasons for writing this book was to share my experiences from over six years on Agile projects and, ideally, to help other development teams learn from others’ mistakes. I’m a big believer in learning from others’ experience and not repeating the mistakes and going through the same pain. On several Agile projects, I’ve see new teams refuse to ask more seasoned teams for advice. Perhaps they just wanted to learn on their own and not be influenced by others’ experiences. Maybe they thought they had all the knowledge and tools they needed to be successful. But, inevitably, I would hear them go through all the same pain that other teams had gone through and long since learned from. That’s why I wanted to share these stories. Not every team is the same and not every scenario is covered here; that could never be the case. There is no right answer and the thoughts about each story are just my opinions and based on what I have personally experienced.

Even if you read through the stories and don’t agree with my views, I hope this book has made you rethink some of the things your organization is doing and has given you some ideas of things to try. It is not meant to be a step-by-step guide. Ask any Agile Coach how many times he or she has been asked, “Are we doing Agile right?” Everyone wants to know “the steps to doing Agile the right way” and wants a clear set of steps and tools that will make them “Agile.” I know I was guilty of wanting such a clear and concise answer when I first starting using Agile. But what you learn along the way is that it is not about process or tools; rather, Agile is a way of developing and delivering software. It’s about values and a set of principles that guide the way you develop and deliver software. These values and principles are rooted in the Agile manifesto and how you achieve them will be different for every team.

There is no single value or principle to focus on, but I think some are more critical than others. If I had to focus on three areas more than any other they would be collaborating, morale, and testing.

The importance of collaboration cannot be overstated. Having great teamwork on the Agile team and open communication with the Product Owner are vital. If everyone on the team knows what is the others are doing, then people can share ideas, reduce duplication of effort, and swarm to keep everyone moving forward. Having open communication with the Product Owner (or business in the more general sense) is also key. It means you are being transparent and that allows the Product Owner to prioritize work. It also means the Product Owner knows exactly what the team is doing and there shouldn’t be any surprises at the end of each Sprint.

Whether you are using Agile or not, morale is always important. But when using Agile software development I would say it is more important, or at least changes in morale are more visible. On a Scrum team, for example, when the morale of the team is poor, velocity usually suffers. Velocity can suffer because of more defects being introduced. Hence more time is spent on defects and less time is spent on User Stories. Of course, negative morale is never a good thing and can have more effects beyond the Scrum team. I’ve seen some really amusing things done to developers that killed morale: everything from one manager giving us three-day-old donuts as a reward to an executive stating that developers wanted to work late so they could get free pizza. Of course, these are minor things, if not funny in hindsight, but the point is that things like this can hurt morale. One thing I’ve done on some Scrum teams was to have a “Sprint rock star” award. The team would vote anonymously every Sprint for the person who should get the award. It really helped to keep morale high and show that people on the team were appreciated.

A lot of organizations talk about how they are “Agile” because they have set up CI. While CI is a first step, it is often not the last step in being able to deliver quality software. Unit testing is critical and a must for CI to have any value. But if teams want to have a high level of confidence that what comes out of the CI pipeline is potentially shippable, then a serious investment in testing is required. Without automated tests, it means a lot of manual testing and very low confidence that the software is working as expected. Unit tests are one part of automated testing, from a CI pipeline standpoint, but functional tests are also important. Just because unit tests pass, that does not mean your application is behaving as expected. That is where BDD comes into the picture. I am a big believer in BDD and the value that it provides an Agile team. With good unit tests and functional tests, a team will have much higher confidence when everything passes that the software is working as expected. But creating automated functional tests and maintaining them takes a lot of investment. I’ve been on several Agile projects whose leaders were not willing to make this investment and paid the price for years in terms of high defect counts and bad user experiences. I’m not talking about writing a functional test for every feature that is developed, but you start with the most critical aspects of your application and then add tests as you find troublesome areas.

BDD, CD, and automated functional testing are all important areas to think about. Each is a big topic on its own, but I believe it is critical for an Agile team to understand these topics and see how they can improve software quality, time to market, and overall confidence in the software that the team is delivering to the business.

References

Adzic, Gojko. (2011, June 6). Specification by Example: How Successful Teams Deliver the Right Software. Shelter Island, NY: Manning Books.

Fowler, Martin. (2010, October 29). FeatureToggle [bliki]. Retrieved from http://martinfowler.com/bliki/FeatureToggle.html.

Humble, Jez and David Farley. (2011). Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. New York: Pearson Education.

West, Dave. (2011, December 15). Analyst Watch: Water-Scrum-fall is the reality of agile. Retrieved from http://sdtimes.com/analyst-watch-water-scrum-fall-is-the-reality-of-agile/.