Room Full Of Jello
At my former taekwon-do do-jang, we would sometimes be asked to perform our patterns (katas, prescribed sequences of moves everyone learns as a rite of passage as they progress through the ranks) as though we were in a room full of jello. In a room full of jello, you have to slice your way through. Everything has to be deliberate and powerful.
Right now, work feels like that.
In some ways, we have a long way to go. The Old Guard cut their .NET teeth on our application, and thus learned a certain agglutinative approach to software. Over time, this has lead to what I saw one blogger refer to as a House of Cards architecture. There is genuine and real fear about improving the application. It’s a data-driven house of cards, with a staggering number of possible configurations.
Management saw the problem coming, so they hired some New Blood, of which I am one. Although I don’t have a computer science degree, I have a mathematics degree and thus computer science, test-driven development, agile, and object-oriented design make perfect sense to me. It’s clear the application is in need of some love.
So I’ve championed these things. I spearheaded Scrum and agile methodologies. My cohort and I tout the benefits of testable design and unit testing regularly.
Recently, I created a design review checklist in the hopes that reviewers would point out these design errors and that things would slowly get fixed. I recently got the chance to look at some code while doing my first review.
And I feel I am back on the gym floor, moving through jello. There is so much left to do.
Scrum is faltering because our teams lack the discipline or the understanding to really do Scrum justice. I’ve volunteered to teach a scrum mastering seminar to address that. Projects are not quite done. People aren’t getting involved. Scrum masters are managing, not facilitating. All the classic traps.
And I’m falling in too, so I browbeat another experienced Scrum man into helping our scrum master challenge us to do better, because we’re by far the most successful team.
Our application is getting increasingly harder to maintain and harder to enhance because of legacy architectural decisions and poor execution. After having features fail to meet the approval of our stakeholders because of our lack of understanding, we’re spearheading domain-driven design. We have a lot of people curious. After introducing OO via the book “Clean Code”, though, I haven’t seen the lasting impact I’d hoped for. People say they are too busy to do test-driven development or proper design, because “we have to get things done!” I worry the same will come true of DDD.
Another factor: we have a very nice man who joined us recently. He’s nearly deaf. We’ve been trying tossing a koosh ball in meetings so he can follow who’s talking. It’s met with limited success, but our discipline in passing the ball is lacking.
The jello is solidifying around me. I fear I will run out of ideas or steam before I see any relief.
And now a new factor: distance. Another far-off branch of the company is going to become integrated with our team. So we need to figure out how to make our Scrum process work smoothly for people thousands of miles away. Fortunately, time is on our side: they are in a similar time zone. All of the magnet boards and flip chart presentations won’t do us a lick of good.
The company made an investment in Team Foundation Server, but my initial experience wasn’t positive. I quickly got to a point where the Scrum templates wouldn’t load on my machine. Even so, I found it to be clunky, and with only a Visual Studio interface (which onlhy our developers have), it’s not an inclusive solution. I’m thinking about Pivotal Tracker, BananaScrum, or TargetProcess.
Any ideas? Encouragement? A spoon? 😉