Release #2

Posted: April 12, 2011 | Author: | Filed under: Scrum | Tags: , , | 1 Comment

The code for release #2 has been tagged in the BitBucket repository. You can download the software distribution and check it out for yourself.

Features Complete:

  • Create database models and diagrams in JavaScript using a domain specific language built using the Fluent Interface Pattern.
  • Interact with models and diagrams through a command-line REPL.
  • The tool will generate a DDL script for database creation for a particular database platform (SQLite3 implemented).
  • The tool will create an initial database diagram based on a database model and can save the diagram to a JavaScript file.
  • Models and diagrams can be split up among multiple JavaScript files.

Demonstration:

Retrospective:

Actual Hours Worked by Day

I spent just over 60 hours working on the code for this project over the past semester. This equates to about 1.5 work-weeks of effort had I been doing this as a full-time job rather than a “spare-time” project. I feel pretty good about what I’ve been able to accomplish in the amount of time spent. I think the software represents a strong, functional prototype, which is probably all you can expect from a single person in 1.5 work-weeks.

Burndowns for One-week SprintsSince my one-week sprints were more successful than my two-week sprints, I thought I’d compare the burndown charts of the one-week sprints to see if any patterns emerged. The sprints had different amounts of work scoped, so I displayed the burndowns in terms of percent complete. No pattern jumps out at me, though. Each sprint seems pretty unique.

Personal Scrum

Posted: April 10, 2011 | Author: | Filed under: Agile, Scrum | Tags: , , , , | 8 Comments

If you’ve been following my blog, you know that I have been using an adaptation of Scrum for a one-person team to manage my graduate project. I (and others) call this “Personal Scrum.” The semester-long experience was very positive. The Personal Scrum methodology was an excellent tool to get the work done.

Personal Scrum Definition:

Personal Scrum is an Agile methodology that adapts and applies Scrum practices to one-person projects. It promotes personal productivity through observation, adaptation, progressive elaboration, prioritizing and sizing work, and time-boxing.

Personal Scrum vs. Scrum:

Let’s compare aspects of Scrum as defined by the Scrum Alliance to those of Personal Scrum.

Scrum’s 3 Roles:

A Scrum team has three roles: Product Owner, Scrum Master, and Team Member. The Product Owner is responsible for the business value of the product and decides what is built. The Scrum Master is primarily a facilitator and enforcer of the Scrum rules. The Team is self-organizing and cross-functional. The Team decides how to build what the Product Owner wants and goes about doing it.

Obviously, since Personal Scrum is a methodology for one-person teams, one person must fulfill all three Scrum roles. This is not as difficult as it may sound, because Scrum’s ceremonies typically focus on one role’s responsibilities at a time.

Scrum’s 4 Ceremonies:

The Scrum Alliance lists four ceremonies (think “group activities”) used in Scrum: Sprint Planning, Daily Scrums, Sprint Reviews, and Sprint Retrospectives. Mysteriously missing from this list is Release Planning, perhaps because it is typically not a regularly scheduled event. Exactly what these ceremonies entails is beyond the scope of this blog post, but each of these ceremonies are reflected in some way in the Personal Scrum methodology. I used blog postings for sprint planning, sprint reviews, and sprint retrospective. I tracked my daily work and release plans in Excel. It is important to observe and delineate these activities.

Scrum’s 3 Artifacts:

The Scrum Alliance lists three artifacts used in Scrum: Product Backlog, Sprint Backlog, and Burndown Chart. Each of these artifacts are used in exactly the same manner in Personal Scrum.

My Experience:

  • Initially, I thought I could accomplish way more in one semester than I was actually able to undertake. The Personal Scrum techniques helped me to focus on the most important work first. Velocity tracking and release planning helped me to identify early on that I was unlikely to finish all that I had started out to do. I was able to revise my goals and plan accordingly.
  • I found that estimating work in terms of time is exceptionally hard, especially when you have no team members to help and few of your tasks are similar. I learned to expect my time estimates to be wrong.
  • Estimating in story points is easy and effective.
  • I tried one-week and two-week sprints. For me, one-week sprints were much more effective. One-week sprints have smaller scope. The shorter-term deadlines made the goals and tasks more salient. I found myself to be more diligent on the one-week sprints. The downside to one-week sprints is that you spend a greater percentage of your available time on planning and reporting; less time is available for actually doing the work.
  • Burndown charts have to be done in terms of estimated hours of work accomplished rather than story points. One person is unlikely to finish more than a couple of user stories per one-week sprint. Burn down hours only when a task has been fully finished (“done done”).
  • Use story points to track velocity. Use velocity to do release planning. Release planning is a great way to project what you are likely to be able to accomplish by a certain date (the end of a semester for instance).
  • Committing to posting your sprint plans, demonstrations, retrospectives, and burndown charts online is a great way to keep motivated and accountable. I found this to be an even greater source of motivation than having a faculty advisor. If you know your work is going to be visible in a very public way, you will be more likely to do your best work.

My Work:

The entire project has been chronicled in the materials below. To my knowledge, this is the first fully documented instance of a Personal Scrum project, and it is certainly the most open. My code has been released under the MIT License, and the Excel workbooks and blog posts are released under the Creative Commons Attribution-ShareAlike 3.0 Unported License.

Sprint #9 Demo and Retrospective

Posted: April 3, 2011 | Author: | Filed under: Scrum | Tags: , , , | 1 Comment

Burndown Chart:

Sprint #9 Burndown Chart

Completed User Stories:

  • #30 – Users should be able to run the application from the command line.
  • #31 – Users should be able to split the model and diagram into multiple files

Completed Tasks:

  • Modify the Ant build file to create an “uberjar” of all the libraries
  • Modify the project & Ant build file to put each library’s license into the distribution
  • Solve the classloader problem preventing command line execution
  • Include a bat file (Windows) and shell script (Linux) to launch the application.
  • Implement a way to load a model and diagram that is split into multiple JavaScript files.

Demonstration:

I’ll have a great screen cast coming up this week! Check back.

Retrospective:

Est. Hours vs. Act. HoursEverything went well this week. Nothing much to reflect upon.

 

 

Sprint #9 Planning

Posted: March 29, 2011 | Author: | Filed under: Scrum | Tags: , , , , | 1 Comment

This plan is a couple of days late.

Release Plan Revisions

My latest release plan provisioned 2 final 2-week sprints, sprints #9 and #10. Since then, I have been given the requirements for the “final deliverables” for my graduate project. I will need three weeks to produce these deliverables, get feedback, and address said feedback. Thus, sprint #9 will be a one week sprint devoted to cleaning up the technical debt from the last sprint and putting the finishing touches on the prototype.

Sprint #9 Plan

Sprint #9 will consist of two user stories totaling 6 story points. This breaks down to 5 tasks and an estimated 5.92 hours of effort.

User Stories:

  • #30 – Users should be able to run the application from the command line.
  • #31 – Users should be able to split the model and diagram into multiple files

Tasks:

  • Modify the Ant build file to create an “uberjar” of all the libraries
  • Modify the project & Ant build file to put each library’s license into the distribution
  • Solve the classloader problem preventing command line execution
  • Include a bat file (Windows) and shell script (Linux) to launch the application.
  • Implement a way to load a model and diagram that is split into multiple JavaScript files.

 

Sprint #8 Demo and Retrospective

Posted: March 28, 2011 | Author: | Filed under: Scrum | Tags: , , , | 1 Comment

Burndown Chart:

Sprint #8 Burndown Chart

The burndown chart for sprint #8 is an even more pronounced stair-step than the one for sprint #6. I was unable to do any work for the first week of this two-week sprint for a variety of reasons. This means I went 3 weeks without making any progress on the project. Having lost all momentum, it has been very difficult to get moving again. I was only really able to do any coding on the weekends. Luckily, I was able to cram two weeks worth of work into two days.

Completed User Stories:

  1. #20 – The tool should create an initial diagram from a model.
  2. #21 – The tool should save diagrams to a JavaScript file.
  3. #24 -The GUI should have a toolbar and menubar allowing the user to open models, create, open, save, and close diagrams.
  4. #27 – The GUI should allow the user to Pan and Zoom within a diagram.

Completed Tasks:

  1. Tool creates a blank diagram file for a model
  2. Tool writes statements in diagram file to draw tables
  3. Tool writes statements in diagram file to draw foreign keys
  4. Tool figures out how to space out the tables in the diagram
  5. Tool figures out how large to make each table in the diagram
  6. Tool figures out how to lay out foreign keys in the diagram
  7. Figure out how to do translation and scaling in Processing and add Pan/Zoom functionality
  8. When mouse moves near edge of viewer, pan in that direction
  9. Add toolbar and menubar to window
  10. Add open model function and connect to toolbar and menubar
  11. Add save diagram function and connect to toolbar and menubar
  12. Refactor diagramming classes to set up for new features

Incomplete Tasks:

  1. Add toolbar buttons for zoom in zoom out.

Technical Debt:

  1. I still haven’t solved the class-loading problem that prevents one from running the app from the command line. It still runs fine from IntelliJ IDEA. I haven’t tried bundling all the libraries into a single jar. Maybe that would solve it? Is there an issue doing this with libraries under the LGPL 3 and Apache License 2.0? I don’t think so, but I’m not 100% sure.
  2. I don’t particularly like the way the “open diagram” functionality works. I need to refactor it.

Demonstration:

A screen shot doesn’t really do it justice, but I don’t have time to do a screen cast today. Sorry.

Sprint #8 Demo

Retrospective:

Sprint #8 Est. Hours vs. Act. Hours

My (poor excuse for) user stories and tasks were much too implementation specific. They described the “how” rather than the “what” and/or “why”. After getting my hands dirty with code, I discovered better ways to do things. For instance, I initially wanted the tool to pan the diagram when the mouse reached the edge of the window. I was able to get this working but it didn’t “feel” right. It was hard to control. I ended up using scrollbars to achieve the same end with better results and simpler code.

One thing I have determined is that there is no such thing as “sustainable pace” on a project that is done in one’s “spare time” on top of a full-time job. There is a “tolerable pace” or maybe a “survivable pace” in the short-term, but I’m not sure if “sustainable” is achievable.

Equipment Failure

Posted: March 25, 2011 | Author: | Filed under: Uncategorized | Leave a comment

I spend most of my day in front of a computer. And by most, I mean somewhere in the vicinity of 90% of my waking hours. Whether or not this is sad/lame is a topic for another post. Since I spend so much time with computers, I tend to value quality equipment pretty highly. When I buy a computer for myself, it’s always a beefy machine. It is worth the extra money to have a machine that can keep up with me. Currently, that means I will not settle for less than a quad-core processor and 4 GB of 1066 MHz DDR3 RAM, even for a laptop. In fact, the next time I need a desktop, I am going to build one from components, and it will have a RAID array.

Bottom line: I don’t want my equipment to get in my way. Period.

I have perhaps the cheapest keyboard and mouse known to man. Lately, I’ve felt like my keyboard in particular is holding me back. I just cannot type as fast as I’d like to; the keyboard won’t keep up with me. I’ve read about mechanical keyboards, and I’m wondering if one might be the answer to my prayers. Unfortunately, mechanical keyboards are expensive. I think I’d like the Das Keyboard, but $129 is a hefty price to pay for a keyboard, especially if you’ve not had a chance to try it out. Seriously? $100+ for a keyboard?

I think I need to research a bit more before I invest that much in a keyboard…

The Four Essential Product Owner Qualities

Posted: March 15, 2011 | Author: | Filed under: Scrum | Tags: , , | 7 Comments

  1. Informed

    It is imperative that the person in the Product Owner role have a firm understanding of the business processes and needs that are being addressed by the software to be built. A newbie to the business would not be a wise choice for the Product Owner role. A subject matter expert would be a better choice. A person that not only has intimate knowledge of the business but can also teach others well is necessary. The Product Owner has to be able to explain the business to the scrum team. Because the Product Owner is responsible for the project’s return on investment, he or she needs to be well enough informed that they can judge the business value of each user story.

  2. Empowered

    Like George Bush, the Product Owner must be the “decider,” empowered to make the call when questions arise. The Product Owner is the one person on a Scrum project that gets to decide what is built (but not how it is built). One cannot hold a Product Owner responsible for a project’s return on investment without also granting that person the authority to make decisions that impact the ROI. Furthermore, having one person designated to make decisions can greatly improve a project’s velocity. If developers have to convene, address, and negotiate with some sort of council or project steering group each time a decision needs to be made, the scrum team will have difficulty removing roadblocks efficiently.

  3. Available

    The Product Owner role is a full-time job. The person serving in the role should be dedicated to the project. The Product Owner must be available to explain business concepts, processes, and needs to developers when questions come up. When decisions need to be made, the Product Owner must be ready to decide. When features need to be demonstrated and approved, the Product Owner must be available.  Whenever a scrum team has to wait on Product Owner, the team’s velocity is negatively affected and money/time is wasted.

  4. Prepared

    Between explaining, deciding, and approving, the Product Owner must be busy grooming the product backlog and release plan. Without a properly prepared backlog, a sprint planning meeting is a non-starter. An unprepared Product Owner can be the biggest source of delay to a scrum team. The Product Owner has an obligation to be ready prior to each sprint’s planning meeting so that the team can begin the sprints on the right foot.

Sprint #8 Planning – or Sprint #7 Redux

Posted: March 14, 2011 | Author: | Filed under: Scrum | Tags: | 1 Comment

For sprint 8, I will be doing the work that I had planned to do in sprint 7.  15 story points and 12 hours of estimated effort.

User Stories:

  • #20 – The tool should create an initial diagram from a model.
  • #21 – The tool should save diagrams to a JavaScript file.
  • #24 – The GUI should have a toolbar and menubar allowing the user to open models, create, open, save, and close diagrams.
  • #27 – The GUI should allow the user to Pan and Zoom within a diagram.

Tasks:

  • Tool creates a blank diagram file for a model
  • Tool writes statements in diagram file to draw tables
  • Tool writes statements in diagram file to draw foreign keys
  • Tool figures out how to space out the tables in the diagram
  • Tool figures out how large to make each table in the diagram
  • Tool figures out how to lay out foreign keys in the diagram
  • Figure out how to do translation and scaling in Processing and add Pan/Zoom functionality
  • Add toolbar buttons for zoom in zoom out
  • When mouse moves near edge of viewer, pan in that direction
  • Add toolbar and menubar to window
  • Add open model function and connect to toolbar and menubar
  • Add save diagram function and connect to toolbar and menubar
  • Refactor diagramming classes to set up for new features

Sprint #7 Demo and Retrospective

Posted: March 14, 2011 | Author: | Filed under: Scrum | Tags: , , | 1 Comment

Burndown Chart:

A burndown chart couldn’t look much worse without adding scope to a sprint. One of the main tenants of Agile Methodologies is that of “visibility,” which means that you can expect the truth to be revealed whether or not it looks good. As embarrassed as I am to say it, I didn’t accomplish anything in the last two weeks.

BEGIN EXCUSES:
1. I'VE BEEN SICK.
2. I'VE HAD TO PUT IN SOME EXTRA HOURS AT WORK TO FINISH OFF A PROJECT.
END EXCUSES;

Retrospective:

I don’t think there is too much to reflect upon or learn from this sprint, except that one should expect things to come up that will impact any project’s schedule. I will shift all of sprint 7’s work to sprint 8 and try to move forward.

 

 

 

EE616 Release Plan Revised

Posted: March 7, 2011 | Author: | Filed under: Scrum | Tags: , , , , | 2 Comments

Release planning is one of the major functions of the Product Owner role in Scrum. While sprint planning addresses only the next sprint, release planning is a more strategic, longer-term planning exercise that considers many sprints. The goal of a release plan is to group the product backlog into like-sized sprints based on story points and team velocity. Each sprint should contain topographically similar stories. Each sprint’s theme describes the goal of the sprint. A release plan lays out sprints chronologically and groups them into releases. A release may consist of one or more sprints at the end of which the software is released to the customer. Note that this does not mean that the each sprint should not still result in potentially shippable code, just that the plan for actually shipping code is at the end of the release.

It is important to note that, like the product backlog, the release plan is a living document meant to be revised as you go. The release plan is not the same as a traditional project schedule like you would see on a waterfall project, nor is it a work breakdown structure. It is a tentative, high-level plan for future sprints.

On a personal scrum project, you have to play all the scrum roles – product owner, scrum master, and team. In fact, for this project, I am the customer as well. Last weekend, I revisited and revised my release plan for my graduate project. This was necessary for a number of reasons, not the least of which being my switch from one-week sprints to two-week sprints. I had been grooming my product backlog throughout the first six sprints, and my release plan had become out-of-date.

My original release plan included a second release on March 5th, and a final release on April 22. March 5 would have fallen smack in the middle of a 2-week sprint. I decided to do away with the second release and just have one final release on April 22. This gives me 4 more 2-week sprints between now and the final release. In this time, I will focus heavily on database diagramming via the GUI tool. The scopes for sprints 7, 8, and 9 are pretty well firmed up, having around 16 story points each. I have way too many features left over to get done in sprint 10. As I get closer to sprint 10, I will decide what to include and what to throw out.

I have been doing all of my scrum work in Excel 2010, which has been perfect for personal scrum. I have been posting my product backlog, sprint plans, burndowns, etc. to my project’s BitBucket repository. I have posted my new release plan there as well, and I have released it under the Creative Commons Attribution-ShareAlike 3.0 Unported License. So, feel free to use and adapt it per the license constraints.

The release plan uses the Sparklines feature in Excel 2010 to draw the burndown in each sprint. If you use an older version of Excel, you won’t see these.

Release 1 – Completed

  • Sprint 1 Project Setup + Core Library
  • Sprint 2 Model API
  • Sprint 3 Refactoring + DDL Generation
  • Sprint 4 Refactoring
  • Sprint 5 DDL Generation

Release 2 – April 22

  • Sprint 6 Cmd Line Options + Diagram Viewing
  • Sprint 7 Diagram Creation & Storage + GUI Niceties
  • Sprint 8 Diagram Editing
  • Sprint 9 Diagram Export + Model Explorer + Database Compare
  • Sprint 10 ?

 

← Older Entries