By now, everyone in software has heard of agile software development, and for the most part about scrum. Almost everyone, at some point, has worked on a team who has done agile with varying degrees of success. About half the companies I know have, quite frankly, implemented agile completely wrong and it has made their process even worse. The other half have used it with some varying degrees of success, but rarely to the degree as the “mythical teams” whose productivity elevated to a whole new level.

DDM uses agile and scrum, so when I joined and started managing the Deseret News team we had our agile process: sprints, estimations, standups, planning sessions, etc. It worked well for the most part, but we still struggled as a team to find that next level of productivity. It always felt like we were missing something, so we’d shuffle things around. One week sprints to two week sprints, which day to hold the meetings, who was involved in what, etc. But no matter what we did it felt like we were just shuffling things around. We couldn’t achieve that next level of productivity.

On the same floor as us was another team: the Deseret Connect (DC) team. They were extremely productive with their agile process. Stories were defined, prioritized in their backlog, and finished in a very timely manner. The amount of work they were accomplishing was incredible. I would sit in my office wondering how they pulled it off. They did pretty much the same things we did, so I chalked it up to the differences between the projects and that we just naturally had a more chaotic environment.

As december rolled around, and we were preparing for a new year, we decided to completely revisit our process and revamp our agile process again. Our Product Director used to also be the scrum master, but we found it was very hard to manage the demands of the product as well as manage the process. So Steve Ostermiller, the project manager for the successful Deseret Connect team, joined our team with the sole purpose of helping manage our process. This allowed our product manager Mike to solely focus on our backlog and definition, and Steve focus solely on how the process was working.

Steve brought with him a meeting outline that we would follow for our semi-weekly sprint planning sessions. On it he had an item called “Previous Sprint Retrospective”, which I hadn’t heard of before. It seemed so straight forward it was almost embarrassing to think you needed to spell it out. It asked three simple questions:

• What went well?
• What we’d like to change
• How we’ll implement that change

So in our first new sprint planning meeting, we asked ourselves these three questions and wrote down a summary of our answers:

• What went well:
  • Backlog/Icebox organized!
• What we’d like to change:
  • Coordinating emergencies
  • Better & more timely definition prior to Sprint start
• How we’ll implement that change:
  • Coordinating emergencies
    • Designate point person (product manager) for all requests to come through
    • Proactively coordinate with [Ad Ops] before Sprints start
  • Definitions
    • Give Christian and Mike time over the next couple of weeks to define & prioritize the Icebox

It was nothing earth shattering, our icebox was a mess and we would get interrupted during the week by Ad Operations with last minute requests. So we wanted to work on these things. We continued every two weeks in our sprint planning meeting to reflect on the previous sprint in our retrospective:

What went well:

• Kept Gary & David more focused on daily basis

• SoftServe backlog increased, with fewer late nights for Christian

What we’d like to change:

• Get stories broken down, especially on mobile site

• Chores list should be in Pivotal

• Streamline daily standups

How we’ll implement that change:

• Chris has the task to define mobile stories

• Justin convert “Christian List” to chores in Pivotal

• Justin consider with SoftServe a time for entire team to be at standups (9:00/10:30?)

Again, nothing ground breaking, just a list of things that went well and didn’t go well, and what we wanted to change. We’d look at the previous sprint’s list and see how well we did on the things we set out to change to make sure we did them. Week after week, we’d set aside this time to revise the process and see what we wanted to change.

Heres the thing: it worked.

It worked extremely well.

It has been 10 sprints (so 20 weeks) since we started this new methodology and we’ve seen incredible improvement:

We’ve doubled our velocity as a team. In hindsight, it seems so obvious: we started iterating over our process, not just our code.

We would find more things to change and modify in our process. When we started this process, we were tackling big problems like a backlog and tasks that lacked definition. Once those were fixed, we started to notice other things to help the process go along. However, these things to change would never had been noticed if we weren’t regularly iterating over our process.

It’s not just our velocity that has increased: we’re hitting our deadlines much better. We’re able to make decisions about features much more confidently. When a new feature comes in, we can estimate it’s impact on our deadlines and decide what course of action to take.

What is even more crazy is these last 10 weeks have been extremely disruptive for our team: our senior developer, who had 10 years of legacy knowledge, left our team for another job. Another of our in-house developers had to take extensive time off to help with a family crisis. For several sprints we were running with 60% of our team. However, we had our solid process, and we followed it. We came out releasing a major project on-time. So when our team got back to 100%, our velocity started to take off even more.

I truly believe the Retrospective really unlocked the potential of agile development: We went from shuffling around our process to iterating over our process. What kills me is every time I’ve heard someone talk about the agile process, I’ve never heard anything about doing a “retrospective” before. I’ve heard about estimations, backlogs, sprints, velocity, yet the central principle, the very catalyst that can take whole agile process to the next level, seems to never get any attention.

So if you’re not doing a retrospective, start doing one. If you are, start sharing it with others. It has been the catalyst in our team finding it’s next level of productivity, and has help us solidify our process into a well-oiled machine.

Today I saw a few mentions on twitter about a blog post by the Harvard Business Review on the Seven Rules for Managing Creative People. The reaction has been rather, well, negative from those who are “creative people.” Some thought it had to be an April Fool’s joke, but it was published on the 2nd, not the 1st. The article acknowledges the great value creative people have in a company, but then is condescending in it’s recommendations for managing them. The big issue was #5: Pay them poorly.

Pay them poorly: There is a longstanding debate about the relationship between intrinsic and extrinsic motivation. Over the past two decades, psychologists have provided compelling evidence for the so-called “over-justification” effect, namely the process whereby higher external rewards impair performance by depressing a person’s genuine or intrinsic interest. Most notably, two large-scale meta-analyses reported that, when tasks are inherently meaningful (and creative tasks are certainly in this condition), external rewards diminish engagement. This is true in both adults and children, especially when people are rewarded merely for performing a task. However, providing positive feedback (praises) does not harm intrinsic motivation, so long as the feedback is perceived as genuine.

I understand what the author is trying to get at, but I believe it’s worded rather, well, poorly. After 200+ angry comments on his post, and hundreds more angry tweets, the author does apologize and states he should worded it as “don’t overpay them.” That is better, but I would take it one step more and reword it this way:

“Don’t motivate solely through pay”

If the only reason your creative employees are working for you is pay, you’re doing yourself a severe disservice. Creativity isn’t restricted from 9:00am to 5:00pm. While your employees aren’t directly working on a given project, you want them to be mulling ideas over at any given time. I find my most productive “thinking” time is when I’m showering in the morning, and many problems have been solved over several days of “shower time.”

If you’re creative employees are only working for the money, the likely hood that they’ll let their creative process work while not at work is very low. Instead, they’ll just try to force their creativity while on the clock and you’ll end up with sub-par results.

There are many motives for a employee to work for you aside from pay. Joel Spolsky has a great white paper on 10 motivating factors for developers that are just as important as pay. I plan on doing a whole post on several of these factors, but that is for another night.

So if you were to take away anything from this post, is that there are so many more important things than just pay for an employee, and if they only work solely for the pay, you’re likely not getting the best they have to offer.

At work we use Omniture for our web analytics, and for a long time I’ve wanted query our Omniture Data to run some internal reports. I discovered that Omniture has a restful reporting api, and after using it for a little bit I decided it would be nice to write a wrapper library for it.

Since I had recently taken the PHP Testing Bootcamp from Chris Hartjes, I decided I wanted write it using Test Driven Development and really get my feet wet. I also decided I wanted to make the library compatible with Composer. After the weekend was over, I had an almost finished library that just requires some more work to be done, but I learned a great deal that I thought I’d share.

Lesson One: TDD is 90% changing the way to write code, and 10% writing tests

Every other time I tried to start writing tests, I would get frustrated because I couldn’t really understand how to write tests in “real applications.” I understood the basics of assertions, but I couldn’t connect the dots to really write tests for real code. The problem was that to write testable code, you need to have loosely coupled code, which is much more easily said then done.

This is when the Law of Demeter comes into play. It basically states “only talk to your immediate friends”, and from an OOP stand point, it means your code should be broken up into pieces that only communicate with other pieces it’s immediately related to. There are some articles written about it, and Chris’s book on Building Testable PHP Application talks about it pretty well.

Basically, if I ever ran into a situation where I thought “Man, these tests are hard to write” then I likely had a tight coupling issue with my code.

Lesson Two: Understanding Mock Objects is the real key.

Once I used a few mock objects, I really started to “get” testing (at least I think so). I can honestly say this was the missing key in my previous education with testing. I found the Mockery library which makes writing mock objects quick and painless.

Lesson Three: It takes almost twice as long to write code and tests then just code

As I started coding, I did notice it felt like it was taking a great deal longer to write the tests, and then the code, more than I expected. I first attribute this to my inexperience in writing tests, figuring out how to test certain scenarios, etc. But I imagine even when I get the hang of it more, it’ll still increase development time significantly.

And you know what? Thats okay, because I realized that I was catching lots of little bugs up-front. I was “hardening” the code so to speak making it feel much more solid than when I just write code by itself.

Lesson Four: Its extremely easy to get out of the habit of writing tests.

Even after a few hours of coding, I realized that I had created some classes that I didn’t write tests for. It was really easy to just slip out of the discipline of writing the tests, and to be honest there are a few more tests I still need to write. However, I did also notice that as soon as I stopped writing tests first and writing code to satisfy the test, I introduced a few bugs that took me some time to figure out.

Lesson Five: You’ll refactor quicker and more often when writing tests

Because you’re writing tests for your code, you get a feel for how you’ll be using the code. For me, when I was writing this library, there were a few times where I thought “Hrm, this is kind of kludgy, I should have written it another way.” I discovered these problems so much sooner in the process of coding, and I really was starting to really understand the power of writing tests.

So what did I do? I just changed the code to the new way and ran my tests. I saw what it all broke, fixed the code that depended on the old functionality to the new functionality, and I was done. It was amazing how much more simple refactoring was when there were written tests in place.

Lesson Six: Having testable code made me feel much better about sharing the code.

I didn’t nearly have much trepidation about sharing the code I had written. I knew that what I had completed worked, and it was likely a great deal more bug free than most quickly written libraries I have lying around. I also can easily share this code with other teams here at work to help them pull their own data.

So I don’t know how many people who will read this will be in need of a PHP library for interfacing with the Adobe/Omniture Site Catalyst Reporting API, but they could quite easily start using my library and contribute back if they wanted.

I still have so much more to learn about writing testable, but I’m excited that things are starting to “click” in my head. I can see and understand just start writing testable code, and having my code be much more durable in the future.

I saw this picture and it really drove home the idea that mobile devices have become a major part of our lives. Here are two photos: one from 8 years ago when Pope Benedict XVI was introduced at St Peter’s Square, and one of just the other day when Pope Francis I was introduced. Its startling the one single contrast. Its amazing how technology can be a part of our lives.

(click to see the full image)

Here is a useful website for evaluating regular expressions for PHP and testing them out live.

http://www.phpliveregex.com/

Before when I worked from home, keeping a continuous connection to IRC wasn’t that big of a challenge. I was always on a great connection that I controlled. However, since I started my new job, I’ve been struggling for the last 10 months or so to stay as connected on IRC as I had in the past.

See, half the time my laptop is connected to our network through a wired connection when I’m working at my desk. It is extremely fast, and I have all of the access I need to our internal production networks. However, when I go to meetings (which can be a lot), I switch over to the wireless. For whatever reason, the ports to Freenode’s IRC channel are blocked, so I can’t access it. Then switching back and forth every day causes me to connect, drop, etc. Also, when I commute I don’t have my laptop open and connected to the internet.

Long story short: I wasn’t on IRC nearly as often as I’d like, and many times I’d miss out on conversations or messages people tried to send me. This is especially important with the Utah PHP Usergroup.

I had heard of some ways of using Irssi and screen, but I much prefered using my own Mac OS X client of limechat. So after some Googling around, I found my answer: ZNC.

ZNC is an “irc bouncer” which is basically a very sophisticated proxy, and in many ways it is almost a mix between a proxy and a bot. ZNC is a program that you can install on a computer that has continuous connection to the internet that will connect to your IRC channels for you. I have my running on a small cloud server. Then, instead of having my client connect to the IRC server, you connect to your ZNC server.

Some of the immediate benefits are being able to connect from multiple clients and have them use the same “connection.” On the train and want to use your phone, and then continue the conversation when you get to work on your laptop? You don’t have to worry about the connection, ZNC will handle everything for you.

Also, if you’re not connected at all, it can still accept messages and record channel buffers. Then when you re-connect, it can reply what you missed for you.

Best of all, I have my ZNC listening on port 443 as well as 6667, so even if I’m on a locked down network, as long as port 443 works (HTTPS), I can stay connected on IRC.

Little nerdy tool I’ve picked up, but I’m really glad I’ve found it.

Eh, I know I’m late publishing this post, but oh well! 2012 was an amazing year for me: new job, first baby boy, new responsibilities. There were a lot of firsts for me in 2012. So now as I look at 2013, I pretty much think it’s time to iterate over the year again and just try to improve in several areas.

Several changes in 2013 are that I’m now the current President of the Utah PHP Usergroup, which is awesome and daunting at the same time. This year it will be celebrating it’s 10th anniversary as a group, and has been meeting regularly since it’s inception. Which to me means: crap, don’t mess this up! We’ve had a lot of awesome guys run the group over the years, and I hope to be able to do as good of a job as they have done.

I have some very large projects happening at work, at to be honest, it’s a little frightening. Why? Because I won’t be doing much of the actual programming for them, but rather my team will be. In the past, I would rely heavily on my own abilities as a programmer to take on big challenges. Now, I can’t possibly do it all, and the bulk of the work will be done by the four other developers on my team. My biggest advantage is my team, though smaller than some of the others at DDM, is definitely filled with awesome devs. I have complete confidence in Gary, David, Stas, and Serhi. However, it’s going to be a learning experience focusing on directing and managing the project instead of coding it.

Finally, I’ll just say this: it’s awesome to be a dad. I love coming home, leaving the laptop in my backpack, and playing around with Marshall. He loves to respond and play back, even if it’s mostly just giggles and smiles. I know 2013 is going to be a year of lots of firsts for both of us, and I’m excited for whats ahead.

I read an article about startups that just really just summarized one of the greatest struggles that they face, and how so many of them are oblivious to the problem.

Here’s some stunning, Earth-shattering news: You know all those hundreds of incredibly stupid startups that have been raising seed money in Silicon Valley despite the fact that the people running those startups have no experience doing anything, ever, and have no idea at all how to generate revenue (let alone profit) with their lousy ideas, because, in fact, there is no way to make money with their lousy ideas, because in fact their ideas are lousy?

Well, nobody wants to give those dopes any more money. So now they’re going to go out of business.

I know. Shocking.

I’d recommend reading the entire article, but the summary is this: it is hard to make a profitable business. Just because you use modern technology and call it a startup doesn’t make that fact any more different. There are really good businesses with great ideas that struggle to make a profit.

While I don’t watch South Park, there is an episode I’ve learned about that expresses these startup business plans perfectly. You see, there are these gnomes who have a great business idea of stealing underpants and then profiting from them (warning, they do swear once in the video):

You can watch the whole clip (which contains more swearing and such) to see just how ironic their idea is. The reality of the matter is that this episode right at before the big Dot Com bubble was about to burst, and soon journalists and analysts were using this example of why so many companies failed to become successful.

So a decade later, and we’re running into the same issue. Now I’ve worked for several startups in the past. In fact, the majority of them are still in business making a profit 5 years later. So since they were profitable, am I now filthy rich? Nope. Even when we made a profit, it wasn’t astronomical, nor did Google swoop in and want to buy us out. It was just more hard work to make more profit.

So many people have this idea of forming a startup, gaining a large user base, and in turn making their product “valuable.” The trick is, eventually, even if everyone in the world thinks its extremely valuable, you’re going to need to convert that value into revenue and hopefully profit. If Facebook and Twitter are struggling to do it, how do you plan on changing that? I can guarantee you it won’t just magically happen.

So right now, the majority of startups I know their plan is like this:

• Step One – Make a Website
• Step Two – ???
• Step Three – Be Purchased for $$$$$$$$$$$

You know what, that is totally fine, as long as you realize that the probability that you’ll fail is extremely high. The sooner you find a way to define step two and convert value into profit, the sooner you’ll be successful.

Personally, my biggest rewards from working at a startup haven’t been the paychecks from the business. Its been the investment I’ve made in myself by growing my experience and skills. So go ahead and work for a startup, have realistic expectations of your probability of success, and go at it with everything you got. If you walk away with better skills, more experience, that’s great. If you make some money while doing it, even better. But ultimately, the likely hood of “making it big” isn’t that great.

If you’re only working at a startup to get rich, you’ll be sorely disappointed. If you’re working at a startup for the whole experience, there is a good chance you’ll walk away with a better investment in yourself, maybe some money in your pocket, and hopefully experiences and skills to take to your next job.

Thursday morning at 12:36 AM, Joanna’s water broke. Eleven hours later, Marshall, our first son was born. It was an amazing experience. I’ll likely be posting in the future about the wonderful, and truly humbling, experience of becoming a father. However, I want to talk about something very different.

One year ago, Joanna and I were in a very different state. We were struggling with infertility. We were undergoing tests after tests, trying to diagnose why we were unable to get pregnant after trying for two years. While no diagnosis had been found for our infertility, Joanna was diagnosed with depression and anxiety. We struggled month after month of trying with no solution in sight. It was completely humbling as our life plans and hopes were slipping through our fingers and I could do absolutely nothing to “fix it.” We watched as dozens of friends, family, and neighbors got pregnant, gave birth to their babies, and lived a dream we thought we might never have. It was a very serious personal trial for my wife and I, one which can still bring tears when we look back, even though we’re “passed it” now.

The reason I bring this up, such a private and personal trial, is because for the majority of the time we were trying, my wife and I suffered through it alone. We didn’t really share this trial with anyone else. It wasn’t something we talked about with others. Only the very closest of friends had any idea. It wasn’t until much later, that we talked to other people, and realized that we weren’t alone.

15% of all couples will struggle with infertility, and as we talked with friends, family, and neighbors, we found so many more people who had gone through the same things as we had. Suddenly, we realized we had such a large support group of people who had gone through what we were going through. We could have had that support group so much sooner had we just opened up and talked about it with others sooner.

We sought out help for all aspects of our well-being. We started to work with a therapist to help work through some of our emotional trials. I cannot recommend high enough talking with a good counselor or therapist. Every time I see a “shrink” on TV or a movie, I want to just tear my hair out because of just how “fictional” those scenarios are, usually for comedic value. Our experience was nothing like that, it was like talking with a normal person who just helped us view our situation through other view points. He just helped us understand our thoughts, emotions, challenges, and helped us find way to healthily coupe with them.

We patiently worked with fertility specialists to come up with a plan to improve our chances of getting pregnant. We also talked about adoption, and we were starting the process by the time we got pregnant with Marshall. We worked with a physical trainer to help improve our physical health & nutrition. We had taken everything that was in our control and made a plan, and then left the rest to God and accept his plan for our family.

I feel incredibly fortunate that our struggles with infertility only was for a few years. There are so many amazing couples who will make incredible parents who struggle with infertility for much longer, and some ultimately will not have the opportunity to experience being a biological parent. My heart goes out to these great people, and I know that our Heavenly Father is acutely aware of their struggles & hasn’t forgotten or forsaken them, and has plans for each and every one of them and their families.

So you, as the reader, what do I hope you get out of this?

If you’re not struggling with infertility, just to simply be aware of it. Before going through this, I had no idea just how prevalent infertility is. I also can remember times where I put my foot in my mouth with others who likely were struggling with infertility. Joanna and I had comments from friends and neighbors who would say things that had the best intentions, but stung from our point of view. If you ever find yourself where you’ve put your foot in your mouth, don’t worry, a simple acknowledgement is more than enough. We understand what you said wasn’t intended for how it was heard.

The best advice is just to never assume that a couple has chosen their situation when it comes to children. Whether it is no children, one child, or even a dozen. It is a topic that can always evoke very deep, strong feelings, so always just be careful.

For those who are struggling with infertility now, or might struggle with it in the future: reach out to others and don’t struggle with it by yourself. You’ll get advice from many people who have no idea what their talking about, but mean well. I think Joanna was ready to punch the next person who told her “just relax and it will happen.” Find people who have actually gone through a similar situation to you. It was extremely helpful just to be able to vent stories with others. You can also learn of different options and ways to help your situation you weren’t aware of before. You’ll find out that in reality, each couple is unique, and each will differ from what is the right answer for your family. It is a choice that you and your loved ones will need to make. So please, reach out to others that you trust to treat your situation with the delicacy that it deserves.

I truly believe that every couple dealing with infertility can find peace and comfort in their situation to be able to coupe. The first step of finding peace and learning to coupe is to reach out to others and not try to struggle alone.

Finally, a thank you to the dear friends who had struggled with infertility and shared their stories with us. You know who you are, and I cannot thank you enough. I truly believe that if it wasn’t for your help, we wouldn’t have been emotionally healthy enough to get pregnant with Marshall, and we wouldn’t have this little sleeping boy in our room tonight. You truly have enriched our lives during some of our greatest trials, and will always be the dearest of friends to us.

Thank you.

I’ve been lucky to work for several successful startups. Granted, they weren’t Facebook or Twitter, but almost all of them turned around good profits and/or were bought. I’ll admit, working at a startup is, well, a lot of work. There are articles written about long hours and hard work. Even articles about telling people to quit whining about the hours.

Now I really appreciate my opportunity to work with the companies I did. I remember working long hours, even 80+ hour weeks during crunch time. I remember sleeping 3-4 hours a night and working pretty much every waking moment. This culture is pretty pervasive in the tech industry, and working 40 hours a week for many companies just isn’t enough. Even outside of a company, there is a feeling of pressure for programmers to spend most of their free time working on their skills.

So last week when our CIO & VP of Technology, Stephen Tolman, talked to our technology team in a meeting, it was a very different tone. He quoted David O. McKay: “No other success can compensate for failure in the home.” He stated that our first priorities are our families. Not our deadlines, not the number of hours worked, not our company’s profit, or anything else. Are these things important? Of course they are. But they are not to come at the expensive or sacrifice of our families.

At Deseret Digital Media, while we are a larger company, out technology team is about 30 people. However, because of the so many different projects we have, each team just has only about three to four developers on them. So in a lot of ways, we’re a company of 6 or 7 small startups all bundled together in the same building. We do a lot for a team of our size.

Tolman then outlined exactly how we would continue to be a successful as a team while working just 40 hours a week, taking vacations, taking sick days, and taking care of our families. I’ll cover more of those details in future posts, but its great to work for a company with these values.

There was just one more part to this story: I wasn’t actually at this meeting. I was working from home trying to recover quickly from a cold. You see, my wife is due any day now with our first child, and we wanted to try and get me heathy before Marshall was born. So while technically I could have gone into work, I felt zero pressure to do so and just worked from home several days last week trying to recover. So everything I had heard about this meeting was from my fellow co-workers who explained it to me. When I finally was able to go into work, on my 1-on-1 with Tolman, he explained to me everything I had missed in the Tech Team meeting. He wanted to make sure I knew our priorities, family first, and exactly how we will be productive while putting our families first.

I really hope that many more companies can adopt this type of mentality. I feel like I can give 100% here at work, because when I need to go home, I can leave work at work and support my wife and future son.