Gary Allison's Cloud Blog

Last night, I read a passage in the Steve Jobs Bio recounting a conversation between Steve and Mike Markkula as Steve was contemplating his return to Apple.  The passage was about reinventing a company, and struck me as very poignant as I had just spoken to my team a few weeks ago at our 2012 kickoff about reinvention.  The passage

They spent the rest of the time talking about where Apple should focus in the future. Jobs’s ambition was to build a company that would endure, and he asked Markkula what the formula for that would be. Markkula replied that lasting companies know how to reinvent themselves. Hewlett-Packard had done that repeatedly; it started as an instrument company, then became a calculator company, then a computer company. “Apple has been sidelined by Microsoft in the PC business,” Markkula said. “you’ve got to reinvent the company to do some other thing, like other consumer products or devices. You’ve got to be like a butterfly and have a metamorphosis.” Jobs didn’t say much, but he agreed.

How prophetic. Also evident in the book is that not only did Apple have to reinvent itself, Jobs had to reinvent himself to a degree in order to become an effective CEO.

Reinvention is the key to all success and the path forward. For teams and companies to grow, they must recognize that the things that worked in the past which made them successful, will have to change, be reinvented, to continue that growth.  Since growth = success in our measurement system, then change requires reinvention.  Approaches, processes, technologies, teams, communication – it all must be reinvented all the time.

Five years ago, I wrote a blog about leading through change.  Rereading this now, I feel it is still on target.  At the time I was thinking about change that is sourced from the outside.  Reinvention is sourced internally.  The same strategies apply.

Sunday, an article appeared in our local paper that has everyone buzzing over a talent shortage in Austin. I agree a talent crunch may be looming in the near term, and we’ve been working to prepare for it. Rather than describe some of our recruiting strategies here for continued growth through this crunch, I thought I’d share a few simple things that we do to take care of the people we already have. I’m comfortable sharing this because they are so simple, but require so much effort and constant attention, our competitors will likely not follow this advice anyway.

To sum it all up succinctly: ensure people have meaningful work, that they work with truly excellent peers, put them in control of their efforts, recognize their success both individually and as a team, and keep them pointed towards a compelling vision. Simple, right?

The challenge in the above is that you have to create a culture by which all of this is possible. This culture creation is the extremely challenging aspect – it requires years of investment and continual nurturing. And, since this culture drives even more success, you have to be able to scale the team and yet retain the culture.

So, a talent crunch is likely indeed coming. When the COO of facebook is out encouraging students to study computer science, you can be sure there’s an issue. But those companies without the culture I describe here will be far more crunched than those with one.

Last week, one of my team members forwarded me a link to this blog by Savio Rodrigues, entitled Why devops is no silver bullet for developers.  It’s a well written blog and Savio makes some good points, namely that environments that the Devops team hopes to build on need to be standardized. He comes so close to hitting some important topics right on the head, and then just misses the mark slightly, IMHO.

Savio nails it when he points out

“One thing I’ve come to understand is that these two groups tend to think differently, even if they are using the same words and nodding in agreement.”

Bingo Savio.  He goes on to say,

“It’s no surprise developers want to adopt tools and processes that allow them to become more efficient in delivering new applications and continuous updates to existing applications. Today, these two tasks are hindered to a degree by the operations teams that are responsible for production environments”

But then, he misses an opportunity to drive the point home and starts a discussion about standards. I agree standards are important, but what needs to be reckoned with are the very different culture, goals, and reward systems between the two disciplines of Engineering/Development and IT/Operations.

How are these teams measured and rewarded? The answers to these questions tell you many things about the team’s culture. A Development team is typically measured and rewarded by amount of innovation, quality of their deliverables, timeliness of delivery, and responsiveness to market.  An IT team is measured and rewarded typically by uptime, stability, security, and control.  (Note rewarded can mean “not punished due to failure” as well as more expected definitions of reward).

All of the above seem like good things! We want uptime, innovation, quality, stability, etc!  Right? I envision one could draw a Venn diagram for the Dev culture and the IT culture and there would be overlap, but there would be just as much outside the intersection.  Innovation is often at odds with stability.  Responsiveness to market can be at odds with uptime, etc.

We’ve had the good fortune of having a few opportunities to implement a new Devops model.  When everyone is rowing together the boat certainly moves faster in the desired direction. But it is difficult. It requires continual investment in the Devops team because at the core, these two very different cultures aren’t going away anytime soon.  Savio sees it too when he says, “This isn’t a technical issue. It’s a cultural issue.” I’d suggest we spend as much time looking at the measurements and rewards as we do thinking about standardizing platforms.

This is unquestionably one of my favorite times of the year – surrounded by family and tradition, all the memories of Thanksgivings past flood back over me.  I am so Thankful for my amazing family, that I have been able to celebrate another year full of joy and challenges, seeing my daughters grow up and change so much, and still being able to share these things with my Mom and Dad. I’m Thankful for my good friends of various and assorted funny nicknames and for them helping me smile when I am overly stressed.   I’m very Thankful for my amazing and supportive wife who gets the pleasure of seeing all that stress as well, handling it with grace.  Finally, I am so very Thankful for the talented, brilliant, and dedicated people I have the privilege of working with every day.  To every engineer, support tech, IT engineer, sales person, account manager, web developer, product manager, marketing professional, trainer, and fellow exec, you really are changing the world and making it a better place.  Thank you for letting me be a part of it.

Reaching the Summit

Today was an especially good day.  Few things can compare to seeing the combined efforts of a large team who has worked so hard together towards a shared vision finally reach that goal.  Like hikers on a long trek finally reaching the summit, today we took time to survey the terrain we conquered, thought a little about the road ahead, but still enjoyed the moment.  Building SaaS based products with Agile process can result in a relentless pace, so these moments are special.

I’ve had the pleasure of leading terrific teams of very talented people in delivery of software projects, and this day, I have the privilege of leading the best of those.  The scale of innovation, integration, and imagination that as a team they delivered is a tribute to their commitment to our company and our clients.  For me, it is a huge thrill to see what months ago was a set of ideas turned into a quality solution.

Today, in our team meeting, I tried to convey the importance of this accomplishment.  Ten years from now, each of us may look back on this day, proud and maybe a little amazed of what we did together.  There’s a very good chance many of us will never deliver so much innovation in one day again on this scale.  I’m proud of our team, grateful for their efforts, and hopeful many non-profits will benefit from their hard work.

This article is fascinating; I just couldn’t stop reading it:  http://www.neowin.net/news/the-turbulant-times-of-the-playstation-3. I have a lot of respect for Sony, but this is a classic story of the downside of closed systems, blunders that are so easy to make when trying to lock down proprietary systems, and the exact wrong way to respond to the market.  Sony has a huge base of enthusiasts, and instead of engaging them and seeing it as an opportunity, they continue to see it as a battle they must win so they can stick to their predetermined strategy.  A must read.

In a prior post, I wrote about the relentless pace at which our Agile development moves, especially as it is teamed with delivery of software as a service (SaaS).  One of the consequences of this speed of constant delivery is that there’s never time to go back and “clean up” any of those important but not urgent tasks that you just didn’t get to in the sprint.  You know the ones I mean – that last unit test you really should write, fixing a low priority bug, UI tweaks, or automating all of the QA tests.

We’ve found that at the core of this challenge is that the team may not all be engaged simultaneously on the same project.  As I work with other Engineering executives, many face the inherent conflict of QA sprints that lag behind development sprints.  On the surface, this seems natural.  After all, there’s nothing to test until it is written?

We know from test driven development practices this doesn’t have to be the case. Even if not following strict test driven development practices, with careful development story planning, the UI aspects or API stubs can be built first in the sprint, so by the time the QA team has spent a day or two planning test scenarios or preparing test data, they can begin automated test development.

We also find that we need for new code development to stop at some point in the sprint. From that point to the end, developers are only fixing bugs found by the QA team in the sprint, completing those final few unit test cases, taking on usability feedback, and otherwise driving to complete.

By taking this approach, the developers and QA engineers stay together, focused on one goal as a team.  That goal is sprint complete of a high quality and finished deliverable.  The result is far fewer lose ends, a higher quality product with less rework, and just as important a team that works together.

On my day off today, I find myself contemplating how little time there is to smell the roses (and write blog posts).  We have so tuned our processes that really there is no downtime.  It turns out that when you add Agile development processes to delivering software as a service (SaaS), what you achieve is a relentless pace of innovation.  That’s good right?

Well, it does have a few consequences that are important to manage.  First is that there is never time to go back and finish that unit test, test automation, or UI tweak you really wanted to do last sprint.  You need to be complete and ready to move on to the next project.  We’ve been working on ways to improve here which will be part of a follow up post (really it will).

This post is about another consequence – we deliver innovation so quickly while also working on the way we deliver that it is easy to lose sight of how far we come.  As I overheard on a flight yesterday, “the days are long and the years are short”.  So true.

To combat this in my team, we try to be as rigorous about our celebrations as we are about our delivery.  We deliver somewhere around 10 times a year (even more with minor updates) and this will only grow as our product line continues to expand.  Still there are certain deliveries that stand out as larger accomplishments and 3 times a year as a team we will take a day and celebrate.

Often these celebrations include a team engineering event – we’ve built tinker toy towers, water balloon launchers, and aqueducts.  We’ve played kickball, laser tag, and cruised the lake on a party barge.  Once a year in Dec/Jan, we will take stock and as a team, share what we feel are our largest accomplishments as we also layout how we want to raise the bar for the next year.

It can be exhausting at times to be a part of the relentless pace of Agile delivery, and at those times when the release is rolled out to clients, maybe the last thing you want to do is plan a celebration. But every time we have one of these events, I am reminded what great people we have on our team and how much they deserve (and need) these times together.

Lots of discussion lately about measuring productivity has had me spending time I should be sleeping thinking about the same.  I love accountants and finance folks.  I find them very bright and love the way they typically approach any business discussion from the point of logic, but they can be an intractable lot as well.  They’d love to measure software engineering efforts like a consultancy – hours in, output out, utilization metrics pop right out the other side of the equation.  More utilization of the team means more productivity!  Wonderful!  Its so simple and we should have figured this out so long ago.  All that time wasted counting KLOCS and function points….

Of course it doesn’t really work. You can count hours, or days, or whatever to your hearts content but you are only measuring effort.  And, measuring effort of a software development group is an exceptionally tricky (and potentially dangerous) thing.  Its not the effort that matters, but rather the results.  So how do we measure the results?  Ahhh there’s the rub.

What we need to measure is the business value of the stories the team is being asked to build.  For the consultant this is very simple – you are paid by the hour for the consulting performed.  Thus, hours billed X hourly rate = business value.  The business value of a software going into a product is not so easily measured.  But, lets assume this is a solvable problem.  It gets even more interesting in the planning phase when you are making product choices.  For a proposed feature, what is the busniess value?  Now suddenly, this is not a software engineering question at all.

Last week, the Austin Agile development user group, AgileAustin, published a online poll of tools that teams in the local area favor for agile planning.  In response to the email announcing the poll, a couple of members emailed the list saying their favorite tool is no tool at all.  Some said index cards.  I shook my head a bit and emailed a good friend of mine who also leads development teams for his thoughts.  We came to the conclusion that it must be nice to work in a project so small you need no tools to help the team plan a sprint.

Actually, I don’t think it would be that nice.  I’d submit that if your plans are so simple that you need nothing to track them, or index cards suffice, you’re probably not doing much interesting.  For my team, Rally Software’s Rally Enterprise has been very successful in helping us plan very complex agile projects.  I recommend it without hesitation.

In many cases, our product management team enters user stories (sometimes we use epics for very large user stories) while the development, QA, and docs team breaks these down into stories and tasks.  We plan sprints as a fully integrated feature team across all these disciplines.  It’s not perfect, but it works and works well.

You can keep your index cards, thank you.

As you can tell by the frequency of my posts, things have been very busy at work – no complaints though, I know of friends and associates that would like to have such a problem. I wanted to follow up on one of the thoughts in the prior post regarding the global ramifications of effect of freely / very affordable cloud computing services.

With services like google app engine and amazon’s elastic compute cloud offering free and low cost resources that would have previously required investment of at least six zeros, the bar is substantially lowered to take a good idea to market.  To build out an idea, you now really just need a handful of expertise and time – not to mention a lot less time that you once did.

This opens competition up on a global scale never seen before – certainly there are many excellent and bright developers in India, China, Eastern Europe, Russia, Brazil, you get the picture.  The value increases for innovative ideas, domain knowledge, and the ability to market the solution.

I firmly believe America remains the cradle of innovation; it is in the very core of our society and our DNA.  I’ve had the privilege over my career to work with some of the best and brightest, and feel very blessed that I still do every day.  It is heartening to see the innovation coming out of Apple and my own company.  Still it is going to be a very different world when my daughters enter the workforce.   Change is coming and it is coming even faster than we can imagine.

Tomorrow, I have the opportunity to speak at an Rally customer success tour at the Renaissance.  Tonight, I am reflecting on the leaders I have a privilege to serve with on the panel, Israel Gat, Jack Yang, Torsten Weirch, and Eric Huddleson.  These gentlemen are all significant leaders in the Austin Community and I’m looking forward to tomorrow.

I’ve chosen the topic of “Agile in the Large” since the real power of Agile is evident when you turn loose the teams to run at their full speed in a self directed agile process.  Agile gets really interesting with development teams over 50, and also holds its most promise.  We believe that the best way to scale a team and continue to deliver successful software projects is to build it as a set of Agile teams.

Here’s few things we’ve learned along the way.  Interestingly enough, in comparing notes with the some of the development leaders at salesforce.com, it seems they have learned many of the same things.

• There’s no replacement for a great technical leader in the Agile team – effective team leads are priceless.  You should always be growing and recruiting for leaders.
• Great Product Owners are hard to find.  I have the pleasure to work with some of the best, but to scale the teams, you need more.
• An Agile team must be composed of all the skills they need to produce a shippable result.  In our case, it is the product owner or manager, usability, dev team, QA team, and tech writers.
• You run into problems when you depend on other parts of the organization that may not be Agile.  Just for an example, if you have a supporting organization that is still working on the Hero principle, or the waterfall process, there is going to be trouble.
• Tool support is critical and everyone must adopt. For large teams, roll up views and quick reporting is absolutely essential.  Rally gives us this capability.
• Test automation is absolutely key to keeping the product shippable.  As each sprint there is significant new functionality being delivered, the QA team must at the same time deliver automated tests so that doing regression testing onthe whole product is a swift process at the end of the release.  There’s just not time to regression test the whole product.

We have even been able to extend Agile to expose our feature teams to end clients through the Rally Agile tool.

Veteran’s Day was this week and I received an email from my Dad, the Colonel, that I wanted to share with everyone.  No, it has nothing to do with technology, but it has everything to do with being an American, and being grateful.  Things that I believe are in short supply these days.

“Each year on Vets day and/or Memorial day, I normally send out a greeting to my fellow veterans and loyal American friends.  For various reasons this year, I have not been in the mood and have not been very moved.  I cannot pinpoint precisely why.  I have not changed in my firm belief in this great nation and all that it stands for. Having personally spent over thirty years in support of and defense of a set of values, I am not likely to change my mindset.

What is finally getting through to me is that there are a measure if folk who claim citizenship to this nation that I dearly love who do not feel nearly as committed to it as do I.  Most of these citizens have never done anything in support of this country but rather have gone to great effort to verbally and by their actions demeaned and disgraced it.  While I have always been aware that such folk were there, I had them fixed on the fringe and that we loyal and patriotic citizens were in the mainstream.  By nature I have always been optimistic, yet for the first time, I now harbor some lingering doubts.

In awful places all over this earth good and patriotic servicemen and women stand in support of this wonderful nation, putting themselves in grave danger by their own choice.  This knowledge gives me reason for hope.  Yet, I see large segments of our population who either are ignorant of this concept of service or who chose to ignore any responsibility to defend our nation by word or deed.  When we reach a point where there are few willing to support our values but many who are willing to damn them, we fail to function as a nation and are reprehensible as a people.  As Vets, we must insure that we do all that we can to keep those who love our nation in the forefront.  We must teach well our children and grandchildren.

When the next catastrophic attack occurs, let us pray that another generation of warriors are out there like a sleeping tiger ready to come forward.  It is my belief that we will likely need those young warriors and very soon if our leadership wavers or shows weakness.  Amid the gloom, there is always cause for hope.  I wish all of my former comrades in arms a wonderful Vets day and hope that my remarks did not throw cold water on an other wise wonderful day.  I feel that we must remain very vigilant in the next few months/years to insure we do not loose our moral fabric and thus our way as a nation.”

Thank you Dad.  Thanks for the many times you risked your life for our country.  I am so proud of you.

We just returned from Smith Point Texas where we witnessed feats of ordinary heroism that warrant recording here.  Lets start with Fred, president of the volunteer fire department, and his wife Jennifer, who the next day after the storm return to Ike’s bullseye to assess the damage, and took pictures of everyone’s home and posted it on the web so that all the neighborhood could see the condition of their home.  And Fred, heeding the calls of a desperate voice far off in a quagmire of mud dredge up from the bay and deposited all over Smith’s Point by Ike, found and rescued a man who floated on a tank 11 miles from Port Bolivar.  Fred and Jennifer are a force at the Fire station every day, handing out meals to those returning to dig out.  Did I mention, Fred and Jennifer’s home is a total loss?

And Louis, tirelessly helping neighbors rework broken pipes so that they can get water flowing again in their homes.  And Ben, fixing, hauling, and building everything in sight, for anyone, even though he doesn’t have a home there.  And the countless trucks of linesmen from Virginia, North Carolina, and Michigan, who had new lines up and power flowing after a week back to the remote community of Smith Point.  And the stories go on, and on, of neighbor helping neighbor to dig out of 8 inches of mud in their homes, hauling out water heaters, washer, dryers out of yards, cutting up fallen trees, hauling away dead cattle, and searching for lost memories among the flotsam.

The American Red Cross has won everyone’s heart in Smith Point.  Their providing of meals, MREs (boy have these improved since I was a child in the Air Force), and clean water.  I am a donor for life at http://www.redcross.org.  In our little neighborhood, probably 1/3 of the houses are simply gone without a trace, boats are everywhere, the woods are full of homes demolished in Crystal Beach or Port Bolivar, no one escaped unscathed.

More than anything, the story of Smith Point is a story of a community drawn closer by tragedy and adversity.  A story of human determination and the quiet, resolve of Texans picking up the pieces, helping their neighbors and starting over.  It makes you proud to be an American.

Recently, we evaluated several Agile Project Management tools.  Having used XPlanner for years, it was time for a change.  XPlanner is great in some ways – fairly lightweight and easy to use for developers.  It really falls apart though when you start to consider multiple agile teams working together to deliver a release.  It is just really problematic to get a group view of where you are, what progress is being made by the team, and where the hot spots might be.  To accomplish this, you need to drill into the details of every scrum team and study the metrics / charts.  I even went so far as to change the source code to build a dashboard – that’s when we started to approach diminishing returns.

The other shortcoming of XPlanner is the management of the product backlog and release planning.  Yes, you can work around this, but intrinsically, the tool does not support building a backlog and then moving stories into a sprint.  Yes, this can be done, but it is arduous.  The interface also is stuck in Web 1.0 land, making data entry into a form submit after form submit affair.

So then what?  Surveying the market and talking to many of my longtime friends developing software with agile process, we quickly build the short list to replace XPlanner. We looked in detail at Rally, VersionOne, and FogBugz.  Though FogBugz had some very interesting capabilities around predicting the accuracy of estimates, it didn’t really seem to support agile planning methodologies and the scrum process.  Also, though the predictive capabilities are interesting, this really isn’t a huge benefit in my opinion if agile is really used and you know your people.

So, it was down to VersionOne vs Rally.   Both companies did extensive demos for our leadership team and key stakeholders.  Both tools intrinsically are built around the scrum agile process.  Both were priced around the same level with VersionOne being just a little less per seat, per month, but Rally matched and beat this price point in our negotiations.  The huge gaping hole in VersionOne for us was that it really didn’t assist with resource planning at all.  That is, they don’t enable you to enter the amount of available resources in terms of hours, days, etc, and then in the planning cycle show you where you are in using those hours as you take stories from the backlog and add them to the sprint.  Both tools track burndown during the sprint of course, but only Rally lets you know if you are planning too many stories in the sprint.  Even XPlanner supports this, so it is a big miss for VersionOne.  We can only assume they are working to add this capability.

Also, the rollup reporting for an entire release is more powerful and flexible in Rally.  This was a big plus for us.  To be sure, Rally isn’t super sophisticated in resource planning.  It doesn’t allow the individual team members enter their availability and then sum it up for the sprint.  (I would like this feature – I need to add this to the Rally Community.)  Rather, it just allows you to add the total number of hours available for a sprint at the beginning of the planning cycle.  How you figure this out is up to you.  After you add the total number of hours available, it shows you hours remaining as you add stories.

In coming blogs, we’ll talk more about the pros and cons of Rally as a Agile management tool.