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.
Source Allies is proud to be involved in many charitable endeavors such as dsmHack, Hyperstream and Tech Journey. Tech Journey is a 501c(3) non-profit founded in 2013 by my friend Tony Kioko and my teammate David Kessler. Tech Journey was created to inspire youth with limited resources in Des Moines to increase their knowledge and interest in technology by providing engaging learning opportunities led by technology professionals.
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.
I convinced a client to upgrade the computers we were using for software development. Maybe this article will help you convince your manager to do the same!
ActiveMQ is a great messaging broker. However, using the default configuration is not recommended. This article will explain how I determined the appropriate ActiveMQ memory settings for one of our clients.
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.
I was able to attend the Agile 2013 conference in Nashville, TN earlier this month. I had previously attended Agile 2006 in Minneapolis, MN. There was a significant difference.
At this year’s conference, the overall theme seemed to be that teams needed to focus on producing value rather than following a process. Most of the attendees have figured out that the process will only get you so far. At that point you have to figure out how to improve what you are delivering, not what you are doing.