Skip to content

Room Full Of Jello

4 February 2009

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? 😉

Advertisements
6 Comments leave one →
  1. 5 February 2009 12:37 am

    ““we have to get things done!”

    How can this be the case? Developers select the stories they work on. Only they decide what to do in the next sprint. Empower them. Tell them it’s only them who decide what do do. Protect them from management. Help them be free for their decision what they can do in the next sprint.

    1.) Play Scrum by the book.
    2.) Play Scrum by the book.
    3.) Instill a pride of professionalism into the developers. Only from there flow practices like TDD, acceptance of a level of done agreement, refactoring, beautiful architecture, quality! This doesn’t come from Scrum.

    Stephan

    PS: Perhaps I forgot to mention: Play Scrum by the book.


    Programming is hard – http://blog.codemonkeyism.com
    http://twitter.com/codemonkeyism

    • neontapir permalink
      5 February 2009 9:29 pm

      @codemonkeyism: I hear ya. I’m not sure whether developers understand their part in things — and I’ve been guilty of caving to the pressure to squeeze in one more feature, to my inevitable peril. Other developers seem paralyzed, looking for direction.

      I was reading Beck’s XP Explained, and in the beginning, he talks about values vs. practices. I think in some people, we have good practices, but no values, leading to blind adherence to rules without understanding. In others, we have good values, but poor practices, leading to people who’s heart is in the right place, but who don’t know how to proceed.

      I’m going to explaining the reasoning behind the practices with the goal to install the values. I’ve also instituted a “design review checklist”, with the goal to provide feedback to allow folks to improve their practices.

      Stay tuned, and thank you very much for the pep talk!

  2. 5 February 2009 1:48 pm

    People say they are too busy to do test-driven development or proper design, because “we have to get things done!”

    Let management know that if they don’t budget time for test cases in current development then they need to budget twice as much time for bug fixes and code analysis for features in the future.

    Our office just got a capture device for a whiteboard. It’s pretty slick — it captures your whiteboard activity as you draw; you can save it for later reference or email folks. And with Webex or other screen-sharing programs, the remote peanut gallery can watch the whiteboard as you go. We’ve also got a motion-tracking webcam, though I’m not sure how often it gets used (I’m not on a team with anyone remote).

    As humans, communication is easier face to face, so limiting that ability within a team is a cost to consider. Our successful remote employees are proactively very communicative — IM, email, lots of phone calls. If you’ve got enough folks, IRC might be a good option.

    • neontapir permalink
      5 February 2009 9:32 pm

      @Trevor, thanks for stopping by. We’ve just reached the maturity stage where we’re executing most all the test cases we’ve identified. The issue there is that we have so many permutations of usage that we can only see a fraction of them. Users use the software in ways we don’t understand in-house. I’ve been pressing for more involvement from our customer representatives, and have an ally in management to help make that happen.

      I will definitely bring the whiteboard technology to the attention of the team. Neat stuff!

  3. 5 February 2009 11:10 pm

    I’m staying tune, I’m interested how it plays out. Scrum is easy to understand but hard to get right.

    Best wishes
    Stephan

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: