I decided to post a short, sweet, to-the-point blog letting everyone know that I am switching roles here at Seapine.
I have moved from being a software engineer dabbling in Services and Agile to being a consultant that does 50% Agile Services and 50% Services here at Seapine.
I am very excited about the opportunity, and really looking forward to expanding my horizons and continuing to put my new Agile skills into practice.
In a previous blog post, I discussed what I learned about the quality of user stories. Better user stories would make things easier to implement. I couldn’t give any concrete examples of what I did and what I thought would be better because of Seapine’s pesky confidentiality thing – we don’t like to make announcements of features that will be in a release prematurely. Anyway, now that the features in Surround SCM 2011.1 are common knowledge, I’d like to share specifics of what I learned with you.
The first feature that I worked on was the ‘edit comments’ feature. Now, this is my first IRL Agile experience – thus far it was only books and classes – so please no comments that I should’ve realized before that I was an idiot.
The user stories were:
1. As an admin, I want to be able to edit all non-system generated comments for file history events.
2. As a user, I want to be able to edit comments that I entered for file history events
3. Comments that have been edited should be saved in the database.
4. As an admin, I want to be able to grant/deny permission to edit own comments and have this be enforced.
5. As an admin, I want to be able to grant/deny permission to edit others comments and have this be enforced.
If I had to do over the user stories that I’d have would be:
1. As an admin, I can set security for Edit Own Comments that is saved in the database
2. As an admin, I can set security for Edit Other Users’ Comments that is saved in the database
3. As a user, I can make the comment field editable in the history details dialog for non-system comments if my security allows it. System generated comments are never editable.
4. As a user, if I click on the Next or Previous button within the history details dialog, the comments become non-editable again
5. As a user, if I change the comments on any labeling events, security is checked, the new comments are saved in the database, and the new comments are shown in the GUI.
6. As user, if I change the comments on any regular file events, security is checked, the new comments are saved in the database, and the new comments are shown in the GUI.
7. CLI list group and edit group commands should support all new security.
If I had it to do over, I wouldn’t have forgotten the good ole CLI, and I would’ve made the user stories deeper. My previous user stories split being able to change something from the changes being saved in database.
My cuts were horizontal
– instead of a user story accomplishing releasable functionality, I fell into the trap of dividing the user story by layers. One user story handled the UI/application layer, and a different user story handled the database layer. And, I missed some things – the comments when a file is added/removed from a label are stored in a table with label events, and the comments for regular file actions (add, edit, checkin) are stored in a different table, so the label events deserved their own user story.
My cuts should’ve been vertical.
Each user story should accomplish something releasable. There should be no separate, ‘oh yeah, and everything is saved in the database’ story. The stories should pass through all layers if it’s necessary in order to accomplish something of value (and not appear half-done).
I realize that I haven’t mentioned anything about User Acceptance Testing in either blog about user stories. I couldn’t convince anyone that my features shouldn’t go through the normal QA process, so my User Acceptance Testing was done via Test Cases that our QA team wrote.
We’ve been hard at work preparing our Agile services offerings to help clients achieve their goals adopting Agile practices.
Check out Seapine’s Agile Services page for your Agile needs!
I’ve found it interesting that people outside of the IT industry really have no idea what the differences are between different IT jobs. Sys Admin, software engineer, software architect, help desk…to them it’s all ‘computer stuff.’ So when I say that I’m a software engineer, I have to then explain that I design and write software. Many times, I just skip the software engineer explanation and say that I write code. I guess that it’s okay if people identify me as a programmer or a coder. But, if someone identifies me as a code monkey, then a) they know what that is and b) they are underestimating what I actually do.
Although, not always. My 13 year old nephew got into trouble during music class one day because the teacher asked if anyone wanted to sing or play an instrument in front of the class. He’s a bit of a class clown, and he and his friends got up and sang this . Apparently they like code monkeys. (I lobbied my sister not to ground him.)
That got me to thinking about the difference between Waterfall and Agile development. In Agile there’s just no place for code monkeys. Since the design is done incrementally, it has to be done by whoever is actually writing the code. In Waterfall, the big upfront design can be done by architects or higher-ups who just toss the technical specifications to the code monkeys to implement. You can do Waterfall where your developers do functional and technical designs (that’s how it is here at Seapine, thank goodness), but if you only trust a couple of higher-ups to do your design work, then you really can’t do Agile.
Agile requires that a) you trust the people who are writing the code to be capable of intelligent thoughts and b) you give them the power to have intelligent thoughts instead of just transferring tech design to code. That’s a definitely a +1 for Agile as far as I’m concerned. There’s simply no room for code monkeys.
Chuck Clevenger, Alan Bustamante and I did a presentation for the Computer Science students at the University of Cincinnati. Chuck did the intros, Alan gave an Agile overview, and I discussed some of the challenges I’ve faced going Agile.
Since getting started with my services project using TestTrack was so successful, I decided that I would also use it for my Surround SCM 2011.1 development. So, I created a new Public folder called Development tasks. Under that, I created a folder of type ‘Product’ and added Surround SCM. Then I created a release folder named Surround SCM 2011.1. I created a backlog and added all of the remaining user stories that I had for my first feature, and the new user stories for my second feature.
Since I had already completed a few sprints, I decided I would dummy up the data so that I could check out how the TestTrack Agile reporting worked. I added iteration/sprint folders for all of the sprints that I had completed and added the appropriate user stories for each sprint. At this point, I decided I needed some kind of workflow so I could tell if a user story was finished or not. I decided to create ‘Backlog’, ‘Blocked’, ‘To Do’, ‘Work in Progress’, and ‘Done’ states to represent the status of the user story. All user stories in the Backlog would be of status ‘Backlog’ and, when I moved them into a sprint, I’d change the status to ‘To Do’. Once I started working on them, the state would be ‘Work in Progress’, and then finally the state would be ‘Done’ when I completed a story. ‘Blocked’ is, well, self-explanatory. I set up some logic events and transitions. I cycled the completed user stories through the workflow so everything looked as it should. I went back and changed the dates on the events to when I (approximately) actually did them.
Now, how do my reports look? I added a burn up chart for Surround SCM 2011.1 (Reports->Release Status->Burn Up Chart, Select Surround SCM 2011.1 as the folder and be sure to check Recursive). I ran the report, and…um, no data. The Data to Chart is set to Hours. I didn’t assign any hours to any of my user stories because I am tracking by story points.
Lucky me, working at Seapine means that I have access to the Product Owner for the TestTrack suite, Paula (http://blogs.seapine.com/author/romep/). So, I went and cried to her that I wanted to report on story points. She’s great, and patiently explained to me that I could, indeed, report on story points, I just needed to hook it up in the backend to do it. Under Tools->Administration->Project Options there is a section under Time Tracking Requirements where all I needed to do was set the Story Points field to the custom field that I created to hold my story points.
The report looks pretty good:
I am doing both Surround SCM development and services projects, and I have a services project that involves updating existing C# code for further customizations. The code is the Risk Management App. A few customers were requesting some updates, so I am working with another member of the services team, Michael, to implement the requests.
I am, of course, going to do this in an Agile style instead of Waterfall. Michael will be the product owner representing the customer, and I will be, well, everything else. I decided to use our very own tool, TestTrack to manage my Agile project. I looked at the Agile Expedition to get started.
I have my own TestTrack server running locally so I am free to do whatever I like with it. I figured the most straightforward way to do it was to use TestTrack RM and folders. I added a folder Services Projects, and, under that, a folder of type ‘Product’ called Risk 
Management Application. I created a folder of type ‘Backlog’ under that, as well as a folder of type ‘Release’ that I titled (oh so creatively) Release 1. I set the start date and end date under the ‘Release Planning’ tab.
I worked with Michael to come up with user stories to represent the various customer requests. I went to add the user stories to my backlog folder, and I was a tad disappointed that I didn’t have a type user story option out of the box. But, it was easy enough to add. Under Tools->Administration there’s an option called Requirement Types. This opened up a dialog that allowed me to add ‘User Story’ as a requirement type. I added my user stories, but I wanted to keep track of my story points for each of them. Again, TestTrack RM allows me to customize this way. So I went to Tools->Administration again and this time selected Custom Fields. I switched the type to Requirements, and added a custom field of type Integer called Story Points. Then I had to go back and fill in the correct story points for each of my stories in the backlog.
I worked with Michael to get his priorities for the user stories and then went into my backlog and ranked them. It’s a right-click menu within the folders. We figured I would do one week sprints so I created a folder of type ‘Iteration’ (again, my creativity is astounding – I named it ‘Sprint 1′) under ‘Release 1′, set the start and end dates appropriately under the ‘Release Planning’ tab of the sprint, and moved the user stories from the Backlog into the sprint folder.
I made sure Michael had access to the project, and now we can use TestTrack instead of the kanban board since we are on different floors.
As I’m implementing my user stories, I really feel like I could have done a better job of coming up with the user stories. Part of the problem is that we didn’t follow the ‘true’ Agile process and have user stories in the backlog – basically when the feature list for Surround Surround SCM 2011.1.0 was handed down from on high, I worked with the product owner to come up with user stories. He has done this before – I think he’s even been to the Agile Product Owner class, but I think that I should’ve done a better job as the developer to make the user stories more, well, straightforward…concise…encapsulated…I’m not sure what the right word is here, but I feel like I have a better idea of what the user stories should look like now. I still feel like I have a lot to learn as a developer doing Agile how to guide (force, whatever) the product owner to come up with user stories that will make my job easier.
After Surround SCM 2011.1 is released, I will post what the original user stories were and what I’d select for the user stories now.
One thing that I’ve noticed while doing TDD is that coming up with the tests is really challenging. Some of them are pretty obvious, but I find myself really struggling to come up with tests for others. For instance, the feature that I am working on requires new security. So, I have my user story to allow an admin to grant security through a group. But…how do I create unit tests for this? If you’ve used Surround, then you know that the security is really just a list of privileges that the admin can check (to grant access) or uncheck (to take away access) for a given group. I can’t create a unit test to make sure that the new privilege appears in the list because the tools that we have just aren’t that fancy. So, I’ve got a unit test to make sure that the code to grant the permission and take away the new permission actually works. But, it feels like cheating.
I can’t really even come up with a good way to test the button enabling based on user security because the client gets that data from the server. I feel like I’ve got a constant nagging temptation to slip into cowboy coding and just do the darn thing instead of spinning my wheels trying to figure out how to come up with a test so that I can do test driven development </rant>
I really see that it takes a lot of discipline to do test driven development. It’s a mindset thing. Forget pair-programming, I need a little parrot on my shoulder that says, “Did you write a test for that?” All in all, I think that the benefits of test driven development make it worth it. It’s just hard and takes some serious discipline when you are first starting out.
My first sprint review was pretty short and benign, as will be this post. It consisted of the Product Owner, my manager, our documentation manager, and me. The QA analyst assigned to work on the feature that I am developing was out. I demoed the user stories that were done. There were a couple of questions, a bit of discussion, and that was it. Easy breezy lemon squeezy.
