Posts Tagged ‘Andrew Shafer’
A Special Technical Debt Offer from the Cutter Consortium
The good folks at Cutter are making the October Issue of the Cutter IT Journal (CITJ) available to anyone who is interested in getting deeper into the intricacies of technical debt. Here is the table of contents for this issue:
- Opening Statement by Israel Gat
- Modernizing the DeLorean System: Comparing Actual and Predicted Results of a Technical Debt Reduction Project by John Heintz
- The Economics of Technical Debt by Stephen Chin, Erik Huddleston, Walter Bodwell, and Israel Gat
- Technical Debt: Challenging the Metaphor by David Rooney
- Manage Project Portfolios More Effectively by Including Software Debt in the Decision Process by Brent Barton and Chris Sterling
- The Risks of Acceptance Test Debt by Ken Pugh
- Transformation Patterns for Curing the Human Causes of Technical Debt by Jonathon Michael Golden
- Infrastructure Debt: Revisiting the Foundation by Andrew Clay Shafer
Being the guest editor for this issue, I can attest better than anyone else how much I learned from the various authors, from Karen Pasley (the October issue editor) and Chris Generali (CITJ Editor-in-Chief).
Click here for details of this special offer including downloading instruction.
Changing Culture to Enable Devops
InfoQ has posted the video recording of the panel on Cultural Change in Devops from DevOps Day US 2010. Under the skillful moderation of Andrew Shafer, panelists John Allpsaw, Lee Thompson, Lloyd Taylor and I shed light on the fascinating cultural dynamics that devops teams go through. The four of us and Andrew are not necessarily in complete agreement on every point, but we all emphasize one key lesson:
Defining learning and readiness in technical terms is inadequate in the devops context.
Click here for the recording of the panel on Changing Culture to Enable Devops.
Boundary Objects in DevOps
Source: Flickr; Chrice‘s Photostream
The following recommendation was given in the post How to Initiate a Devops Project:
For a DevOps project, start by establishing the technical debt of the software to be released to operations. By so doing you build the foundations for collaboration between development and operations through shared data. In the devops context, the technical debt data form the basis for the creation and grooming of a unified backlog which includes various user stories from operations.
I would like to augment this recommendation with a suggestion with respect to the mindset during the initiation phase. Chances are the IT folks feel outnumbered by the dev folks. It might or might not be a matter of optics, but recognizing and appreciating this mindset is will help a lot in getting the devops project on track.
Here is a simple example I heard from a participant in the June 25 devops day in Mountain View, CA. The participant with whom I talked is an IT ops person who tries to get ops aligned with fairly proficient Agile development teams. She is, however, constrained with respect to the IT ops resources available to her. She simply does not have the resources required to attend each and every Scrum meeting as 25 such meetings take place every day. She strongly feels “outnumbered.”
Various schemes could be devised to enable meaningful participation of ops in the Agile process. The more important thing though is to be fully sensitized to the “outnumbered” feeling. The extension of Agile principles to ops will not succeed at the face of such a feeling.
Discussing the subject with my friend Andrew Shafer, he mentioned the effectiveness of boundary objects in such cross-organizational situations:
Boundary objects are objects which are both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites. They are weakly structured in common use, and become strongly structured in individual-site use. They may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable means of translation. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds. [Source: Wikipedia].
As an example, the boundary object for the situation described in this post could be a set of technical debt criteria that make the code eligible for deployment from a product life cycle perspective. By so doing, it shifts the dialog from the process to the outcome of the process. Instead of working on generating IT resources in an “outnumbered” mode, the energy shifts toward developing a working agreement on the intrinsic quality of the code to be deployed.
Some technical debt criteria that could form the core of a devops boundary object are mentioned in the post Technical Debt Meets Continuous Deployment. Corresponding criteria could be used in the boundary object to satisfy operational requirements which are critical to the proper functioning of the code. For example, a ceiling on configuration drift in IT could be established to ensure an adequate operating environment for the code. A boundary object that contains both technical debt criteria and configuration drift criteria satisfies different concerns – those of dev and those of ops – simultaneously.
Agile Infrastructure
Ten years ago I probably would not have seen any connection between global warming and server design. Today, power considerations prevail in the packaging of servers, particularly those slated for use in large and very large data centers. The dots have been connected to characterize servers in terms of their eco foot print.
In his Agile Austin presentation a couple of days ago, Cote delivered a strong case for connecting the dots of Agile software development with those of Cloud Computing. Software development and IT operations become largely inseparable in cloud environments. In many of these environments, customer feedback is given “real time” and needs to be responded to in an ultra fast manner. Companies that develop fast closed-loop feedback and response systems are likely to have a major competitive advantage. They can make development and investment decisions based on actual user analytics, feature analytics and aggregate analytics instead of speculating what might prove valuable.
While the connection between Agile and Cloud might not be broadly recognized yet, the subject IMHO is of paramount importance. In recognition of this importance, Michael Cote, John Allspaw, Andrew Shafer and I plan to dig into it in a podcast next week. Stay tuned…
The Agile Infrastructure cultural change problem – Agile Executive #06
To listen to this podcast, download the podcast directly, subscribe to the blog/podcast feed in iTunes (or whatever), or click play below to hear it:
As part two in our (planned to be) three part or so series, Israel Gat, Andrew Shafer, and I get back together to discuss the idea of Agile Infrastructure. See part one for an overview of what “Agile Infrustructure” aims to be in the first place.This time, we talk about the difficulty of cultural change to make a more Agile IT process possible. We spend much time on “motherhood and apple-pie” topics as always happens when it comes to discussions of organizational change management, but drawing on our experiences in both small and very large companies, we start to pull apart the tactics for not only implementing a change to Agile IT, but coping with the friction that occurs during any change, esp. something as dramatic as changing to a more Agile way of delivering software and business services.
Here’s a feel for what’s in the episode:
- I start out by asking how organizations start the process of changing to more Agile IT operations.
- Andrew says that change starting at a grass roots level, bottom-up, and is far from wide-spread.
- Israel speaks to one anecdote with 20% from the top and 80% from the bottom.
- What’s the process for change? What’s the context for trying to get people to change?
- Andrew says that people have to care – they must be interested in doing more than passing the time and getting paid for it, as I put it. Ideally, champions can start to “manage upwards” too, as needed. Also, having an expert on Agile available for internal assistance and answering questions is key.
- Israel adds in his “Agile Executive” view. He speaks to using people’s desire to do better, but figuring out a window (or time and environment) in which it’ll succeed.
- Using small successes to build the room to do large successes.
- This discussion leads Andrew to remember a talk by Lisa Crispin where the testers and others began to understand the “business,” or the larger context they were operating in.
- I ask Andrew and Israel why it’s important for IT employees to rise above being someone who “just works here.”
- We then discuss how changing to the more role-fluid nature of Agile conflicts with the static nature of jobs in organizations, where people are assigned a specific role and aren’t expected to go outside that role.
- When it comes to knowing how well you’re doing, Andrew introduces the Dunning-Kruger effect, wherein people are bad at evaluating themselves, esp. when their context is limited to their own group or organization.
- Reflect and adapt… making sure you do this in Agile. Israel connects this back to building confidence and moral in the organization as a way to enable change and Agile. This relates to one of those group psychology studies that’s always fascinating, namely, people preferring confidence over expertise.
Live Recording of Four Principles, Four Cultures, One Mirror
The live recording of my Agile Roots keynote presentation is available here. In addition to threading the slides together, the recording captures the Q&A session that followed. Various questions and observations were brought up by Diana Larsen, Jeff Patton, Andrew Shafer as well as other participants in the conference. In particular, linkages were made during the Q&A session to Appreciative Inquiry and to Serious Games.
Needless to say, comments on the presentation will be much appreciated.
The Agile Executive 