You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Version 1 is a Joke

First off, I am not talking about VersionOne the Scrum management software.

We have been working toward version 1 on a couple projects for a while. The projects are released in pilot mode, and new releases are pushed to production every week or two, but they aren’t at what we are calling “version 1”. Which is what we are thinking is a finished product.

Scope Creep is Terrifying

I think a thriller/horror movie called “Scope Creep” would do well because I think a lot of people would relate to the horror of it. We have, multiple times now, put all of the stories in our backlog that we considered to be “version 1” into a Jira version. And those stories have all been completed. And then we add more. And those are completed. It is an endless cycle because we’re missing the decision making process of we’re there.

The Perfect Product

Show me a piece of perfect software and it will probably be the “ls” command or something. The key to perfection is simplicity.

Trimming the Tail

It is usually the responsibility of the Product Owner to trim the tail. However, you can’t always rely on that. It is the responsibility of the TEAM to prevent scope creep. Everyone has a say, everyone can see it. No one wants to be working on the same project forever.

only you can prevent scope creep

Posted in Uncategorized. Tags: . Comments Off on Version 1 is a Joke »

Offices and Opens and Saving your Work

A thread picks up on reddit every so often about developers needing quiet and the evils of open floor plans.

Many years ago I got a new job and during the interview process I was told I’d get my own office. There were several open offices, the person I was replacing had her own office. It was a sure thing. My first day I was grouped with the most junior developer of the group. I hated it. For a year or so I was the only person who had to share an office. (Yes, I see what I did there, this article is about me, not him.) After a week I was used to it.

Then the dev team moved to a new location. Half of the developers got offices and half got cubes. I had a cube right out in open, offering no privacy. I hated it. I had to learn how to work with a laptop on the lap and I had to be okay with people coming up behind me and commenting on whatever I was looking at. It took a week or so, but I got used to it.

Then the cube next to me opened up. I went in over the weekend and disassembled the wall connecting them. I reworked it so I had a double wide cube with walls toward the door. Privacy achieved. It was great. People could still come by and chat, I had room for a small table to have important 1:1s for discussing XML or Lost. But no one could lurk on me. I felt safe and open.

Then the band broke up a and different people were slung in different directions. I was moved into the same situation I was in when I was hired. I was the only one who had to share an office. I actually made a stink. We were the only people sharing and there were other options. I deserved my own office, right? Probably. But I got stuck with this guy — and this is no reflection on him, he’s great, but still, entitlement. And uh, peace and quiet?

Anyway, this was around the same time I was getting into agile. Really understanding principles of software development. How things really can work well in imperfect environments. Software development, I was discovering, was 90% collaboration/communication and 10% coding. I could go off and continue soloing my projects, or I could discuss what I’m doing more with my team and find better, and often faster ways of doing things.

I came to the realization that the time of the solo coder was gone. An office for a developer no longer makes sense. Developers are the center of work. If they’re inaccessible, they may not be getting the information they need to be doing the work correctly. Which happens constantly. Developers will often run down a rabbit hole head first if it’s an interesting problem. Having an office, with a closed door, is a great way to not be in communication with a team.

The argument most developers make is best explained in the following cartoon to the right:


The idea is that we work a lot in our heads. We are putting things together in an organic way. And when someone interrupts that organic process, work is actually LOST.

Interruptions are a part of the job. How we deal with them defines the kind of software engineer we are. To the comic, I would liken it to working on a Word document and not saving. KNOWING full well that at some point someone is going to message you on a chat client that makes Word crash. And autosave isn’t working… okay fine, it’s not a perfect metaphor.

So how do you save?

The concept of saving work can be thought of multiple ways. Rough documentation is always good. Map out your thinking in a document, a google doc or a confluence doc. I create google docs for almost everything nowadays. Some of them end up trash within in day, but it’s good to not lose my train of thought. I can stop anytime, continue it while I’m walking or commuting, pop it out in a meeting that isn’t relevant to me, whatever. You can also talk it over with a coworker. Bringing someone else into your train of thought can not only help you figure out a good solution, but also help in retaining the information. Building a collaborative relationship with your coworkers is paramount to succeeding in software development in the new world. The point is, interruptions are going to happen, so like, save often.

Posted in Uncategorized. Tags: , , , . Comments Off on Offices and Opens and Saving your Work »

Jira vs Github :: Agile vs Open Source

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”.

Posted in Agile, ATG, Git, Open Source, SVN. Tags: , , , . Comments Off on Jira vs Github :: Agile vs Open Source »

Feature Branches with Code Reviews

We have been trying to find a process for doing code reviews for a little while. Because most of our current projects are in github, it made sense to try and use some of the github features to help in this process.

I have been using issues for stories and milestones for sprints for a while. And it works out nicely because I get a pretty neat gamificationy results.

So I started using a feature branch in order to have the ability to make pull requests on my own project and get a discussion thread before code is merged into the trunk (production).

This discussion is a great way to get a reasonable code review before merging code. Right now we’ve decided to only do this for non-trivial changes, but with a very high bar on “trivial”.

Posted in ATG, Development. Tags: , , , , . Comments Off on Feature Branches with Code Reviews »

Forcing Client Involvement Through Production Releases

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.

Posted in Agile, ATG, Development, Quizmo. Tags: , , , , , . Comments Off on Forcing Client Involvement Through Production Releases »

Agile Context Switching

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.

Posted in Agile, ATG, Development, Flashcards, Harmony Lab, Quizmo. Tags: , . Comments Off on Agile Context Switching »

Gamification in Software Development

Gamification has been on my mind a lot lately.

I was just doing some of my sprint planning and found myself filling out borderline excessive github issues for my project. I put all of the issues for the current sprint into aptly named milestones. So as I finish the issues in the milestone, the milestone progress bar gets filled up. I recently realized I enjoy doing this because it’s very game-like.

I’ve turned work into a game and I think it has increased productivity and general happiness with employment. Maybe that sounds lame, but it seems true in my case, I would recommend it for most people who are finding their current work stale and are looking for some self motivation.

Posted in ATG, Development, Gamification. Tags: , , , , , . Comments Off on Gamification in Software Development »

Agile Documentation and Research Stories

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.

Posted in Agile, ATG, Design & Modeling, Development, Uncategorized. Tags: , . Comments Off on Agile Documentation and Research Stories »

A little bit of Agile, a dash of Open Source, and a pinch of ITIL

Agile, Open Source, and ITIL

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.

Posted in Agile, Development, ITIL, Open Source. Tags: , , , . Comments Off on A little bit of Agile, a dash of Open Source, and a pinch of ITIL »

Functional Testing: what to test?

I’ve been working with PHPUnit’s SeleniumTestCase. I worked out some good login switching for the two authentication schemes I’m working with. Then came time to actually write some tests. But what to test?

Unit testing tests a single class. A singular piece of code or a unit. I typically write unit tests for Models only. Integration testing tests the interaction of multiple units or units with multiple resources. I’ve been thinking of these as sort of testing the Controller. That’s a little simplified, but it’s not really something I have a framework for with Yii and PHPUnit. Functional testing likewise has varying definitions. Some people like to focus on the testing of “functional requirements of the product” and some people have a more simplistic view of it, that it’s just automating tests of the views — so it can be used as integration testing. I personally think the former is a better way to look at it, but it also sounds a little douchey to say it out loud.

So I’m totally agile. I’ve got all these user stories. And all these tasks. What I’m doing is writing the functional tests in terms of the user stories and tasks. This is sort of BDD, except I’m ignoring the excessive mocking, which basically makes the BDD tests unit tests, and doing the whole shebang at once. Shebang isn’t being picked up by spellcheck. #!

Posted in ATG, Yii. Tags: , , , , , . Comments Off on Functional Testing: what to test? »