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.
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.
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 reminded of a profound truth as I was re-reading Robert C. Martin’s book “Agile Software Development, Principles, Patterns, and Practices”, in C# this time.
It is not wise to apply (a) principle … if there is no symptom.
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.
By David Kessler and Cecil Williams
Is it really possible that intense planning and the ability to respond to change can co-exist within the same development process? If you are wondering this, then you are not alone. Clients regularly ask us if Agile software development teams follow any sort of plan or are they just feel good, free for alls? In this article we explain the types of processes that can be adopted to allow your teams to plan while still responding to change.
ThoughWorks Studios has released an ebook titled “How do you estimate on an Agile project?” where they explore common approaches and their adaptions from real-world projects. The book is comprised of several authors, most notably Martin Fowler. In this ebook they discuss why teams estimate, different methods that teams use to estimate, and provide a couple of case studies.