Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts

Sunday, September 8, 2013

Crawling toward the goal line

For several months I've been using a Kanban board (via www.kanbanflow.com - a great FREE resource) to track the work I need to get done on OttoJotts. It's been helpful seeing both the work that I've been getting done (very minimal) and what's still left to do (big and growing daily). That said, it's been nice going through and moving things from Ready to Pull to In Progress to Done. I'm keeping my WIP (work in progress) limit to one because, yeah - I'll get distracted if it's more than that.
Part of my Kanban board
Almost all of the work left to do is around the two player game. I will need to go back and sort out all of the bad decisions I made around single player games when I get into Beta, but until I complete these remaining 11 stories, that's not worth my time. The nice thing about the board is that I can see how much time I've estimated it will take to complete each story. And when I sum them together, I get 176 hours remaining. Which is actually pretty cool. I am, in theory, 4.25 weeks from being done with OttoJotts. Assuming that I worked 40 hours a week (which I don't) and that I haven't terribly over- or underestimated any of these stories (which is kinda likely).
STILL! 176 hours is actually reasonable. There is real potential to be done with this thing before I sprout daisies. And bringing together a lot of technologies and pieces that I have only some familiarity with (and certainly wouldn't claim proficiency or expertise). Well, beyond using agile methodologies to track the work (and even that was a latecomer to the project). Overall I'm feeling, well, accomplished.
I had this gigantic negativity about the project when I put it on the back-burner last year. The size of the work that needed to be done seemed ginormous and insurmountable. But when I picked it up again and poked at it I saw some small successes and those kept building into other successes - small, to be sure, but present. And then when I finally took an accounting of all of the things that I wanted to complete before I could explore the possibility of releasing the game - 176 hours were all that remained. And out of those 176 hours there are 80 hours that I put in for what I consider will be some large efforts - things I don't have any idea how to do. The good thing is that they're down well-trodden paths - I just need to find the guide map and make my way down those paths.
So, it's been a LOOOOOONG winding road getting here, but the end really truly is in sight. And thanks to tools like KanbanFlow I've been able to focus on prioritizing the work I need to do next and focus on the current item only. And, hopefully, this is the beginning of something really exciting.

Sunday, August 19, 2012

More Mayan Madness and Inspiration

So it's been a while since I've posted. Unfortunately in the weeks since then I've had a hard drive "almost" fail, a Time Machine restore TOTALLY fail, the hard drive FINALLY fail, and lots of restore pain. In short, it's been a hell of a few weeks. But now I'm mostly back to normal (well, the laptop is) and running again.
19 Aug 2012 in Long Count
I've been working on the Long Calendar app for the past few days. So far I've added a lot of better graphics to it so it looks better than it did before (see picture to the right). I think it's starting to look a little better. I wasn't planning on working on the glyphs until I had completed everything else, but I'm actually really close now. I have two remaining bugs. For some reason the Haab and Tzolkin calculations are incorrect. I'm guessing I messed something up when I fixed some +1/-1 problems earlier. And BCE dates aren't working correctly right now. Again - I think I managed to break them at some point during development.
One thing I'm not doing much and need to be doing a lot more is the unit test. Xcode 4.2 integrated a unit testing framework into the system, which is awesome. I need to spend some time really beating it up and understanding it a lot. With this applet I feel that it could be beneficial (it would have caught the changes that broke the calculations), but I'm also pretty far down the path. I've got a set of tests that I do whenever I make changes, so I'm not totally out of sync with current development methodologies, but still feel that with all of the agile experience I have that I'm not being "true" to the methodology by not doing it for my own projects. Especially since Apple has done the "right" thing by encouraging developers to do it. Next project I must do it.
Regardless, things are starting to come together with this. I expect that I'll be able to get this completed this week, I hope, and get it into the AppStore next weekend. Earlier would be better, but there's a lot going on right now - lots of swirl and lots of stress.
On a good note, though, I spoke with a friend from my HP days - Cooper. He works at Microsoft right now and I was in Seattle last week and rang him up. He's one of the most talented engineers I know (perhaps the most talented). He's also one of those people who is completely committed to whatever it is that he's working on at the moment. He inspired me to work on things that made me happy when we worked together. We actually started talking about starting our own company before MS offered him riches that would make Solomon blush. But it's Coop who really encouraged me to dream bigger and work harder to achieve those dreams.
I've sort of lost sight of that in the doldrums that are everyday development. It's easy to forget the why of what you're doing in the day-to-day of doing. What do I want to have? The ability to be with my family when and where we want to be. To be able to provide for them while not being beholden to a time clock at a wage-slave job. To not be a sarariman. As you probably know, I have a 9-5 at Comcast. The "job" is good - challenging to be certain, but I'm well-compensated and enjoy working with my coworkers. But it's not what I want to do in the long-term. Before I got this job I told my wife that I wanted my next job to be my last one - that I would make this Otto Von thing work come hell or high water. And what's happened in the 2.5 years since I started at Comcast? Not a whole lot. I've managed to learn a lot but at same time waste a lot of effort not focusing on the end goal.
Talking with Cooper has really re-focused my energies on that end goal. I was reminded of the possibilities we had back at HP. Of the things we talked about doing and the places we'd go. Of the games we'd write and the lives we would change. Of the paradigms we'd create with our innovation. We'd be the Nintendos of the game world. And that's gotten lost.
So, here we are in August. What will the next few months bring? I don't know, but I do know that I'm reconnecting with those "halcyon days of my youth". I'm remembering WHY I'm doing this and why I need to make this more than just a hobby. It just takes a look at my family and a chat with an old friend to bring everything back into focus with a clarity I could scarcely recall. Almost like a haze that slowly dims your vision. Over the years it just seems fuzzier than it used to be. And then you clean the haze away. Now I just need to keep the haze away.

Saturday, May 19, 2012

Using Kanban for Work


I've been using agile development methodologies (Extreme Programming (XP), RUP, Scrum, etc) for over a decade now. In every job I've had in that time I've touted the benefits of using agile rather than whatever process was prevalent (usually just basic waterfall). In some cases the teams totally bought into it and saw fantastic productivity improvements (like a 300% increase at one company). I've had grassroots support in the trenches only to have senior management balk at it ("too hard to track", etc. - the typical NIH issues). In some cases, the team decided to implement it anyway. Other times the team thought they knew the technology but just ended up with iterative waterfall (smaller waterfall cycles).
Example KanbanFlow board
For all of my work with Otto Von I've done agile in some way. I've been doing primarily XP with some modifications given I'm a one-man shop. But lately Kanban has been getting a lot of traction in my mind and I've just started using an online Kanban board (see this post for a little more about it). What I like about Kanban is that it's really better adapted to how I need to work and what I focus on from an agile perspective - take on a small chunk of work, complete it, move on to the next.
A slice of cake is like a story
So what does Kanban offer? First, as in all agile methodologies, you start with decomposing the work that needs to be done into small pieces. The key concept is to look at the entire project as a cake that you cut into vertical slices. In most applications there are layers that need to be built (back-end, UI, storage, database, etc). With the slice, you focus on doing all of the work on the layers at one time in the slice while providing some small element of value to the project. In the picture above you can see that I've got stories like "Add Friend". These require UI changes. back-end code, and DB changes. That's my slice for that piece of work. These can sometimes relate to "functionality" or "features", but traditionally features are larger than a story would allow.
Your first column is usually the "backlog" or "To Do" list. These are the stories that you've started to define but aren't really complete enough to really consider for developing. Ideally you prioritize the backlog so you can quickly identify those stories that you need to finish defining first. Your "Ready to Pull" list are the stories, in priority order, that can be worked immediately if you have the bandwidth. The "In Progress" is just that - things that you are actively working. Sometimes called your "WIP" (work in progress), this should contain only those stories that you can work on and complete in two weeks (the standard iteration/sprint length). This insures that you don't try to take on multiple tasks that de-focus you from working something through to completion. Finally, when you've completed a story you move it to the "Done" list. It's pretty straight-forward, but the challenge is making stories/slices that are usable and small enough. It takes a lot of practice and even after a decade I struggle sometimes.
Kanban allows you to have multiple work items in process (your WIP limit). For me that's generally one. I need to focus on that one thing, get it completed, and move on to the next. With a larger team than I have (i.e., more than one),  your WIP limit will be larger. Using the Kanban board lets me prioritize the work that needs to be done. I can add new stories, shift priorities - all things that are important in running a small project.
KanbanFlow, the free(!) online board I'm using doesn't have some typical user story fields (and no, I don't get a kickback for rating them so highly, but maybe I should; are you listening, KanbanFlow?!). For instance, it tracks time in hours not points. I guess you could use the "hours" field as a "points" field, but overall it's a small thing. So far I am very pleased with the software and able to work around (or ignore) the things I don't require.
If you're looking to get some focus on your work, Kanban is certainly one methodology that you should explore. And KanbanFlow is a very good free service should you choose that direction. Good luck and happy coding.