Thanks First
First I would like to thank Paul Klipp for inviting me to be a part of the first annual AgileCE conference – as a speaker, as part of the program committee, and as a sponsor. I felt the conference went extremely smoothly. Registration lines were non-existant (with a full house), coffee was flowing all day (perhaps most important for me), the Internet never slowed down (another very important item), and the caliber of the speakers greatly exceeded my expectations. Krakow was a fantastic city in which to hold the conference, and no one let a little rain stop them from having a great time. I look forward to being a part of the conference again next year.
Another Paradigm Shift Occurs
I feel that mechanics are easy. The mechanics of Scrum are easy. The mechanics of Kanban are easy. It is when we inject people into the equation, which we do at every level of Agile projects, that the situation becomes infinitely more complex. It is the interactions between team members, including managers and customers, that make an already complex process even more so. Trying to get everyone on the same page and adhere to a process that has been collaboratively created, is challenging. It is the psychology behind all of it that makes software development very fun.
How do we help customers explain what they want in terms we can understand and turn into quality software that will help them? How do we work with each other to achieve quality and a pace that reduces business risk and increases output? It is questions like these which we continuously seek to answer. Answers that change the more we learn and the more we experiment.
The last paradigm shift I went through was while attending David Anderson’s Kanban Coaching Workshop in Miami. The latest was during the AgileCE conference. Hearing speakers like Pierluigi Pugliese speak about approaching a problem from the solution rather than the cause, Andrea Provaglio discuss how organizational systemics can be used to give roots to a team and enable self-organization, and Monika Konieczny use games to not only show the breakdowns that can occur in communication but how we can fix them, showed me that as project leaders we need to continue to learn better ways of helping our teams work together and create a culture that fosters this.
Bring Your Idealism With You
I removed myself from the world of corporate IT many years ago because I felt that IT professionals did not get the respect of the rest of business, regardless of the fact that if all of the computers in the company shut down, the business would cease to exist. This attitude is still very strong in many organizations. As Andrea said in his talk, we have treated software development like a factory. This is what we are most familiar with, the most comfortable with. And therein lies the problem. Software is intangible. If we were pumping out widgets, we could apply known project management methods easily. However this is not the case. Yet company after company continues to operate the factory, and project fail.
Maria Diaconu and Alexandru Bolboacă spoke about software craftsmanship. This movement is growing in the United States and Europe. It is my hope that through this movement we can help show that software development is a profession with standard to which we adhere.
I am sure many of you are familiar with what happens though when deadlines are looming and there is much work yet to be done. Testing falls off, QA gets behind, and there’s a mad rush to get the project out the door. And once it is, bugs are found, clients are upset, and even more work needs to be done to repair both code and relationships.
The irony is that if we start from the beginning with quality and collaboration in mind, we have a much greater chance of success. I believe that this is at the heart of the software craftsmanship movement.
I always wonder if I’m too idealistic. I see so many companies – not teams but companies – easily sweep aside quality in order to avoid having the hard conversations and renegotiate timelines. This doesn’t have to be. If we communicate throughout the project, honestly showing progress, and see it not as good or bad but how it is, those conversations can be easier. What I learned at AgileCE is that there are many ways to approach these conversations and keep them positive rather than focusing on the negative, which we tend to do, all the time.
So I won’t stop being idealistic.
I know there is a better way, and so do many others. It is those others that I want to work with. There are many teams that not only care about the quality of their work but have management that allows them to do so, and helps them to improve. Sometimes people just need help to make the case for it.
Words Without Action Are Hollow
I was never taught in my computer science program how to make the business case for doing things one way or the other. TDD, continuous integration, pair programming, and other XP practices were words I only learned a few years into my software career. We all know about them now, though sometimes it is hard to explain (to management) why we need to take the time to use them, using words that they can understand. And that starts to really scratch the surface.
Help is on the way.
Closing Thoughts
AgileCE was a great conference to attend, and one that had a great and lasting impact on me. I was happy to be able to represent the United States, meet a lot of great people, and learn much more than I ever expected to.
If you haven’t been to Krakow, next year may be the time to do so. And AgileCE will be a great reason to go. Sell that to your manager!
Pictures From The Conference
Other Posts That Might Interest You
