Now that Agile has become mainstream, teams are looking to go beyond their Agile process to find ways to improve. There has even been recent use of the term “Antifr-Agile”, where process is secondary to product validation and customer learning (AgileDayChicago, 2016). Here are 7 ways that your team can go beyond your Agile process.
I’ve been pairing for over a decade. I’ve witnessed and tried all kinds of things shoulder-to-shoulder with all kinds of pairing partners. Through the years I’ve witnessed a single consistent misfire while pairing. We don’t understand our roles. As professional problem solvers we gravitate towards actively solving the problem at hand.
In a previous post, I mentioned that in order to have a successful DevOps experience, there were some key components and principles that need to be implemented. In this post, I’ll cover those components in more detail.
What I want to cover in this post is the experience that I had transitioning from a traditional development role to DevOps and what I learned to be useful in that transition. One of the nice things that I experienced with DevOps was that it pushes developers to take more ownership of their application because they are living through the pains and difficulties of running the application which in its turn pushes them to make running the app easier.
Wikipedia defines DevOps as:
DevOps (a clipped compound of “development” and “operations”) is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.
I like to simplify this definition by saying that DevOps is when you’re not only responsible for developing the application but you’re also responsible for running and supporting the application in your testing and production environments. As opposed to the traditional way of developing where you have the luxury of developing the application then throw it over the wall to the Ops team.
About a month ago, I facilitated the first event as part of the Source Allies external mentoring program known as Source Allies University (SAU).
It was an interactive forum and networking event designed to:
- Cover basics and explore new tricks of Test Driven Development (TDD) in Java
- Create new code & refactor existing legacy code via TDD
- Code through a sample project for hands-on experience
One of the tenets of the agile methodology is feedback. To provide value to your customer, you need to know that what you are delivering is correct. But as an agile coach, I often struggle with teams understanding the importance of getting feedback from the customer as soon as possible. One way to get teams to understand is to use an analogy – cooking.
After years of being immersed in Java development, I must admit that I got spoiled by its strong and mature ecosystem. Hence, whenever I want to pick up a new technology or programming language the following must be there:
- Support by my favorite IDE (Eclipse or IntelliJ IDEA)
- Mature building framework. It does not have to be Maven or Gradle but it needs to be at least better than Ant.
- Easy TDD. This could be the trickiest one to achieve because not only do I need a testing framework, but it must also be supported by my IDE and build tool. Moreover, it must have an adequate mocking framework.
Groovy easily satisfies those criteria right out of the box. It has awesome support by IntelliJ IDEA, Gradle is written in Groovy and you can write JUnit 3-style unit tests.
If you have ever practiced test driven development (TDD), then you are probably familiar with the TDD mantra – red, green, refactor. I’m a big proponent of TDD, but I think the TDD mantra is missing a fourth step.
For years, like many of you, I have been comparing software development to construction. But ever since adopting the agile methodology a decade ago, I have been looking for a better analogy to help me explain agile software development. I recently came up with what I think is that analogy – urban planning. Read on to see if you agree.