The Agile Executive

Making Agile Work

Posts Tagged ‘Ryan Martens

Harnessing Economies of Scale in Cloud Computing to Realize a Greener Computing Option

with 2 comments

Economies of Scale have been much discussed in The Agile Executive since the recent OpsCamp in Austin, TX. The significant savings on system administration costs  in very large data centers have been called out as a major advantage of Internet-scale Clouds. Unlike various short-lived advantages, the benefits to the Cloud operator, and to the Cloud user when the savings are passed on to him/her, are sustainable.

In this guest post, colleague and friend Annie Shum analyzes the various sources of waste in operations in traditional data centers. Like an Agilist with Lean inclinations who confronts an inefficient Waterfall process, Annie explains how economies of scale apply to the various kinds of waste that are prevalent in today’s small and medium data centers. Furthermore, she connects the dots that lead toward a Green IT option.

Here is Annie:

Harnessing Economies of Scale in Cloud Computing to Realize a Greener Computing Option

Scale Matters: “Over time, however, competitive advantage within categories shifts inexorably toward volume operations architecture.” – Geoffrey Moore, “Dealing with Darwin”

It is a truism that today’s datacenters are systemically inefficient. This is not intended as an indictment of all conventional datacenters. Nor does it imply that today’s datacenters cannot be made more efficient (incrementally) through right sizing and other initiatives, notably consolidation by deploying virtualization technologies and governance by enforcing energy conservation/recycling policies. There are a myriad of inefficiencies, however, that are prevalent in datacenters today.

Many industry observers lament the “staggering complexity” that permeates on-premises datacenters. Over time, most, if not all, enterprise IT datacenters have become amalgamations of disparate heterogeneous resources. Generally, they can be described as incohesive, perhaps even haphazard, accumulations. The datacenter components and configurations often reflect the intersections of organizational politics (LOB reporting structures leading to highly customized/organizational asset acquisitions and configurations), business needs of the moment (shifting corporate strategies and changing business imperatives to gain competitive edge or meet regulatory compliances) and technology limitations (commercial tools available in the marketplace). It should come as no surprise that human interactions and errors are considered a major contributor to the inefficiencies of datacenters: IBM reported that human errors account for seventy percent of the datacenter problems.

The challenge of maximizing energy efficiency begins fundamentally with the historical capital-intensive ownership model for computing assets to enable each organization to operate its own datacenter and to provide “24×7 availability” to its own users.  The enterprise IT staff has been required to support unpredictable future growth, accommodate situational demands and unscheduled but deadline-critical events, meet performance levels within SLAs and comply with regulatory and auditing requirements. Hence, datacenters generally are over-configured and over-provisioned. In addition to highly skewed under-utilization of distributed platform servers, ninety percent of corporate datacenters have excess cooling capacity. Worst of all, according to IBM, about seventy-two percent of cooling bypassed the computing equipment entirely. Further compounding these problems for a typical enterprise datacenter, is the lack of transparency and the inability to control energy consumption properly due to inadequate and often inaccurate instrumentation to quantify energy consumption and waste due to energy lost.

The economics of Cloud Computing can offer a compelling option for more efficient IT: by lowering power consumption for individual organizations and by improving the efficiency of a large number of discrete datacenters. Although the electricity consumption of Cloud Computing is projected to be one to two percent of today’s global electricity use, Cloud service providers can still cultivate sustainable Green I.T. effectively at lower costs by leveraging state-of-the-art super energy efficient massive datacenters, proximity to power generation thereby reducing transmission costs and, above all, harnessing enormous economies of scale. To better understand how Cloud Computing can offer greener computing in the Cloud and how will it help moderate power consumption by datacenters and rein in run-away costs, a good starting place is James Hamilton’s September 2008 study on Internet-Scale Service Efficiency” as summarized in the table below.

Resource Cost in

Medium DC

Cost in

Very Large DC

Ratio
Network $95 / Mbps / month $13 / Mbps / month 7.1x
Storage $2.20 / GB / month $0.40 / GB / month 5.7x
Administration ≈140 servers/admin >1000 servers/admin 7.1x

Table 1: Internet-Scale Service Efficiency [Source: James Hamilton]

This study concludes that hosted services by Cloud providers with super large datacenters (at least tens of thousands of servers) can achieve enormous economies of scale of five to seven times over smaller scale (thousands of servers) medium deployments.  The significant cost savings is driven primarily by scale. Other key factors include location (low cost real estate and electricity rate, abundant water supply and readily available fiber-optic connectivity), proximity to electricity and power generators, load diversity, and virtualization technologies.

Will this mark the beginning of the end for traditional on-premises datacenters? Can enterprise IT continue to justify new business cases for expanding today’s non-renewable energy powered datacenters? According to the McKinsey article, the costs to launch a large enterprise datacenter have risen sharply from $150M to over $500M over the past five years. The facility operating costs are also increasing at about twenty percent per year. How long will the status quo last for enterprise IT considering the recent trend of Cloud service providers? Major players such as Google, Microsoft as well as the U.S. government itself have invested in or are planning ultra energy-efficient mega-size datacenters (also known as “container hotels”) with massive commoditized containerization and proximity both to power source and less expensive power rates. Bottom line: will the tide turn if the economics (radical cost savings) due to enormous economies of scale become too significant to ignore?

Despite the potential for significant cost savings, it is premature to declare the demise of traditional IT or the end of enterprise datacenters. After all, the rationale for today’s enterprise IT extends well beyond simplistic bottom-line economics – at least for now. To most industry observers, enterprise datacenters are unlikely to disappear although the traditional roles of enterprise IT will be changing. A likely scenario may involve redistributing IT personnel from operating low-level system operational tasks to addressing higher-level functions involving governance, energy management, security and business processes. Such change not only would become more apparent but will likely be precipitated by the rise of hybrid Clouds and the growing interconnection linking SOA, BPM and social computing. Another likely scenario is the rise of the mega datacenters or “container hotels” for Cloud Utility Computing providers. Although the global economic outlook will undoubtedly play a key role in shaping the development plans/timelines of the mega datacenters, they are here to stay. Case in point: by 2012, Intel estimates that it will design and ship about a quarter of the server chips (it sells) to such mega-data centers.


Advertisements

Wrestling with Scaling Software Agility

with 2 comments

Software Development Times has just published Guest View: Wrestling with Scaling Software Agility by Ryan Martens and me. This Guest View is a little unique in that Ryan and I actually try to wrestle each other to the ground… Here is why we try to do so:

Agile champions spend a lot of time trying to communicate the agile premise to the executives in their organization. The difference in context between the champion and the executive often makes it a difficult conversation. A Scrum Master versed in behavior-driven design is not always able to relate to the frustrations of a sales executive who gets free advice on how to sell from everyone and his grandmother.

Conversely, a CFO does not necessarily understand why unit test coverage on the company’s legacy code is still inadequate after a full year of investment in agile methods that embrace refactoring as a core practice.

To bridge the chasm through this article, we resort to role-playing. Ryan Martens plays the Agile Champion; Israel Gat plays the Skeptical Executive. Metaphorically speaking, each one tries to wrestle the other to the ground.

Before you get into this Guest View, I would like to reinforce an important disclaimer:

A note of caution before Ryan and Israel make irreparable damage to their long-standing relationship: The two actually understand each other extremely well and rarely are they of different opinions on the fundamentals of agile in real life…

Enjoy the article!

The Success of the Success Tour

leave a comment »

We started the 2009 Rally Agile Success Tour (AST) Series in March in Denver, CO; we just concluded it in London, UK. In between the AST “train” stopped at:

All in all we hosted about 1,000 participants in these cities. More than 40 panelists shared Agile experiences with their local colleagues. Some 200 meetings were held with various participants in conjunction with the events. Obviously, I cannot write here about the level of business generated by the success tour, but none of my Rally colleagues complained so far…

The breadth and depth of topics that were covered is mind-boggling. Here are a few of the most intriguing ones:

The success tour proved successful to a degree that actually perplexed me for quite some time. I had certainly expected a strong series of events from the outset and could point out to various things we were doing right along the way. Yet, the very simple ‘secret sauce’ that made the event series so remarkable eluded me until I collected my thoughts for writing this post:

The Agile Success Tour proved phenomenally successful because the Rally team is so much like the customers and prospects that participate in the events, license the Rally software and work hand-in-hand with Rally coaches.

A few words of explanation for what might seem on the surface like a somewhat banal statement. The various members of the Rally team – sales reps, coaches, technical account managers, marketing professionals and execs – resonated with participants in the events due to exceptionally high level of congruence in values, thinking and practices. If Ryan were the CTO of eBay he would probably have licensed Rally software; Jean would have re-architected the flow of eBay processes; Zach would have integrated the ALM tools eBay uses. As for Lauren, she would have single-handedly created a world-wide marketing events organization for eBay.

The power of being like your own customers is magnetic. Digital Equipment Corporation was immensely successful selling minicomputers to engineers like their own engineers in the 60’s and 70’s. Sun Microsystems rode the early Internet wave as their product designers were carbon copy of the folks who roamed the World Wide Web. Apple triumphed with the iPod because just about every Apple employee would have murdered for such a cool device. Nothing beats the intuitive understanding that comes with designing, marketing and selling the kind of product you will buy, play with and use yourself.

After the Santa Clara event, Forrester’s Tom Grant told me the following about Rally:

What a smart company – everyone gets it!

Though a slightly different perspective than mine, Tom had actually identified the outcome of the company-customer congruence I am highlighting in this post. Everyone at Rally gets it due to natural identification with his/her customers. Contexts and experiences of customers are exceptionally well understood and often replicated in Rally’s Boulder, CO headquarters and its various branch offices.

Fundamentally, the success of the success tour reflects the affinity between Rally and its clientele.

More on the Social Contract

with 3 comments

The posts A Social Contract for Agile and Additions to the Social Contract established the dire need to reconstitute the social contract at a time when software development and test jobs migrate off-shore in an unprecedented manner. As stated in the first of these two posts:

My sense in 2005 was that the social contract between employers and employees in the software industry was broken. Without a working social contract, the friction and antagonism can bring a system down. For example, in 1942 – the turning-point year of WWII – 833,000 days of coal mining were lost due to strikes in the British coal industry.

Colleague and friend Ryan Martens has just published an article on the subject in Dr. Dobb’s. Ryan examines the Agile Social Contact in the context of what it really takes to get Agile rolling. To quote him:

Can you see the simplicity of Agile Adoption when you apply appropriate commitment and structure? A truly effective Agile Social Contract that creates true trust and commitment requires clarity and discipline. With the transparency of a clearly communicated Agile Social Contract, you will establish a strong leadership mechanism that aligns all the stakeholders and teams within your Agile adoption. Of course Enterprise-scale agile adoptions take place in a larger context of the business and market. As Israel Gat stated in his personal Agile Social Contract, we cannot guarantee lifetime employment in this globally competitive world. But, by making a clear commitment to win-win agreements, we can change the conversation into a motivating one versus a de-motivating one. Don’t try to scale Agile without a real and personal commitment or without a clear rollout structure.

The fascinating thing to me is that Rally’s own social contract seems to have developed completely on its own. Best I know there had never been a conscious attempt to develop a social contract. Yet, the company is well-known for the strong affinity of its employees.

I will leave it Ryan to comment on this riddle…

Written by israelgat

October 27, 2009 at 3:26 pm

10 Steps for Setting up an Agile Start-up

with 4 comments

Mapping the Agile thinking, theory and practices to the realities of the target company is a tricky part of making Agile happen in a sustainable manner. HubOne’s Nick Beaugeard, known to readers of this blog from his post Enterprise Product: $50,000 and 8 months – You Must be Kidding, shares with us his recipe for so doing in a start-up environment. He manages to weave the pragmatic details with the core principles behind software development in general and Agile methods in particular. For example, consider the following insight provided by Nick:

In fact, when developing an API, the unit tests are your clients!

Readers of this blog might want to compare and contrast the thoughts Nick expresses in this post with those of:

  1. Ryan Martens on prescriptive versus adaptive rollout of Agile (click here).
  2. Eric Ries on iterating on the problem definition and developing the customer base in parallel with iterating on the solution (Click here).

Here is Nick:

After my last post, where I discussed the concept of implementing the tools and process before you get people on board, I though it appropriate to provide some prescriptive guidance on how we achieved the process. This post is primarily aimed at start-ups where you have total control over your infrastructure, computers, network and internet connection. If there is enough interest, I’ll produce another post of how to perform the same, but in a corporate environment.

I believe, and my experience has shown, that preparing your work environment, tools and process before the team starts coding helps eliminate costly and lengthy discussions about tools and process. In fact, in my experience, most developers are pleasantly surprised to find the environment ready and working and slip into the processes extremely quickly.

So, please find below my ten steps. Following this process really helped us get up and running quickly. Whilst we used Microsoft Development tools, this equally applies to their open source equivalents, so feel free to substitute specific tools, just not the requirements and process.

  1. Authentication, Network and VPN. Setting up the core of your environment is critical. As you are more than likely working on secret software at the outset, you need good, auditable mechanisms for authentication and logon. In addition, we don’t want our developers to have to do anything except start their PC or laptop and login, and we really want them to be able to work remotely. If you don’t feel qualified or able to complete the steps below, any good local IT Pro should be able to set this all up for you. To perform this, we implemented the following:
    1. Network Connection – we are in Australia so our networks are not fantastic. We subscribed to a good ADSL 2+ plan (24Mb) with a 80Gb limit. We implemented a modern ADSLwireless modem/router and configured it correctly. This gave us acceptable internet connectivity.
    2. Domain – We implemented a domain controller running on Windows Server 2008. This gave us corporate authentication, auditing and identification. The domain controller was hosted on our private network (see 1.c)
    3. Routing and VPN –our internal development network needed to be protected from internet connectivity so we implemented a Windows Server 2008 machine with two network cards (called multihomed). One card was connected to the router and one connected to an Ethernet switch. We used a private IP subnetfor our development Local Area Network (LAN) and enabled Microsoft Routing and Remote Access. This gave us the ability to authenticate domain users to VPN into the private network for remote working. We then configured our router to allow access to the server for VPN Access.
    4. DNS –one of the issues you face with ADSL is that your Internet IP Address changes often. The solution for this was to use a solution from DYNDNS (www.dyndns.com) which allowed us to register a host name, coupled with a client application which ensured our host name for VPN always pointed at the correct IP Address.
    5. DHCP –it’s a real pain, especially when using VPN when your client machines are configured for static IP addresses. We used Microsoft Dynamic Host Configuration Protocol (DHCP) to ensure every machine had a unique IP Address and that our networking became just “plug-and-play”
  2. Version Control and issue tracking – in my experience, there are four critical systems needed for any software development team. These are:
    1. Version Control – Also known as source repositories, these systems allow control over check-in, check-out and versioning of source files. I cannot recall the number of times we backed out an individual source file to a previous “working version”. Without this in place, I can guarantee you’re going to struggle maintaining a good code base!
    2. Bill of Materials– the way I use these is to highlight each of the key deliverables in a project. When building Enterprise Profile Management, our BOM had 345 separate items, everything from the corporate website, to graphic design, to core components of the API. The Bill of materials is a way to track the overall progress of the project. Each item in the Bill of Materials should have at a minimum a title, description, owner, due date, % complete and %tested. We also use the bill of materials to determine our release criteria (more on this later).
    3. Build System – the biggest mistake a development manager can make is to not build the software regularly. We build our software system every time there is a new check-in (called continuous integration). Even with a very small team, the ripple effect of changes could go un-noticed for ages without building regularly. As an aside, we also have a Nabaztag (www.nabaztag.com) bunny which tells us whenever there is a build, whose check-in caused it and whether it succeeded or failed. While this is really annoying, it focuses the developers on good check-ins. We might also make the person who broke the builds buy us a round of beer, but that’s a secret!
    4. Issue Management – More important than email, IM, or indeed any other form of communication in the development team is issue management. I believe that in  a project of any size, you’ll be hard pressed to ever finish if you don’t have good issue management. Issues should contain a title, description, history, assignee, status and indicate which version/iteration of which product the issue applies to. I don’t actually think a spreadsheet will cut it here. If there’s one investment you make, make sure it’s issue management.
      We used Microsoft Visual Studio Team System for all of the above. Being an ex-microsoft product team member, I am familiar with the way the product works, but there are lots of plug-ins available for scrum, agile (MSF) and CMMI. To do this on a startup budget, we were able to join the Microsoft BizSpark program (http://www.bizspark.com) which gave us instant access to Microsoft’s developer tools. I’d highly recommend taking a look at that program!
  3. Backup – Now is the time to do a backup and recovery operation. You have no real data in the system and how you installed it all is probably fresh in your mind. Trust me, every first recovery operation fails. You need to imagine your office has been hit by lightning and you have no servers, and just a backup. If you can successfully recover your environment in under 24 hours, you’re in a good place. Document how to do it and test it regularly.
    When we were developing Enterprise Profile Management, our server with all issue management, reporting, builds and version control failed (the processor fried). We were taking backups, but the restore failed. It took me 22 hours to perform a forensic recovery of our production platform. Luckily the developers could work offline, but we still introduced a ton of integration bugs. Don’t skimp on backup.
  4. Email, IM and Web Conferencing – You’re going to be working remotely at some time, whether you think you will or not. We quickly implemented the following tools:
    1. Email – Google Gmail for your domain (www.google.com/apps)
    2. IM – Windows Live Messenger and Skype (www.live.com, http://www.skype.com)
    3. Web Conferencing – Dim Dim (www.dimdim.com)
      Note: there are lots of other tools out there, we just chose these (with little science, but they’ve worked well for us)
  5. Coding Standards – Getting at least some coding standards in place before you write any code is really important. Good Version Control Systems should be able to validate code against your standards on check-in. My key coding standards are:
    1. No String Literals – All strings must be externalised in resource files for later localization (a process called globalization)
    2. Commenting – I insist that every class, method, property, event and interface be commented. There’s method in my madness here; obviously code commenting is important but with proper commenting (especially in C#) and tools like sandcastle, you can automatically create documentation like ours at http://api.hubone.com.
    3. No Short Cuts – This one was a little contentious – Our code will in the future (hopefully) be worked on by people who had no idea of the concept. Writing out If…then constructs and property accessors in long-hand makes the code much more readable for novices, junior programmers, support teams and architects alike.
    4. Unit Test Everything –I insist that every method, property, event etc, etc has an associated unit test. These we execute as a part of the build. My goal is to have over 80% of any code written covered by unit tests. In fact, when developing an API, the unit tests are your client! Although this increases the programming effort up front, it actually reduces the total time taken to ship the product. I havelost count of how many times our massive unit test library has saved us from nasty regressions that we could never have found from UI testing.
  6. Write some code –Don’t worry, you don’t need to be the world’s best developer to write some code. All you need to do is think carefully about the different items in the Bill of Materials and start prototyping the methods, properties and events that will make it all work. Ensure you adhere to your coding standards. The goal of this exercise is to effectively build a skeleton of your application before the developers get on board. This can make them hyper productive when they start. They’ll probably end up getting rid of every line of your code, but it will get them in the rhythm of how you want the platform to look. As the architect of our platform, I used this period to prototype and test all of my assumptions of how things would work. By the time the developers got on board, I had a passable working prototype of an API with unit tests and coding standards, although there is almost none of my code in the final product, this enabled us to get running really quickly.
  7. Don’t write a test plan – Write the user documentation instead, and use this to test your application. That way you’ll know your application does everything the user guide says it does and you won’t double up on a test plan and the user guide (which should end up being pretty similar anyway). I wrote our user guide because I knew what I wanted the product to do and it’s also a fantastic way (sometimes they only way) you get to communicate with your customers.
  8. Give ownership, responsibility and praise – You will have no choice. As you get developers, testers, writers and others on board, you must give them ownership of components. I find that if I give someone total ownership, they always deliver. People are proud when they do great work and if they feel and really have ownership over something, it will be their best work. Not only that, but they’ll pull out every stop to impress you, the team and your customers. If you hire correctly, you’ve got great professionals in the team. Respect them as professionals and the results will be awesome.
  9. The best wire framing tools are not wire framing tools – You’re a start-up, right? Then you’ve discussed your ideas with potential customers and you deeply understand their needs. You could sit down with any number of wire framing tools and attempt to design components. How about you take a different approach? Write functional code which does what you (and therefore your customers want) – Developers find it far easier to code from a working model and they can re-use portions of your code. All of this streamlines the process and you can take your models to customers (with caveats on your poor coding skills and lack of stylistic ability).
  10. Constantly review and drive – We spend some time every day in front of a whiteboard discussing options, vision, checklists and almost everything else, but in a start-up, it’s not really a democracy. I run my start-ups like a benevolent dictatorship – I hold the final decision, but let everyone have input. I’m the one talking to customers, and sometimes I bring customers in to explain a requirement, but at the end of the day, how it works is up to me (I have the most to lose if it doesn’t work!)

Notice here, we never had a specification, requirements specification or design, we build the code a piece at a time and made it work. We’ve gone back and documented some core functionality, flowcharts and features, but at the outset, it’s more important to make it work. I’ll share a caveat, though, I’m also the software architect so I can hold the requirements for scalability, security and reliability, and guide the team to accomplish those goals.

Hiring the team can happen sometime between points 7 and 8, I don’t recommend you do it before!

If you’d like more information, please feel free to get in touch at nick@hubone.com, and if you’d like a copy of the software this built, we can be found at http://www.hubone.com.

Recommendations from Santa Clara

with 4 comments

So much was going on simultaneously in Rally’s Agile Success Tour event in Santa Clara! More than 140 participants, an eclectic panel, 6 breakout sessions, numerous 1-1’s and, of course, a ton of spontaneous interactions. This posts in many ways represents my own “thread” within this very gratifying event. My Rally colleagues will no doubt supplement this post by commenting on the various activities and interactions in which I was not able to engage.

The number one question I was asked in the course of the event was about the difficulties quite a few software development champions encounter in the course of attempting to coalesce successful Agile projects into comprehensive initiatives at the corporate level. Team successes with Agile sometimes remain isolated islands of excellence within corporate “oceans.” The proven  ability of a capable Agile champion to carry the day in specific project does not necessarily lead to adoption of Agile as part of an all-encompassing corporate doctrine. Just like the Geoffrey Moore entrepreneur who demonstrates success in the early days of his/her start-up but does not quite make it big time, the Agile champion often struggles to cross an adoption chasm and make his/her way to “main street.”

Colleagues Ryan Martens, Dave West and Tom Grant discussed how to apply Agile in combination with Lean to elevate Agile from the project level to the corporate level. There is no need to repeat their good work (click here for example) in this post. Instead, here are the tactical suggestions I gave in Santa Clara to various Agile champions who looked for recommendations how to elevate Agile:

  1. A statement of Agile benefits is not sufficient. It must go hand-in-hand with an assessment of the risks (plural!) associated with the Agile expansion. See A View from the Executive Suite for details of the recommended approach.
  2. Statements of Agile benefits and corresponding risk mitigation approaches are not sufficient. As Peter Drucker quipped, Companies make shoes! To be relevant at the strategic level, the Agile program must be tied into the top initiatives a corporation carries out.
  3. Statement of Agile benefits, risk mitigation and strategic relevance are not sufficient. These statements must be accompanied by a clearly articulated approach to managing the cultural aspects of extending and expanding Agile. If at all possible, opt for for building on the strength of the current culture. It is much more difficult to try to change a culture. Moreover, it take a long time to transform a culture. See my forthcoming presentation Four Principles, Four Cultures, One Mirror in Agile Roots for details.

I will allow myself to repeat my recent assessment from the NYC event as it applies so well to the Santa Clara event:

I came out of the Santa Clara event convinced that we as a movement have a great opportunity on our hands. What we -Agilists – do works quite well. The need clearly exists to elevate Agile to the enterprise level. We will be solving a real problem in so doing.

Written by israelgat

June 6, 2009 at 10:17 am

The March 18 Rally Event in Denver

with one comment

Please see here, here, and here for excellent coverage of the event by Ryan.

Written by israelgat

March 18, 2009 at 11:33 pm

Posted in Events

Tagged with ,