Subscribe to ...considered harmful        RSS Feed
-----

Kaizen Diary: Tickets For All Work

Icon Leave Comment
Kaizen: Tickets For All Work (Sprint 6)
(an entry in the Kaizen Diary)

This was the first kaizen for our team that I have a record for. Right away, you can see that this is a team with some issues: the most important improvement we could come up with was that we follow one of the most standard pieces of developmental rigor, and require that all commits to the repository be related to a ticket in the issue tracking system.
Let's pause for a moment. If you're a new developer, in school or just fooling around with code on your own, this might not be quite as mind-boggling for you as it ought to be, but this is really not a good state for a team to be in. If you're working with a team of people, and they are all making improvements all at once, it is vitally important that you be able to understand what work is being done and why. If you're a team trying to work together, it's important that you have some idea of what work is outstanding, and to agree on roughly what needs to be done next and what can wait a while. If you're using a code review process to ensure that incoming commits meet the project's standards, it's vitally important to know what a commit was meant to accomplish. And if you're trying to justify the expense of a herd of developers, you really want to be able to point to concrete work that they're producing to earn their keep. All of this means that no work should ever be done unless it is in response to some ticket, which has been entered by a user, vetted and estimated by the team, and scheduled by some responsible party. This is basic to modern software development.

To find that we had to say this aloud, then, should make you think that there was something weird going on. And indeed there was something going on, but in fact it was surprisingly normal. What was happening at that point in March was that our team was in massive transition.

The codebase we're working on was originally developed by a guy who I'll refer to as Karl, since that's his name. Karl pretty much came up with everything we're working on today, with occasional help from contractors, and he worked more or less without process, and around the time that I joined the company he was setting up a team to replace him so he could move along to some other important stuff. As a one-man shop, the benefits of strict adherence to process were, let's say, less than obvious, and there wasn't really any apparent need to worry about things like issue tracking or code review. When code was written and tested, it went into the repository, and if it got borken, it got gefixed. This worked great - for one person. It worked less well for the three-person team that I joined in February, and by March we had determined to establish a more team-oriented process, and this was the first step towards that.

It's appropriate, then, that this is the first kaizen for our team, since it more or less marks the point where our team really took ownership of the code. A few weeks after this, Karl's active involvement with the organization ended, and we were off and running.

0 Comments On This Entry

 

Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

October 2017

S M T W T F S
1234567
891011121314
1516 17 18192021
22232425262728
293031    

Tags

    Recent Entries

    Recent Comments

    Search My Blog

    0 user(s) viewing

    0 Guests
    0 member(s)
    0 anonymous member(s)

    Categories