Don't Drink the Water!

I recently went on a mission trip to Tijuana, Mexico, going down with a group from South Church and working with Mexico Caravan Ministries.  When I signed up to go I was expecting to go down there and build a bunch of houses, pushing myself physically to get as much done as I could.  In fact, even before I left I had told the Mid-Michigan Agile Group that I was going to find ways to apply Agile principles to make the house building more efficient (and when I got back I gave this presentation: https://docs.google.com/presentation/d/18Xzs1YF6Vc4P45-PRh_IAdcIUQYcqSFrvlX9m1tQGNw/edit#slide=id.p).

Boy, was my head in the wrong game!  As it turns out, Mexico Caravan Ministries is not a house building ministry.  Mexico Caravan Ministries is missions mobilization ministry.  Specifically it is focused on giving young people a chance to experience short term missions, with the hope that some of them, who don't yet have a career or a family yet, might be willing to go into the mission field for 2, 4, 10 years.  We spent at least as much time building our relationship with God, understanding of scripture, and knowledge of global missions as we did building houses.

So what does a former ScrumMaster with a family and career who wants to do a lot of physical labor while taking vacation do?  Very much like the history of Caravan, I adjusted to my surroundings and changed some of my goals.  First off, I focused on relationships over efficiency.  I played with the children that we were building houses for.  I talked to the high school and college students from my church.  I had to admit that efficiency isn't the most important thing in every context.  Secondly, even though I did still look at some ways to "improve" processes (I did have a presentation to think about after all), I reflected on myself quite a bit and how I needed to be improved.  Even though I don't anticipate partaking in any long term missions myself, there are many ways that I can positively impact the world for the glory of God.  One way to do this is through discipleship.  By working to build up new Christians I can equip them to be a light in the world, and maybe they will be the ones to go to the deepest, darkest recesses of the earth, to reach those who have never heard of Jesus.  Another way for me to be more like the man that God wants me to be is by being bold in my faith.  For far too long I have defined my worth by what other people think of me, which has caused me to compromise my morals to win their favor.  The truth is, the basis of my worth is the fact that I am a child of God.  That is a value that does not fluctuate, does not diminish with time, and really doesn't even depend on me at all, because it is entirely reliant on grace (Ephesians 2:8).  I'm not going to be smacking people in the head with my bible, shouting "repent! repent!", but I need to make sure that I'm living a life that will cause people to ask me to tell them what it is that makes me different, and I need to allow God to use me for each one of those opportunities.

If I get the chance to participate in this trip again I'll be certain to go down with a different attitude and a different goal, and hopefully I'll get even more out of it.

Appreciation Goes a Long Way

While employed at Vertafore I was introduced to the Connect and Reward program.  I believe my initial comment to one of my colleagues was "so we're getting paid in high fives now?", but I severely underestimated the power of simple appreciation.  At its heart the Connect and Reward program was a portal for employees to recognize their coworkers' efforts by giving them eCards and/or points that could be cashed in for some actually pretty cool stuff.  I thought it was a nice idea but I didn't really see the big deal.  In hind sight I think my perspective was due to my experience with one of my Scrum teams, where long before Connect and Reward we were giving each other meaningful recognition and appreciation during our retrospectives.  As the ScrumMaster I was always very conscious about communicating "team" accomplishment externally, but inside the team, where people knew exactly what you were doing and understood the effort it took, for ten minutes every two weeks it was all about praising individual achievement.

Recently (July 5th, 2012) I changed employers and am now a manager at Jackson National.  During my first full week of employment I got the opportunity to see one of my team members rise to a particularly difficult challenge.  It was an emergency request that required a lot of extra hours and effort.  I felt he deserved something for his efforts, but didn't want to do anything requiring money (keep in mind, I hadn't even been employed a week, so for all I knew these things happened frequently enough to put me in the poorhouse in no time).  I thought back to the Connect and Reward program and the badges that you could give to people.  I decided to hack together my own little "Wall of Awesome" webpage, just a series of images of badges that when clicked on pop up a plaque with a very militaristic sounding recognition.  With minimal fanfare, and even less expectation I gave a printed out "Awesome" to the developer who shined through the emergency and to another team member who helped deploy all the changes needed.  I couldn't have been more shocked than when a couple minutes after delivering them one of them came to me, with a slight tear in their eye, saying how this is exactly what they've wanted, to be appreciated.  Now encouraged to continue I have slowly found ways to appreciate most of the people on the team (hopefully I'll get everyone by the end of the week), and I think everyone has cut out the plaque from their printout and placed on their cube wall.  I even had one team member come by my cube yesterday, just stop for a second and smile, and when I asked how they were doing they said, "I'm awesome!", then went on their way.


I'm so glad I took the risk of looking cheesy or lame, because even if the effect is lessened with time, I have had a chance to really make people feel like they had worth and that their work was valued, and that is something that I will cherish.

Is setting hard commitments setting up to fail?

I was at a meeting of Mid-Michigan Agile Group this evening where we discussed how to better estimate software projects at a high level.  At the heart of this discussion was the idea of trying to make an up front contract by which you agree to provide an agreed upon amount of content, by an agreed upon date, for an agreed upon price.  The ScrumMaster in me starts to cringe at the thought of making commitments beyond the scope of a sprint, but the realist in me knows that especially when it comes to State contracts you end up having to promise just that.  So what is so bad about it?  Well, I would argue that when you make a commitment like this you will end up either not delivering on all of your content commitments or giving yourself too much time to get things done.  I would say that I have always (at least felt like I have) been on the "cut content out" side of this approach, or at least on the "cut every corner possible" side, which of course leads to increased technical debt.

So what do you do?

I think a slightly better approach is to break done the monolithic contract into several smaller pieces and within each of these you prioritize the features that they want at the moment, with a commitment to (for example) half of what you think you can get done with the hope of delivering some other content, then repeat as many times as it takes to get the customer all that they need.  Sound hokey?  Consider these benefits:
1) At any point the customer should have something of value.  Okay, so this is basic iterative design, Agile 101.
2) At any point the customer can decide they have enough value.  This way they aren't wasting money and you can move on to the next project.
3) The customer feels more in control of what they get, when.  Customers will be able to pick the few things that they absolutely need with the next release and pick some nice to haves.  They should be doing this at the sprint level too, but (I think) they'll be less likely to feel empowered to change the road map of the "epic product" as they would the bite-sized release.

So what is the end result?  You'll (hopefully) end up with always having more to do, with you always working on the most valuable features, and always finishing right on time, because the customer decides when you are finished, rather than you deciding how to cram as much of what you think is most valuable to the customer into a predefined time box.

Here's a though exercise.  Imagine you in five years.  Let's focus on your house.  Would you be comfortable picking everything that you want done to house in the next 5 years and deciding how much to pay for it now? What if your priorities change (you need the deck finished right away for the graduation party)?  What if you have to move (you don't want things looking half finished or unmatched but you don't want to pay two mortgages while waiting for work to finish)? What if you decide that you don't need certain projects any more (now the swing set isn't needed due to a new park down the road)?  In the end I have the luxury of being a developer... just give me work, and I'll do it.  It's not my fault if it isn't the "best" work I could be doing for the customer.