The Agile Executive

On January 30, 2012 12:00 pm EST, colleague and friend Hubert Smits and I will be doing a Cutter webinar entitled “Big Agile” is More than Just a Software Method.  We will follow on in February with a “Big Agile” issue of the Cutter IT Journal [CITJ] for which I am the guest editor. Coming April we are likely to discuss the topic some more in the Cutter Summit.

The heart of the webinar can be summarized in the following words:

Small is beautiful in software. While big software might not be beautiful, more often than not, it’s in the nature of what needs to be accomplished. This contrast between the beauty of small and the requirements of the big generates systemic tension in many software projects, organizations, and companies. Resolving this conflict is the focus of this webinar.

Discussing the webinar and the follow-on CITJ issue with various folks in the Agile, Lean and Kanban movement(s), I became painfully aware of the very many interpretation folks associate with the the term “Big Agile.” Hence, I would like to say a few words on what it means to me.  I am taking the very pragmatic view of a client on the subject. A VP of one department or another is chartered to implement an Agile roll-out at scale. The roll-out might not include all the teams. Nor might it include all functions within the company. The roll-out, however, affects a significant number of folks. Focusing the roll-out at the team level is not sufficient.

The typical VP that I run into under such circumstances is not an expert on software methods (and usually acknowledges it). He/she, however, is smart enough and experienced enough to understand that scale matters. He/she knows or feels intuitively that Big Agile is akin to Big Data. Data is data is data, but when it is Big Data you need to address various aspects that do not manifest themselves in dealing with ordinary amounts of data. Likewise for Agile IMHO.

We plan to make the webinar very interactive. Anne Mullaney will start with a few ‘warm up’ questions to enable us to ‘dig’ into the subject, thence turn it over to questions from the audience. We plan to take the discussion to wherever the participants might want to.

I hope you will join us whether you love, hate or indifferent to the term “Big Agile.” We are expecting a lively discussion…

I will have the distinct pleasure of leading a roundtable discussion on the subject in the forthcoming Cutter Summit. Here is the general direction we will jointly explore:

A technical debt assessment is often relegated to the “strictly for geeks” category. Supposedly, no sober executive wants to hear about metrics like Afferent Coupling or Distance from the Main Sequence, let alone learn and track them. Right? Wrong! In this round table discussion, Israel Gat will lead a discussion about the “life-view” that technical debt assessments reveal. Time and time again, we find technical debt readings reflect a broader truth than just the way software is produced. Here, we’ll discuss the measures that you could, and perhaps should, apply to tie process, code and outcome together to create a sustainable equilibrium between development, operations and the business.

I will be presenting on the Agile 2.0 subject in the forthcoming Cutter Summit. The premise of my presentation is that markets nowadays are vastly different from those we used to compete in ten years ago. The changes in the markets pose new challenges to software methods. Insofar as Agile methods are concerned, we are starting to see a new generation methods. I perceive these methods as Agile 2.0.

Here is the abstract of my presentation:

Agile, the software method that was conceived as a way to cope with change, is itself dramatically changing. What we are now witnessing is the emergence of Agile 2.0.

Three rapidly converging trends are driving the emergence of Agile 2.0:

• Markets are becoming hyper-segmented;
• Markets are also becoming fleetingly transient; and
• The value chains that serve the markets are dramatically different from yesterday’s value chains.

Traditionally, the Agile movement responded to change by “merging” two strands – development and testing – at the team level. Agile 2.0 extends this single-level approach by simultaneously applying Agile principles at three tiers:

1. The tier at which development, testing and operations merge
2. The tier at which strategy and delivery merge
3. The tier at which problem and solution merge

Agile 2.0 addresses the key challenge posed by “change is changing”: how to solve a problem when it is not understood well enough to produce a viable solution. Rapidly interlinked iterations at all three levels make it possible to substitute learning for planning. It’s through tight feedback loops in and amongst the three levels that the pace of learning accelerates to match the speed of change.

In this presentation, Cutter Fellow and Director of Cutter’s Agile practice, Israel Gat, will divulge the details you need to know about how to implement Agile 2.0 in your organization/company. You’ll get a blueprint for assessing and responding to the new realities of the competitive environment — without compromising the tried and true Agile tenets.

Many of the findings and the recommendations we make in Cutter technical debt engagements are broadly applicable in concept, if not in detail. There is commonality in the nature of the hot spots we typically find, the mal-practices we identify as the root causes and the ways we go about reducing the “heat.”  Granted, your technical debt reduction strategy might dictate investing in automated unit testing prior to reducing complexity, while your competitor might be able to address complexity without additional investment in unit testing. However, the considerations you and your competitor will go through in devising your technical debt reduction strategies are fairly similar.

It is this similarity that we try to capture in this Executive Update. Some of specifics we recount here might not be applicable to your environment. However, we trust the overall characterization we provide will give you, your colleagues and your superiors a fairly good “3D” picture of how the technical debt initiative will look like in the context of your own business imperatives and predicaments.

The good folks at Cutter have released the Executive Update from which the excerpt cited above is taken. It is co-authored by colleague Chris Sterling and me. For a free donwnload, click here and use the promotion code DELVING.

Readers of both the Cutter Blog and The Agile Executive are probably familiar with my my view that Agile nowadays is deployed in a new context. The Agile roll-out is at the very heart of the confluence of major changes in markets, value chains and technological capabilities. Markets are tilting toward hyper-segmentation; value chains are being populated with prosumers; and, technological capabilities are becoming a problem of choosing, not of choice. Hence, the real starting point for the Agile roll-out, indicated by the you are here marker in Figure 1, is comprehending the implications of the merging of these three trends in the context of the client’s business.

Figure 1: A New Context for Agile

DZone has just published an interview with me on the subject. Click here for details, including a discussion of the nature and power of ‘Super-Fresh’ Code in the new context.

The heart of the matter in this engagement was ensuring that technical debt stories would not become ‘second citizens.’ We proposed treating technical debt as a strategic investment theme. To our way of thinking, technical debt is no different from customary budget allocations to growing market segments, tactical sales opportunities, cost reduction and the like.

Click here for details in the Cutter blog including guidance how to work through the Data Structure of the Enterprise figure below.

Allocation Flows in the Data Structure of the Enterprise

Indeed, not only were their walls thicker, they actually seemed to have razor wire on top and armed guards with vicious dogs patrolling each side of the metaphorical wall. All in an era characterized by tremendous advances in social networking and collaboration.

Click here for details of my Cutter blog post on the subject. Until you have the opportunity to do so, the picture below will quickly gives you the gist of it…

Juggling on the Berlin Wall (source: Wikipedia)

In her recent post Getting Ready for Agile 2011, Anne Mullaney gave an outline of my forthcoming sessions at the conference. Specifically, she highlighted the emergence of new forms of Agility:

“Super-Fresh Code” is a term Israel coined (an extension of the “Super-Fresh Web” concept) to describe code that results from seizing upon the opportunities opened by combining recent advances in Agile software methods, cloud computing, mobile applications, and social networking. With the right mix, a company can outgun, outclass and outmaneuver its competition through real-time requirements management and superior business designs. Essentially, super-fresh code becomes the source of competitive advantage. This is a workshop that will make you think about Agile in ways you never have before.

Appropriately enough for the anniversary year of the Agile Manifesto, my strong conviction indeed is that we are just about witnessing Agile going beyond being “just” a software method. Markets are becoming hyper-segmented. There is no way to reach tiny, granular market segments economically without sophisticated software. Moreover, markets are becoming ultra-fluid. It takes a high degree of software-based business agility to penetrate market segments that form and collapse at the speed with which social networking groups emerge (and disappear). Hence, software is becoming a bigger and bigger part of just about any business — avionics, financial services, healthcare, retail, transportation, telco, and so on. In fact, in many engagements Cutter consultants carry out, the software is the company. Unless Agile methods are used strategically, the ability of a company to generate value for its customers and capture profit for itself might be in jeopardy: the company simply cannot adapt fast enough in the face of a significant amount of technical debt.

Viewed from this perspective, technical debt becomes an integral part of Agile methods. One starts an enterprise level Agile roll-out in order to, well, gain Agility. The accrual of technical debt puts a damper on Agility. Hence, implementing a technical debt assessment, reduction and prevention program is an essential part of the Agile initiative. In fact, Cutter recommends to its clients to integrate the two all the way down to the backlog stories.

I can’t wait to discuss these topics with you and other Agile 2011 participants in just about two weeks!

http://www.flickr.com/photos/holia/3204431590/

I have just stepped into the role of Director, Cutter’s Agile Product and Project Management Practice. It has been a long time since I felt so honored. Little had I expected that a friendly 2008 email from Brian Robertson suggesting I write an article for Cutter, and a later invite from Jim Highsmith to join the practice would lead to my heading it now.

My preliminary thoughts about evolving the practice are summarized in the Cutter press release. I view Agility as much more than a ‘mere’ software method. I envision the combination of Agile, Cloud, Mobile and Social as transformative in nature. Specifically:

It is not ‘just’ about doing one thing or another a little faster. Rather, it is about enabling new business designs that utilize the ultra-fast pace and flexibility of multiple links in the company’s value chain. [Excerpt from the Cutter press release].

An example of the transformation I foresee is given in my 2011 prediction:

The paramount need to deliver faster/earlier is, for all practical purposes, dictated by today’s markets becoming hyper-segmented. For example, my (or your) Twitter network today is an evolving market segment. My Twitter network in March 2011 could easily be a different segment than the segment it is today. The only way to penetrate such fluid market segments effectively is by following the classic Agile mantra “Release early and often.”

Viewed from such perspective, Agility is more than a strategic initiative. It actually becomes a philosophy of life in the best sense of the word:

The real challenge, however, lies in how to go about solving problems when you don’t understand them well enough to get to a viable solution … when you don’t have a clear enough understanding of the problem to create clear solutions, you have to iterate. [Interview with Russ Daniels]

I will be the first one to admit that I don’t fully understand various facets of what it will take to make the Agile practice most meaningful to current Cutter clients and highly enticing to future prospects. Just as Russ suggests above, I plan to iterate.

And this, in the final analysis, is all that matters in an Agile practice.

Source: http://www.flickr.com/photos/stevepj2009/3461077400/

Many of the devops posts in this blog were written from a dev perspective. Today’s guest post by Peter McGarahan examines the topic from the ops perspective. It is inspired by the following eloquent quip about change:

Assume we’re starting from scratch. Assume that we actually are a startup that doesn’t have over a hundred years of experience and sub-optimized IT legacy.

A few biographical details for readers who might not know Peter or know of him. Peter J. McGarahan is the founder and president of McGarahan & Associates, an IT Service Management consulting and training organization.  Peter offers 27 years of IT and Business Service Management experience in optimizing and aligning the service and support organizations of the Fortune 1000 to deliver value against business objectives. His thought leadership has influenced the maturity and image of the service and support industry. His passion for customer service led the Taco Bell support organization to achieve the Help Desk Institute Team Excellence Award in 1995. IT Support News named him one of the “Top 25 Professionals in the Service and Support Industry” in 1999.  Support professionals voted McGarahan “The Legend of the Year” in 2002 and again in 2004 at the Service Desk Professionals conference for his endless energy, mentoring and leadership coaching. As a practitioner, product manager and support industry analyst and expert, McGarahan has left his service signature on the support industry / community.

Here is Peter:

As a former Director of Infrastructure & Operations (I&O), I found it beneficial to establish a respectful working relationship with my Development Colleagues. It was important for the accountable leaders to better understand the objectives, workings and success metrics of each team. It was also critical for the leader to establish the ‘rules of engagement’ for how each team would assist each other in achieving their stated objectives (success metrics). It certainly helped to have an IT / Business leader who established a cooperative / collaborative teamwork culture. She also supported it with shared IT / Business objectives and performance goals for all accountable IT leaders. The I&O team certainly benefited from a CIO who understood the importance of customer service, the value of support and the business impact (negative IT perception) caused by repetitive incidents, problems and service disruptions. It was a game changing day for I&O when the CIO announced that all accountable leaders would have half of their performance objectives (bonus compensation) based on the success metrics of the I&O team.

In working with Infrastructure & Operations organizations, it has become apparent that as we continue to implement, measure and continuously improve the IT Infrastructure Library v3 (ITIL) processes, we must simultaneously address how we focus on all things new! In a recent Cutter Executive Update entitled IT’s Change Imperative, I relate lessons learned from my conversations with Geir Ramleth, CIO of Bechtel and Ron Griffin, Senior VP of Applications for Hewlett-Packard. Their leadership, vision and courage inspired me to think differently about how IT can better work together for the benefit of the business. In the end, the only success that matters – is the continued growth and profitability of the business. A summary of their change success stories:

• Hewlett-Packard CIO Randy Mott hired the right people to implement his IT strategy and change plan that included building, consolidating and automating its data centers; transferred work in-house from contractors; standardized on only a quarter of its apps; and built one central data warehouse — all while cutting spending in half.
• Geir Ramleth, CIO of Bechtel described how he used cloud computing principles to transform IT and make Bechtel’s computing environment more agile. He had a vision of allowing Bechtal’s global employees access to the right resources at any place at any time with any device – delivered securely and cost-effectively. He encouraged his IT people to step outside their comfort zones and do things in a different way. He resisted modifying the current state and went with the transformational change fearing they would only wind-up incrementally better. In targeting a desired end state, he gave his team guiding instructions to “Assume we’re starting from scratch. Assume that we actually are a startup that doesn’t have over a hundred years of experience and sub-optimized IT legacy.”

In the spirit of change, we should challenge ourselves to develop shared ‘devops’ goals / objectives. In the end, these should help us identify, link and realize how to translate IT objectives / metrics into tangible business benefits / value.

I have listed some shared ‘devops’ goals / objectives that I believe are a good starting point. I encourage and invite your thoughts, opinions and ideas around these and any others that you feel would aid ‘devops’ in working to establish measurable business value credibility.

1. Lower the total cost of ownership of all services (best way to achieve this is build them with serviceability, usability and maintainability in the design of all new applications, systems and services).
2. Increase business value – achieve business benefits (lower operational costs, increased revenues, improved customer experience)

• Simplified navigation
• Productivity enhancing capabilities /functionality
• Plug ‘n play integration
• Personalization
• Training / On-line Self-help features

3. Minimize business impact

• Reduce change-related outages / incidents.
• Reduce number of problems / incidents / calls.
• Reduce the number of requests / training-related calls / inquiries.
  • Provide insights and tracking to the number of Known errors / workarounds / knowledge articles (solutions).
• Speed to resolution based on business prioritization model
  • Operating Level Agreement / Commitment between Single Point of Contact (SPOC) Service Desk and internal IT Service Providers based on response / resolution times / commitments.
  • Bug-fix Process:

- Provide insights into the ‘bug/fix/enhancement’ list and process with transparent visibility to business prioritization (needs / requirements / quantifiable benefits).

4. Improved and frequent Communication

• A marketing / product launch / status update and awareness campaign.
  • Especially around rollout / enhancement time.