Archive for December, 2009|Monthly archive page

Why Writing Blog Posts is (Maybe) as Helpful as Reading Blog Posts

I gain a lot of knowledge from reading blogs.  I get a lot of new ideas about things I don’t know, or about things I know little about.  When I am thrashing on something and can’t seem to find what I need, there is often a blog post somewhere that helps me find the answers I seek.

I had never written a technical blog before, just frivolous things that never went anywhere.  Having been writing a “big girl blog” for 5 months now, I’ve gained a neat new experience. 

I’m learning from myself. 

A lot of these things that I write about start as nebulous ideas in my head, or things that I work with so closely that I can’t distinguish where to begin writing about them.  I generally just push through and write them.  When I’m done (after 1,000 edits), I have nailed that nebulous blob down into solid ideas that make sense to me.  Doing this gives me a clearer understanding of the concept, the ability to teach others (now that I have the words to do so), and I am, in general, much more confident in applying my knowledge to everyday work situations.  Additionally, the comments I get help me think a little bigger about what I write and see things from a different perspective (or give me new ideas that support my ideas/opinions).

I used to be terrified of writing a blog.  I felt like I didn’t know how to write and I was afraid that people would see how colloquial my posts were and write them off as juvenile and glib.  I felt like I had nothing to write about because I was a n00b and didn’t really have any experience.  A lot of things worked against me to make me not want to blog, but eventually, with a little (read: a lot of) pushing, I started.

All I had to do was write what I knew.  My colloquial voice calmed down a little (read: barely) as I got more comfortable with writing.  Ideas came easier as I gained experience from my environment.

My point (finally) is that blogging can help you solidify a lot of your own ideas just by talking them out.  If you don’t want to blog, that is 100% super ok.  If you are afraid to blog, get off your ass and just do it.  You might surprise yourself with how much you know, and you might surprise yourself with how much you can teach others.

“More Haste, Less Speed.”

Definition: The faster you try to do something, the more likely you are to make mistakes that make you take longer than it would had you planned it.

Our team recently completed two rather large projects with fairly short deadlines.*  Having overseen both projects beginning to end, it was easy to see the patterns of burnout and people feeling rushed.  Throughout the life of both projects, the questions, issues, and general quality of the product was fairly consistent.  Riiight up until the end.

In the last month and a half or so of each project, the quality of what was being produced really dropped and the number of bugs skyrocketed.*  Every story that I’d test would get kicked back multiple times, a lot of them getting kicked back immediately because the program would blow up as soon as I tried to test the feature.

Feeling a lot of pressure as a deadline approaches is natural.  Burning out after 6 straight months of 15-hour days and no vacation is natural.  It’s easy to just say “work at a sustainable pace,” but it’s hard when you are right down to the line and things keep coming.  The main thing is to try to recognize when you are feeling like that and when your code is unhealthy and attempt to mitigate it.  If everything you are writing is getting kicked back, try to find a solution to get your mind back into a productive state.  If you don’t, the end will be much more frustrating, as you will have to continually rewrite code and work on the same stories and rush to try to patch things to meet your deadline.

What can you do to get your mind back into a productive state?  Smoke a cigarette?  Go to Starbucks?  Sit in your car with some death metal blaring?  Change your socks?  Try to find something that works for you (everyone is different).  I’d love to hear some ideas/solutions in the comments.


*note: we are closing out the second one, it’s not actually done yet.  But you get the idea.

*note: the quality of the last half of the second project was markedly better than that of the first one, so kudos on team improvement!

Transparency and High Visibility: How to Keep a Stupidly Large Project Alive and Healthy

I may have alluded to this in previous posts, but let me try to sum up The Hell That Is What Our Team Is Working On Right Now:

We have been given 6 months to complete a web application that is basically a (beautiful and much improved) replica of an existing suite of desktop apps that took us two years to build.  Oh, and we started with pretty much no web experience.  Oh, and our deadline is Jan 1.  Merry Xmas to me; this year I want Xanax.

After going through the complete Kübler-Ross model, we got focused and got started.

Let me tell you some facts about what we are working with: it involves people from a wide variety of departments across the company as well as a lot of hardware/tools/”things” that we do not have any sort of clear concept of yet.  As a result, it has been very hard to get information and fairly hard to specify and figure out which stories a) have enough information to be worked on and b) won’t incur too much change as people figure out what’s going on.

Obviously, we’re building this iteratively.  Because how the hell else can you build something when you get new bits of information every week?  At any rate, this product is essentially changing the face of our company and there are a lot of stakeholders.  This thing needs to be gold in everyone’s eyes.

So how have we been making this work?

1. Transparency

We use V1: Agile Enterprise as our project management tool.  The team uses the storyboard to move stories across the various stages of development, and we use tasks within that to log any issues that come up during testing.  If we log a task within a story, that story gets kicked back for rework.  We have ten columns on our board, so it is very easy to tell what is going on with a story, whether it’s in code, in review, in test, etc (you may have more or fewer; ten was the sweet spot we eventually came to through trial and error).  Anyone on the team can see at any time what is being worked on and where in it’s life a story is.  They can look at tasks within the story to see what kinds of stuff is being kicked back.  Our boss, who is in a different location, can go in at any time and see where bottlenecks are and what needs improvement and then formulate a plan to resolve any issues.  You can use index cards, other programs, carrier pigeons….whatever works for you.  But having this very high level of transparency about what is being worked on has been great for all parties involved.

2. High Visibility

I’ve mentioned our weekly demos in previous posts, but they very much bear repeating.  Without these weekly demos, this product would not be anywhere near the level of quality and, let’s not kid ourselves, awesomeness that it is now.  We have all of the people working on the product as well as our boss and the CIO (a major stakeholder with a lot of knowledge about the rest of the company’s involvement in the product) in the demo, and everyone’s input is equally valuable.  By doing these weekly demos we can ensure that the workflow we have envisioned works, and if it doesn’t we can figure out exactly what we need to change right then and there.  All parties involved can give feedback and present their thoughts on the issue and we can all put our heads together for some critical thinking and problem solving.  Even if it’s something like a minor design change we are very much able to address problems then and there, and sometimes devs will even make changes in the code right away in the demo so we can see what it looks like.  No need to wait 3 days for an email response or call someone and wait for them to get the answer.  Building this product iteratively with high visibility has been an incredible experience; watching it all come together, being able to make immediate tweaks to a system rather than finding out in beta that we’ve completely hosed something, bonding with each other during this hellacious time…I wouldn’t trade it.  It’s been intensely valuable to us, and the product? looks absolutely fantastic as a result.

3. Communication

Which brings me back to the root of every good and bad thing that I ever talk about: communication.  We communicate issues on the taskboard, we communicate the progress of a story on the storyboard, we communicate what is done to stakeholders by way of weekly demos, and we talk all the time to make sure everything and everyone is on the right page.  With this short, rapidly approaching deadline, we don’t have a lot of time for rework and dicking around.  We are all working together and keeping everyone in the know to make this project happen.  Without this intensely high level of communication we would be halfway through the project and it would look awful and we’d all be looking for new jobs come January. 

4. Awesomeness

Our team is incredible.  I love them like a weird family (the way I imagine carnival sideshow acts are a family), and without all of our contributions I can guarantee that we never would have come this far.  I just want to say I love you guys and cannot tell you how amazing it has been to work with you on this mind-numbing, hair-graying, frustrating, wonderful project.  You all bring, give, and do so much, and I sincerely appreciate all of it.  Let’s drink all the beer (in the world) Jan 2.

– The Bearded Lady

Verbing the Noun: A Hammer is Not Hammering, or, A Post About Separating Tools from Processes

The other day (read: several months ago) I was sitting outside talking shop with David Laribee.  We started discussing kanban and some things he does on his team, and I thought I’d finally caught him on something:

Me: But wait…you do daily stand-up on your team.  That’s a scrum thing.  So would you say you’re doing scrum-ban?

Dave (nonplussed, and without hesitation): Daily stand-up is a tool.  It has nothing to do with scrum.




Tools are not processes.

Tools can be used in any context, if they help you.  Don’t limit yourself to using only things prescribed for your particular methodology.  I’m no Jainist, but I’m still not going to kill a bug (except for that palmetto bug that I ironically attempted to kill with a copy of the Bhagavad Gita the other night [read: weeks ago], but that was life or death.  That thing was the size of a pony).  If something fits what you believe in or how you work, do it.

Prime example: Kanban is not a board.  The board is a tool used with kanban.  But how many times have you seen people get hung up on the board and focus explicitly on that as actually being kanban?

You don’t need to follow everything to the letter if it’s not working for you.  Using scrum for us was like trying to fit a square peg into a solid piece of obsidian.  Daily stand up sure helped though.  We were able to strip out things we liked from scrum and cut the things that didn’t work for us in order to improve our process.

What you do need to do is make sure you are understanding what you are working with/preaching/living.  If you said kanban was a board, maybe you need to do a little more reading and research.  And in doing so, you will surely find a lot more information that will help enhance your processes and give you a better understanding of how these things can help your team.  Maybe you’ll even find something better.

My recommendation is not to get hung up on making your team fit with a methodology or process (either because it’s the hot thing in development or because someone is cramming it down your throat as The Law); if some of the related tools are not working, drop ‘em.  Find something better.  Make your processes and methodologies fit your team.  Make up your own stuff.  Don’t feel pressured by the Kanban Kids or the Scrumies (Scrumites?) to work in rigid ways that don’t work for you.  We got a lot of crap when we started dropping things from scrum, but then “scrum-but” became a thing, because, well…scrum works for some, but it’s not ideal in every team/project scenario.

I’d love to hear more on this in the comments.

Estimating Story Size, or, Smidgen, Pinch, and Dash

In this post I am going to talk about something that has evolved on our team.  It may not be right for you but it has served us well and you may find it useful.

Over the past year we have tried many different ways to estimate stories.  We played planning poker (if that’s for you, this is a great tool for it [and great for distributed teams too]), we used story points, we used days, hours, timeboxes (2 weeks or whatever), I’ve heard of teams using t-shirt sizes…there are all sorts of things you can do. 

Having the whole team together to estimate felt wasteful.  Sometimes there would be no discrepancies, sometimes there would be too many discrepancies, and a lot of times the people involved in estimating would not even end up working on the project.  In any case, the estimates were always a lie.  So we eliminated some waste.

We cut it down to just the people who would be working on each story, but sometimes those people would get pulled onto other projects so the estimates would be wrong for the new person that would be working on it.  So we eliminated some waste.

We broke things into MMFs that contained roughly the same amount of work.  Sometimes it would be 20 small things, sometimes it would be 8 medium things, sometimes it would be one ghastly, horrible thing.  It was difficult to measure at first and we were wayyy off on a lot of things, but over time it got a little better.  So we made some improvements.

Now, all of our stories are same-sized.  When we write them we make sure that they are small, but not too small.  Our stories are all “two days worth of work or less.”  After our weekly demo of the current project (10am) we go through the next batch of stories/designs for the coming week (11am).  We talk them out amongst the people who are working on the project at the time and make sure that everyone agrees that the stories are all two days worth of work or less.  If they aren’t, I’ll go back and refactor them.  If they are, they’re ready to be worked on and they go on the board.

For our situation, this process really had to evolve like this.  I don’t know that it would’ve worked if we just jumped into same-sized stories right away.  Getting a feel for how the team worked and how long each thing took (making sure to account for spikes and other things related to a feature but not necessarily in a story) got us into a really good groove.

Formal estimation did not do us well.  Things would always run longer or run shorter, and both of those are bad.  Too long and you’re behind, too short and people will slack off to stretch it out.  Having same-sized stories makes planning a sprint easy.  It makes meeting deadlines easy.  It reduces a lot of stress that you would get from working on a huge story…on our team we would get brand new HIGH PRIORITY WORK on a fairly constant basis, so smaller stories mitigated context switching.  Using same-sized stories has eliminated much of our waste and simplified our planning, and, in general creates a clean, constant flow of work.