XP Explained Cover
This week the re-read of Kent Beck and Cynthia Andres’s Extreme Programing Explained, Second Edition (2005) tackles Chapters 22 and 23. Two more weeks until we shift gears and start reading The Five Dysfunctions of a Team (if you do not own a copy, it is time to order one – use the link to support the blog and podcast).  Back to XP Explained; Chapter 22 considers the implications of offshore development on the application of XP.  Distributed team members does not preclude using XP.  Chapter 23 waxes philosophically on the programming.  At its core, programming is a discussion of people and behavior more than technique and tools.

Chapter 22: Offshore Development
In the late 20th and early years of the 21st centuries, the software industry was still learning how to grapple with offshore development. Distributed teams became a popular idea.  Whether a team was partially in India, Belarus or Iowa has always been less of an issue than how power and decision making is distributed.  Beck makes the point that even the word ‘offshore’ is a loaded concept that implies an imbalance of power (Beck prefers the term “multisite”). Teams with imbalance of power and decision making will be less effective because parts of the team will be demoted to order takers rather than collaborators.  The values of XP (and therefore XP as an approach to development) are just as relevant in multisite development. When embracing XP in a multisite environment the values and principlesof XP provide a stable underpinning to tailor the core and ancillary practices of XP.

The practices of XP, as we have noted before, are merely tools to implement the values and principles of XP.  There is no perfect set of XP practices, but rather each organization needs to implement XP based on their own context.  Multisite development is just another context. As an example, Beck suggests that in a multisite environment planning might have to occur multiple times a week rather than once every sprint or iteration.

The goal of multisite development is to increase productivity.  There are numerous ways to state this goal, such as to get more with less or to improve the value of software delivery; however as we have explored in previous essays, all of these statements boil down to improved productivity.  One way to measure and provide evidence of improved productivity is to reduce team sizes while increasing throughput. The second goal of multisite development is to reduce waste in software development rather than trying to put up barriers that keep work in places with low productivity or high production costs. Everyone should consider the second goal as a clarion call for continuous improvement (process, people and technology) to protect competitiveness and jobs.
 
Side Note:  Even though XP Explained, Second Edition was published in 2005, the state of multisite development is still mixed.  I have worked as a consultant for many organizations that leverage multisite development.  Done well multisite site development often offers significant value, but many organizations approach the model poorly and therefore don’t get the value they expect.

Chapter 23: The Timeless Way of Programming
When I read this chapter I was struck by how different the two editions of XP Explained are when compared. The second edition far more philosophically in tune with the world of software development of the early 21st Century (i.e. now). Beck begins the chapter by using the analogy of the power differential between a structural architect and the person for whom he or she is designing the space.  The architect has the upper hand, unless a balance of between the parties can be established.  In the software development environment, the relationship between the business and development, in which the business describes both what they want and the how, when and cost of what will be delivered, is a reflection of a similar power imbalance.  A healthier relationship requires a balance between the business and technical view that maintains the integrity of the overall system.

The values, principles of XP promote the aim of a balanced relationship between the business and development. XP describes an environment in which the team includes technical and business personnel.  XP provides an environment in which developers can develop and excel technically so decisions about the business can be left to the business-oriented part of the team. As Beck puts it,”sharing power is pragmatic, not idealistic.” In the end XP is discussion of empowering people versus primarily being a discussion of tools and techniques.

Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 – 3

Week 3, Chapters 4 – 5

Week 4, Chapters 6 – 7  

Week 5, Chapters 8 – 9

Week 6, Chapters 10 – 11

Week 7, Chapters 12 – 13

Week 8, Chapters 14 – 15

Week 9, Chapters 16 – 17

Week 10, Chapters 18 – 19

Week 11, Chapters 20 – 21

Remember  we are going to read The Five Dysfunctions of a Team by Patrick Lencioni next.  This will be a new book for me; therefore an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks, we will begin to read the book together.

Transformation is possible if you really want it.

Transformation is possible if you really want it.

I am often asked which projects or organizations should use Agile. Underlying the question is a feeling that there is some formula that indicates specific types of projects or organizations should use Agile and which should not. I feel the answer is very simple. Since Agile is at heart a philosophy, any project or organization that wants to embrace Agile can use Agile. The most important word in that statement is “wants”. We often say we want something, but that statement doesn’t translate to action — for many reasons. For example, I “want” to learn Ruby. I have even gone as far to put a card into the backlog of my personal Kanban board. However, I have not found the time to begin the process. Finding the time would require I change my current behavior (get up earlier) or to abandon another project. Really wanting to become Agile means making changes both to how organizations and teams work and interact. As we all know, organizational change is typically not easy. The recent re-read of Kotter’s Leading Change recounted and discussed a framework for generating major organizational change. The requirements for all changes requires focus, effort and constancy of purpose. A change to embrace Agile requires adopting the philosophy of Agile, abandoning much of the trappings of command and control and thinking more in product terms of than project.

Agile is a Philosophy – the Agile Manifesto is comprised of four values and twelve principles that create a philosophy for structuring and managing work. The focus is on the human side of delivering value. There are innumerable frameworks, methods and techniques for implementing those techniques. For example, while Scrum is the most popular framework being used in Agile projects, it is not the only method. Crystal, DSDM and xP are a few of the other common frameworks. How any of these frameworks is implemented makes them more or less Agile.

Abandoning Command and Control – Effective Agile teams are self-organizing and self-managing. Self-managing teams plan and manage their day-to-day activities with little overt direction and supervision. Command and control management techniques, which hit their heyday in the 1950’s and 60’s and are still common, make the assumption that managers will assign and direct individuals (read that as tell them what to do). Command and control management strips much of the team’s ability to quickly make decisions and to react to change at a tactical level, which slows progress and reduces productivity.

Taking A Product Perspective – Agile embraces short iterative cycles of development that deliver value continuously or in the form of frequent releases. Techniques such as gathering needs into a backlog, involving product owners in planning and prioritizing needs over several sprints and releases are a reflection of product thinking. This type of thinking fosters trust between the business and IT so that the onus is not on the business to think of everything they need at once. Projects, as opposed to products, have a discernible beginning and end and have a known scope or budget, which forces users will to try to maximize the functions they ask for from the project team. The incentive is for the business to ask for everything and to make everything the top priority.

Who Can be Agile? Unfortunately any team or organization can say they are Agile. Any team can begin the day with a stand-up meeting or do a demo or retrospective. However just using a technique or framework does not make anyone Agile. Anyone can be Agile, however only if they want to be Agile enough to make changes in how they think and how they organize their work. Being Agile is only way to get all of the benefits in customer satisfaction, quality and productivity organizations are seeking when they say they “want” to be Agile.

dsc_0108

Several years ago, I hiked the Inca Trail in Peru. The trek included three plus days of hiking, climbing, crawling, sweating and an occasional exasperated utterance. Each day presented me with a new set of challenges and tasks to confront and to overcome. In some cases, failure was not an option with without endangering myself, fellow trekkers, guides or porters (or all of them at once). Each accomplishment brought its own value while moving us closer to the ultimate goal Machu Picchu. Metaphysically the process could be viewed as a form of ritual purification. The process presents the supplicant with a series of tasks and hurdles to overcome to bring him or her to a point where the larger goal can be grasped. The journey is an important part of reaching the ultimate goal. Taking the train to Machu Picchu would not deliver the same enlightenment as toiling for days to attain that goal. Both have a value and one or the other might not be an available option in every circumstance however under no circumstances should the value each delivers be confused with being the same. (more…)

Audio Version: Software Process and Measurement Cast 215

I was recently asked to be part of a debate that asked the question: “Is agile a philosophy or a set of techniques?”  In my opinion, there were a number of layers of meaning that could be extracted from the question.  Unfortunately the debate was canceled however I was able to talk through a number of the points that would have been raised with my learned opponent while jogging.  I would have won . . .

My interpretation of the question has evolved as I researched the question and reflected on organizations that have been successful in embracing and maintaining change.

Premise: Agile is a philosophy, not just a collection of techniques

Dictionary.Com defines philosophy as “a theory or attitude that acts as a guiding principle for behavior.”  Not a fan of Dictionary.Com?  One of the definitions supplied by Merriam-Webster.com is “a theory underlying or regarding a sphere of activity or thought.”  In simplest terms Agile, must be a philosophy because it fits the dictionary definition of the word.  The framework for what we today call agile is defined by the Agile Manifesto which was published in 2001.  The Manifesto is composed of a set of four value statements and twelve principles.  The values provide the rough outline of what provides worth or utility when developing software from which the principles provide guidance on how to achieve value and utility effectively.

A technique is defined by Dictionary.com as “the body of specialized procedures and methods used in any specific field, especially in an area of applied science.”  Pair programming, planning poker and stand-up meetings are procedures and methods.  While techniques direct specific activities, techniques in their own right do not provide the guidance needed to know how and why to apply any individual technique or when experimentation or adjustment might be needed to address context.

The twelve principles that are part of the Agile Manifesto (while not as famous as the sound byte sized value statements) are critical to making agile a philosophy.  I suggest a quick review of the twelve principles (link to the Agile Manifesto) if you think they are not oriented to influencing behavior.  On my part, I would be hard pressed to identify any of the twelve principles that did not seek to guide the behavior of those who want to be agile.  I believe that the principles, while written for people that develop, enhance and maintain software, can provide behavioral guidance to any other kind of team based work since agile represents a people based philosophy and most, if not all, work is people oriented. Therefore, if we accept that the twelve principles included as part of the core of the agile manifesto act as guidance for behavior, Agile therefore must be a philosophy.

Shocked?  To my friends that use other frameworks such as the CMMI, I would suggest that all frameworks are by their nature a form of guidance and therefore a philosophy whether we recognize that fact implicitly or explicitly.  As an example, each of the process areas in the CMMI are underpinned by one or more goals which guide how people are to behave when addressing that process area.  The CMMI, therefore, must also represent the codification of a philosophy.

Before we determine whether the correct question is being asked, should we be worried that Agile is a philosophy? I would like to suggest that common development philosophies like Agile and the CMMI (if embraced) are a reflection of a philosophy called Thomism.  Thomism, the philosophy of Thomas Aquinas, holds that all intellectual knowledge comes through the senses (as opposed to philosophies driven by the meta-physical).  The scientific method instructs scientists and engineers to derive and test hypotheses from observations (substitute the word data if you like). In my opinion the scientific method leverages the same or a similar philosophical basis as Thomism.  Should we worry that agile at its core represents the same philosophy as the scientific method?  Perhaps we should be worried if it weren’t.

Is Agile a philosophy?  Of course it is; however, I would like to suggest that the unasked question hidden in the premise is whether an organization will get more benefit from Agile (or the CMMI for that matter) if the organization adopts the agile philosophy not just the techniques.  While the answer is yes, I think we would have far less unanimity in the community on that account and in two weeks we will explore the answer!

Project and Process Improvement Ethics:  A Primer
Part 1: What are ethics and why do care?

 I recently overheard an offhanded comment that went something like, “if you aren’t cheating, you are not trying hard enough.”  This was after watching a handball in the goal at the recent World Cup soccer tournament and then having a soccer coach suggest that kids are taught that technique to defend against a sure goal through the use of a handball.  These are issues of ethics.  What are ethics?  What is the purpose of ethical frameworks?  Why should they matter to those who manage process improvement? 

 The definition of ethics founds in Wikipedia[1] states that ethics is a branch of philosophy that addresses questions about morality—that is, concepts such as good vs. bad, noble vs. ignoble, right vs. wrong, and matters of justice, love, peace, and virtue.  Hardly the stuff of project management or process improvement, however there is a branch of ethics called applied ethics (doesn’t that sound much more practical) that seeks to address our daily business lives.  Applied ethics seeks to identify the morally correct course of action in various fields of human life; business ethics are a form of applied ethics.

 Interest in ethics waxes and wanes over time, they tend to wax when things go awry.  Obvious examples abound such as Enron when things went up in flames ethics became a hot topic, at MCI during their accounting debacle and even during the BP Oil well crisis but there are less obvious examples such as the spin to under play a risk in a status report or when someone occasionally conflates effort and progress when a project is behind.  Each of these examples is a matter of ethics and unless a framework or code is in place to highlight these transgressions, large or small, and so they are noticed and discussed nothing can be changed.

 What purposes do ethical frameworks (groups of ethics that have been consolidated into laws, codes of conduct, and codes of ethics) serve?  I would suggest that most ethical frameworks serve two common purposes.

 The first purpose is to guide behavior so that it is predictable.  Codes provide a path to guide both the organizations actions and the individuals within the organization actions (to an extent they can be different).  Codes of ethics, codes of conduct and the effort to enforce them help to identify deviant behavior before it can injure the organization.

 The second purpose of codes of ethics is as announcement to the larger world the set of higher order rules an organization intends to follow.  Codes of ethics gengerally reflect the rules and norms of the larger external society the organization interacts with. 

 Why should ethics matter to those who manage process improvement?  I suggest that ethics evolve to guide behavior and provide all affected parties with an understanding of how people (and people proxies) should act.  Rules, laws and manifestos (statements of principles and ethics) are how ethics are applied in the real. The rule, “Thou shall not install un-unit tested code” creates a set of expected behaviors and a set of obligations on all parties.  Living up to the rule is a matter of ethics.  The translation of ethics into codes of conduct, rules, laws or other codes provide a line in the sand so that you can judge whether an action is ethical or not.  The more black and white the ethics rule is the easier it is to follow in real time.

 Most corporate codes of conduct or ethics (a set of rules that describe the behavioral expectations of employees) do not address some of the more specific issues with which a project manager of a process improvement projects will need to wrestle.  What can be done? 

 I have recently begun each of my process improvement projects by establishing a process improvement manifesto.  The exercise has many benefits; however the primary goal is to help empower the team to make the decisions without having to get permission.  The manifesto acts a basis to form very specific code of ethics to shorten the decision making loop which will improve efficiency for normal IT projects and process improvement projects.

 Part 2 – Suggestions for a Process Improvement Project Manifesto


[1] http://en.wikipedia.org/wiki/Ethics

Why Should You Care What Is Driving Change?
Thomas M. Cagley Jr.

What are the pressures driving process change in your organization?  I ask the question because I believe that people, teams or even whole organizations don’t wake up in the morning with the idea that they need to change.  There has to be a trigger, a reason that helps provide the motivation. That reason will create pressure that change will relieve.   

 

Process improvement champions must understand why change is being pursued or risk failing.  Knowledge of the rationale behind change and the urgency of that rationale is an important component to actually making change happen.   There are numerous reason why knowing the “why” of change is important.  One reason is that knowing “why” will help you select the proper solution for the proper problem. A good think right?  A second reason and the focus of this paper is that knowing “why” allows you to communicate the rationale to those affected.  Communication is one of the core tools for reducing resistance and promoting buy-in.  

 

Communication is important because left to their own devices every person impacted by a change will develop their own opinion as to why the change is occurring.  Those opinions will range from the rational (change will help us become more efficient or change will help us increase market share) to the scary (change is a precursor to outsourcing, change is a precursor to downsizing).    The hopes, fears and paranoia’s of each individual affected will be represented when the rationale for change is left to assumption.  Opinions influence the level of effort and commitment applied toward the change (the negative side is resistance).  Communication and actions are required as a part of a coordinated organizational change management plan. 

 

Organizational change management, communication and their kissing cousins marketing and sales tend to be tough subjects for most IT project managers.   Perhaps this is because they are discussions of emotions rather than deterministic tasks.  A good dose of sales training or training in how counsel teams ought to be required as part of every project manager’s CV. 

 

In change programs of any size, communication will range from mentoring, cheerleading through persuasion (perhaps in the same conversation).   Knowing why any specific change is needed and how important that change is will allow you to engage with your customers in the most reasonable and honest manner possible.

 

As a leader of change, you are responsible to know why the change you are pursuing is needed.  If you do not know, find out.  If you can’t find out, think about saying no until you find out. Bottom line, effective change requires effective communication and if you do not know the rationale for the change you are pursuing you will not be effective. 

 

 

 

 

 

Life is an epic adventure even when it seemingly is a series of unrelated events.  So while I wax a bit philosophical, I suggest that this thread of thought is important to process improvement personnel.  Important because when process improvement and measurement personnel view life as an adventure I believe they will be far less likely to view the day to day grind with a victim mentality.  I classify an outlook as a “victim mentality” as a point of view that classifies outcomes as outside of your control.  Therefore in other words “stuff happens” is a mantra.  This point of view is very easy to fall into when you are trying to influence people and organizations without direct authority.  To combat this deadly (from a professional point of view) I would suggest that process improvement and measurement personnel need to embrace life, need to look for the possibilities in all situations, and seek opportunities to increase the impact they can have on their organizations as well as their personnel knowledge base.

Not a new revelation but sitting in the Malaysian Airlines lounge in Kuala Lumpur reviewing events past, present and future left me with the message that we all must grasp each new experience as set of new possibilities.  New possibilities to deliver value and possibilities to increase our personal knowledge base.  We are challenged to look for ways to make every experience work for our self and for those around us.  We must leave the world around us in a better position than when we originally touched it.