Meta

A few years ago, my team got into Open Source. Specifically, we started writing all of our apps on github (as opposed to our SVN). We wanted to do this because we wanted to invite scrutiny. We never expected people to look at our stuff, we just felt that by putting it out in the open, we’d want to do better internally.

We went whole-hog. Organized stories with issues, organized sprints with milestones. It was pretty hot stuff. And it was all in the open. Potentially, someone could come by, see what we’re doing and offer to take a story from the backlog of issues. That’s open source. ish. We have a lot more we can do. A lot of growth to do.

Then we started using Jira. The board system within Jira Agile was excellent. Allowed for better organization, reporting!, and visual representations of work. It’s great. It’s Agile. But it also replaced what we were doing with Github issues.

We essentially replaced Open Source in favor of Agile. Our organization is great, we’re keeping track of things fantastically, but we’re no longer open. We don’t have transparency on what we’re working on anymore. People can’t potentially help. Our code is out there, but we’re not inviting. Our process is no longer out there.

So what’s our solution? We don’t have one yet. But what /can/ we do?

We need to put our vision statement out there. We need to put our plans out there. We need to expose what it is we’re doing. We also need to stay agile, keep our tools intact, keep our reporting.

This means we probably need to be duplicating efforts. Open Source and Agile are both hard work and organization. That they can’t line up and be the same effort is not a blocker, just an “oh well”.

What I take away from agile is the idea of putting something in front of a client as quickly and as often as possible. Of course things are going to have flaws, and things may be unfinished, but having the client see what you’re doing gets a sort of course correction done that doesn’t happen in a vaccuum. People tend to understand this, but they don’t often abide by it.

The problems I’ve seen lately have been in the instance when there is no client directly involved in the process. In that case, a product manager is assigned to take on the role of client, someone who mostly understands what the client wants and basically be their advocate. But the product manager, being an employee and not a client, doesn’t want to risk releasing an incomplete project for fear of how that will look or how the client will react to that. Therefore purposely not involving the client in the only part of the process where the client could give direct feedback — in production.

As long as it’s explained to the client that they are dealing with an alpha, and we welcome feedback on things they feel are necessary, it seems they could be used at that part of the cycle to offer feedback and keep features that will never be used from being added to the project and keep the project from straying too far from something they don’t want.

I had the pleasure of trying to work on 3 separate agile projects last sprint. I typically get 40-50 story points done in a sprint. I like to take on more than I think I can do to keep myself from letting work expand to fill time. I also had the issue of having to take on another developer’s work. Total, we promised ~80 story points.

Now, when my kid was new and I wasn’t allowed to sleep nights, I was able to cram 70-80 sps into a sprint. But sleep has made that level of productivity very hard.

I was also tasked with working offsite, organizing a community of practice, and trying to learn a very large project through “osmosis”. Which is to say, learn as much as you can without reporting time spent on it.

I have to admit, all of the work is interesting and the clients are all people I personally don’t want to let down. So it’s hard to say “forget project X”. (Which is hard to say generally when there actually is a project X.)

So with many things pulling me in many directions, my completed story points for the sprint was 33. A significant decrease in general productivity.

Context switching needs to be allocated for in sprint planning. Duh?

The trick is how much? Some people say it takes 15-30 min to effectively context switch. That’s part of it. I think the larger part is when you’re focused on one-two items, you can finish things effectively. The more items, the more you end up with partial work. Partial work is the worst time killer. You get 50% into a feature and if you have to stop and start again it magically turns into 30-40% done.

Solution? Don’t switch contexts.

Har har. Work on something to completion before switching contexts. Be strict about it.

A few months into our switch to a more agile process, it became apparent that we still weren’t able to find a place for documentation in our sprints.

At first we had the idea that we would add a task to each story that would cover documentation. We found that we would end up writing docblocks and general code documentation but actual user documentation never got written. But we did that before so we really weren’t getting done what we were trying to get done.

Our next attempt was to set aside a day at the end of the sprint where we would write documentation or finish up stories that were not done yet. But I’m not sure how other people are doing point allocation in sprint planning but I think the ideal is to try to go just a little over the to of what you’re capable of. That keeps you working hard. At least for me, if I know I can do 50 points in a sprint and I schedule 40, I will get 40 done. Work expands to fill time. My point is there is always work to get done on the last day of a sprint. Scheduling documentation within the sprint separate from story points just doesn’t work.

That brings us to documentation stories.
As a developer
I need to document this functionality
So I can easily refer back when there is a problem in the future

This would be great, if during sprint planning, these stories actually got priority. The client wants a cool app, they don’t care about user documentation when you could instead be giving them a bell or a whistle.

What we have had are research stories. These are stories where we investigate options. i.e.
As a developer
I want to figure out if X is doable
So I know if this technology is the right way to go

These stories come up often in our process. We typically have been simply making some notes and reporting back at the retrospective / next planning. This was fine for our purposes but then we realized we could be creating a slightly more professional looking set of notes and pass them off as user documentation.

This doesn’t cover every aspect of user documentation, but it can get a lot of useful documentation done. How did we do our ldap data? We have documentation of our options and our final choice and why.

Currently we have been writing all of these in google docs so they can be easily collaborated on. We then paste them into the project wiki. It appears to be working.

From left to right: Agile, ITIL, and Open Source: An (un)holy trinity?

So I’ve hopefully started what will become a multi-part series about integrating Agile, Open Source, and ITIL into an overall strategy for delivering web services. You can find the first part on my personal web site. WARNING: The first post is simply a high, very high, overview of the three methodologies, so you may find nothing new in there. Indeed, here’s a snippet speaking to that very fact:

First, an admission: Open Source, Agile, and ITIL are nothing new to the realm of IT; all have been around for years, if not decades, and many industries have embraced them in some form or another. So the fact we are now incorporating these practices into our work might not seem exactly novel and, if I was strictly speaking about incorporating just the individual practices into our work, such an assertion would be correct. But I’m talking about merging all three, and a quick Google Search on “implementing,” “incorporating,” “combining” or “merging” this trinity doesn’t exactly return a cornucopia of results. So maybe what were doing is somewhat novel, after all.