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.

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.

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.

Oh, how I love this post by Joel on The Duct Tape Programmer!  This is such a salient point that applies to so much more than the context here.  “You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work.”

I just ordered my copy of  Coders At Work.

On a total Tangent, I just completed the transfer of my domain name off of Network Solutions to Dreamhost.  Dreamhost is awesome and dirt cheap.  They have one -click installs of just about everything you’d ever want to run on your website and their registrations are almost free they are so inexpensive.  I’ve been hosting with them for over a year and have had zero issues (other than imap email, but that’s another story).  I 100% recommend Dreamhost.

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.

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.

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.

The Third Sin of Software Projects is failing to understand its all about the people – attracting, retaining, and helping the best software development professionals available to succeed. The people on the project are the key determining factor of success. Let’s look at a few of the key factors in what we need in our people.

Productivity – you’ve probably read that top notch software developers are 2x – 5x more productive that the average developer. I’ve lived it and can attest. It’s not that the best will write 2 – 5 times as much code; it’s that they either can achieve the goal 2x – 5x more quickly, or just simply solve problems that others find unassailable. When I was early in my career I had the good fortune of working with just such a superstar: Brian. While I could hold my own in some of the most difficult projects, I could also see that Brian was simply a brilliant developer. He was simply world class, solving the most challenging issues and making it seem almost effortless. What if you could build a team mostly of this type of person? You could do anything! (FWIW: this also opened my eyes that I needed to focus my career on an area where I felt I could truly excel – leadership.)

Motivation – Software professionals are different than many other professionals in what motivates them. They are motivated by working with other smart people, working on challenging problems and cool technology, and by achieving a level of success personally and technically. (This last one is a complex subject as there are as many meanings of success as there are different types of people in software development). As leaders, we must understand that software professionals are motivated differently, and try to understand what success means to each person in our team.

Teams – In addition to having the most productive and motivated professionals, we need to be able to have them work effectively in a team. Dysfunctional personalities, poor attitudes, or weak contributors will torpedo a team very quickly. Any of these attributes in a team member negates all the positives above. Take a developer who is tremendously productive and knowledgeable, but just has a very negative attitude and they can drag everyone else down, kill cooperation and communication, and single handedly cause a project to fail. Conversely, a team that is made up of top-notch people that are motivated, focused, and check egos at the door can turn out the most innovative solutions imaginable.

Trust - finally, the key essential ingredient in the organization that makes it all work is trust. People within the team must trust each other to deliver, development must trust product mangers, teams must trust their leaders, and all the way through the organization. Very recently, I’ve heard about a situation where a new leader came into a development team and half the team left the company. It’s safe to say that more emphasis on building trust was needed! A subtle implication of trust is that integrity is required for trust to exist. The best companies I’ve worked with have a deep appreciation for all these ingredients, starting with the CEO. Those that don’t will fail.

In this business, we are all subject to schedule pressure which is essentially market pressure. This pressure is often real, coming from executive management, the board, or investors. Despite this, there are some necessary steps in the development process that can seem expedient to skip that in many cases, just shouldn’t be skipped:

• Prototyping the UI and getting feedback and buy in from Marketing and target customers. In the rush to get to market, we can easily skip this one. After all, once the design is done and the developers are implementing, its very expensive to change. Also, when working with new technologies, you don’t always know up front what is possible in the UI.
• Throw away the prototype. Its tempting to keep the hastily constructed prototype and evolve it into the final product. Especially when considering the need to prototype to explore UI options and technologies, this early deliverable is critical but also a mess under the covers. Learn from it and toss it.
• Internationalize the code and externalize strings up front. Its tempting to say “we can do that later”. Later is incredibly expensive. In our globalized world, most commercial software must be internationalized – design it in.
  Continue Reading »

Talking about requirements makes people’s eyes glaze over, so lets ask a more poignant question. What market are we trying to win? This focuses our vision in a much more effective way. The first deadly sin of software projects lies in not asking this question. Requirements management is a fundamental necessity in software development. Changing requirements causes obvious schedule impacts but has more subtle impacts in quality of the product and maintainability of the architecture. But, lets face it, few systems worth building have all their requirements known up front. There is always some element of discovery as the business matures, as early customers give feedback, as new deals are brought to the table.

The deadly mistake that can make your software project, and even the company, fail is a lack of focus on precisely how this product will win in the market. To answer this question, this presumes we can answer these questions of precisely which market are we in, who are our competitors, what are the major technology movements in the market, how will the product be marketed and sold, how should it be priced, and who will buy it. Even if you are the “technology” guy in charge of the software project, you need to know the answers to these questions because it affects in important ways the requirements of the system.   Most companies start out with a pretty firm grip on how they plan to win in the market. What trips them up time and again is not realizing the answers are changing. The deadly sin here is that if the answers to any one of the questions above change over time, they can dramatically affect your requirements and ultimately lead to the failure of your software project (and the company).  These changes can take place very quickly and very subtly in a small project. For example, selling a product into a new channel or to a new type of customer can quickly mushroom into a set of new requirements that can crush your existing commitments. To mitigate this, it is essential that the product management team and development leaders be integrated into the sales processes to gain visibility into these opportunities so they can anticipate new requirements as early as possible. This can be difficult as everyone is excited about the new customer or opportunity, and many times it becomes a “peeling the onion” exercise. At first, it seems that the new customer only needs a small change to the product, and then another, and then another. These changes are driven because they are fundamentally a different customer than has ever purchased before. Recognizing this difference is crucial.   

Another good example I’ve encountered many times is the difference between reseller and direct customers. Resellers are extremely valuable sales channels, but have very different requirements in products and billing than do direct customers. It is important to recognize and understand these differences up front. A reseller may want to embed your product in theirs or rebrand your service / web site. They often want to hide the visible aspects of your product because they want to present only their brand to the customer. These features must be factored in up front as they are very expensive to retrofit.

Finally, the new customer may not necessarily drive changes into your core product, but rather may require you to drive changes into your core processes. For example, a telco customer may have very long cycles between applying updates and may require different service levels that your other customers. Each of these have a cost component associated. The longer upgrade cycles may mean you have to keep alive older branches of source code alive for emergency patching, along with test environments that support that branch. These kinds of patches can be very expensive both to you and the customer. Also, you may have to go through longer or additional test cycles for the releases that go to these customers in an effort to avoid these costs.

In conclusion, asking “What market are we trying to win” means understanding the answer to the question and measuring each sales success against that answer. If the sale represents a fundamental change to this answer, then take the steps to deliberately plan for the product and process changes necessary to deliver on the opportunity.

In our examination of reasons why software projects fail, we start with a few basic assumptions. These seven deadly sins of software development assume that many of the fundamentals are in place: the team is staffed with trained experienced developers, you have a modern source code control system, build processes, test methodologies and automation, bug tracking system, project management systems, etc. In essence, we are assuming at least a CMM Level 2 team – without at least this level of process maturity, there are many other opportunities for the project to fail. This series of short articles focuses on the set of issues that sneak up on experienced software developers and development managers. They are seemingly common issues, but can surface in subtle and surprising ways while teams are heads down implementing a project. We’ll examine some examples along the way as well. Although we may have to change a few names, they will be real examples drawn from experience.

Its been a very busy forth quarter rounding out 2006. Business travel has taken me to South America twice, we’ve been working on closing a number of deals, and December saw the largest number of products all go GA ever in a month at Simdesk. All these are great reasons for not keeping up with the blog, but its time to get back to it.In 2007, I’m planning to write a series of articles on Software Development revolving around common sense knowledge every leader of a project should know. Though I place them in the realm of common sense, I’ve also seen them sink projects over and over again for those that are unaware (or just too busy to notice). Every series like this needs a catchy title, but I’m afraid we’re out of luck. We’re going to call this one “The 7 Deadly Sins of Software Projects”. If you’re in the business, I’ll wager you’ve either seen a few of these or maybe even been guilty yourself. Its easy to do because they can sneak up on you. Stay tuned.