The Next Book for Re-Read Saturday and It Takes a Team

An Agile team is comprised of a product owner, team members (from all the disciplines needed to deliver the project) and the scrum master. Delivering on the team’s commitment is the ultimate measure of value. The scrum master helps to create an environment for the team to work together. Over the life of a project, everyone on the team has to lead and facilitate for the team to effectively deliver value.

 

Systems Thinking: Find The Balance

Its all about finding the balance!

During the heart of winter, when the polar vortex swoops down with temperatures that even my dog finds uncomfortable, my wife and I assemble puzzles.  The act of assembling a puzzle is a simple example of the need to balance a system view with a more detailed perspective.  Getting work done efficiently and effectively requires both perspectives in some sort of balance.

The process we use for assembling a puzzle begins with opening the box, spilling the contents on a handy table and then propping up the lid so we can reference the big picture.  I once had a conversation in a hotel bar with a person who told me that he thought using the picture as a reference was cheating.  A little probing suggested that starting puzzles might have been more his actual goal than completing them, due to the time it took to discover the picture.  In our process, by contrast, I use completion of the puzzle as the goal and the picture on the cover of the box acts as the high-level requirements. However, as anyone that has ever assembled a puzzle will tell you, to achieve your goal you still need to fit all of those little pieces together.  Whether the puzzle you are working on has 100, 500 or 1000 pieces you will have to shift from focusing on the big picture to focusing on the details to find the right fit. The information from both perspectives is essential to fully understand what is required to get from the start of the system to the end of the system in an effective and efficient manner.

Reflecting back to my conversation about puzzles in the hotel bar, by eschewing the big picture, the systems thinking view, my neighbor might have been able to complete the puzzle, but not in the most efficient manner.  Meanwhile, a single-minded focus on the big picture, as pointed out in Gene Hughson’s comments to Systems Thinking: Difficulties can cause the equality serious problem of analysis paralysis. Spinning down into greater or greater levels of detailed analysis means a team is delaying its ability to deliver business value.  Gene was interviewed for the Software Process and Measurement Cast 268 providing great insights into Agile architecture, software development and management.

In the end, both perspectives are needed to get the job done. Finding the balance between the macro- (systems thinking) and micro-focus is a process in its own right.  The balance changes over the life of any project or even iteration. As a team shifts from conceptualizing to developing what is to be done they naturally shift from the big picture to the detailed view.  Product owners face a similar journey between the big picture and the detail, however they need to own the goal and the picture on the puzzle’s lid.  As a coach, the scrum master needs to make sure the whole team remembers the overall goal and big picture. Systems thinking helps us to understand that nothing happens in a vacuum.  Developing an understanding of how we transform inputs into value is critical. However in order to deliver that value, just having the big picture understanding is not sufficient. In order to actually execute, we need to have a handle on the detail also.

 

Agile Risk Management: The Need Still Exists

 

Hand Drawn Chart Saturday

I once asked the question, “Has the adoption of Agile techniques magically erased risk from software projects?” The obvious answer is no, however Agile has provided a framework and tools to reduce the overall level of performance variance. Even if we can reduce risk by damping the variance driven by complexity, the size of the work, process discipline and people, we still need to “ROAM” the remaining risks. ROAM is a model that helps teams identify risks. Applying the model, a team would review each risk and classify then as:

• Resolved, the risk has been answered and avoided or eliminated.
• Owned, someone has accepted the responsibility for doing something about the risk.
• Accepted, the risk has been understood and the team has agreed that nothing will be done about it.
• Mitigated, something has been done so that the probability or potential impact is reduced.

When we consider any risk we need to recognize the two attributes: impact and probability.  Impact is what will happen if the risk becomes something tangible. Impacts are typically monetized or stated as the amount of effort needed to correct the problem if it occurs. The size of the impact can vary depending on when the risk occurs. For example, if we suddenly decide that the system architecture will not scale to the level required during sprint 19, the cost in rework would be higher than if that fact were discovered in sprint 2. Probability is the likelihood a risk will become an issue. In a similar manner to impact, probability varies over time.

We defined risk as “any uncertain event that can have an impact on the success of a project.” Does using Agile change our need to recognize and mitigate risk?  No, but instead of a classic risk management plan and a risk log, a more Agile approach to risk management might be generating additional user stories. While Agile techniques reduce some forms of risk we still need to be vigilant. Adding risks to the project or program backlog will help ensure there is less chance of variability and surprises.

 

Kaizen and Urgency

Kaizen is a Japanese word meaning good change. Change in a dynamic business environment has become an accepted norm. Organizations must adapt or lose relevancy. The concept of kaizen has been adopted within the information technology industry as part of core management practices. In business terms, kaizen has been defined as continuous incremental change. You need energy to make change occur, in many cases, a sense of urgency is the mechanism used to generate the energy to drive continuous change.

John Kotter, author of Leading Change and the eight-step model of change, suggests that without a sense of urgency people don’t give the needed push of hard work to make change happen. Urgency begins by providing a focus that helps people to first become aware of the need for change and then pay attention to the need and the factors causing the need by piercing through the noise. (See the awareness, attention, action model). The energy a sense of urgency injects into the process is needed make the step from paying attention to taking to break through complacency and disrupt the status quo.

The need for urgency in the equation for change can lead to problems. The first is the potential for confusing importance with urgency. In a perfect world, we would only want to react to what is both important and urgent. The second problem area is that of manufactured/false urgency. Both problematic scenarios lead to the sapping of the organization’s energy in the long term, which makes it more difficult to recognize and react when real change is needed. If further there is an over reliance on a manufactured or a false sense of urgency the focus becomes short-term rather than strategic.

My first job out of university was as a statistical analyst/sales forecaster for a woman’s garment manufacturer. We had six “seasons” or product line offerings every year. Quotas were set for the sales force (incrementally bigger than last year). The sales management team for regional sales managers to the national sales manager provided constant “motivation” to the sales force. Motivation always included the dire consequences of missing the quota. There was always a sense of urgency, which drove action, including account prospecting (good behavior) and order padding (bad behavior). The manufactured urgency generated both good and bad change, and when things were going well it was pretty easy to sort those out. However, the business cycle has never been repealed and when an economic downturn occurred it was difficult to differentiate the real urgency. Therefore the organization did not make strategic changes quickly enough. A 80 year old firm with 750 million dollars in sales failed nearly overnight.

Urgency can become a narcotic that makes the need real change harder to recognize and harder to generate. Signs of an over reliance on urgency can include:

• People that are “too busy” to do the right thing,
• Generating highly crafted PowerPoint pitches for even small changes,
• Continually chasing a new silver bullet before the last has been evaluated.

The goal of kaizen is to continually improve the whole organization. The whole organization includes empowering everyone from development and operational personnel to all layers of management to recognize and make change. Motivation is needed to evoke good change, however we need to be careful that motivation does not translate to a need to generate a false sense of urgency.

 

Distributed Agile: Checklist of the Basics

Hydrogen is elementary!

Hand drawn chart Saturday.

In Scrum there are four-ish basic meetings. They are sprint planning, daily stand-up, demonstrations, retrospectives and backlog grooming (the “ish” part). Whether distributed or co-located, these meetings are critical to planning, communication and controlling how Agile is typically practiced. Getting them right is not optional, especially when the Agile team is distributed. While there specific techniques for each type of meeting (some people call them rituals) there a few basics that can be used as a checklist. They are:

• Schedule and invite participants. Team members are easy! Schedule all standard meetings for team members upfront for as many sprints as you are panning to have. As a team, decide on who will participate in the demo and make sure they are invited as early as possible.
• Review the goals and rules of the meeting upfront. Don’t assume that everyone knows the goal of the meeting and the ground rules for their participation.
• Publish an agenda. Agendas provide focus for any meeting. While an agenda for a daily stand-up might sound like overkill (and for long-term, stable teams it probably is), I either review the outline of the meeting or send the outline to all participants before the meeting starts.
• Check the tools and connections. Distributed teams will require tools and software packages; including audio conferencing, video conferencing, screen sharing and chat software. Ensure they are on, connected and that everyone has access BEFORE the meeting starts.
• Ensure active facilitation is available. All meetings are facilitated. Actively facilitated meetings are typically more focused, while un-facilitated meetings tend to be less focused and more ad-hoc. Active or passive facilitation is your choice. Distributed teams should almost choose facilitation. If using Scrum, part of role of the Scrum master is to act as a facilitator. The Scrum master guides the team and participants to ensure all of the meetings are effective and meet their goals.
• Hold a meeting retrospective. Spend a few moments after each meeting to validate the goals were met and what could be done better in the future.

Agile is not magic. All Agile teams use techniques that assume the team has a common goal to guide them and then use feedback generated through communication to stay on track. Distributed Agile teams need to pay more careful attention to the basics. The Scrum master should strive to make the tools and process needed for all of the meetings fade into the background; for the majority of the team the end must be more important than the process.

 

Community of Practice: A Meeting Checklist

Hand Drawn Checklist

Hand Drawn Chart Saturday

The simplest definition of a community of practice (COP) is people connecting, encouraging each other and sharing ideas and experiences. There are a few basic logistics that will affect the efficiency of a community of practice.  On the surface, logistics impact ease and comfort of a meeting but in a deeper sense, impact the ability for members to connect and share information. A basic logistics checklist would include meeting announcements, facilities, and agenda.

Community of practice meeting agenda:

 

Building A Backlog: Technique Synthesis

 

Putting the parts together!

Hand Drawn Chart Saturday

Techniques for building an initial backlog can be classified by how the conversation between stakeholders and the project team is initiated. Some techniques are focused on asking, other techniques focus on observing, while the third category is all about showing something and getting reactions. Most practitioners blend the best from each of the categories. Here are some examples of the hybrid techniques:

Role Playing Prototype: This technique blends paper prototypes (show) with role-playing (observe) to get users and stakeholders to consider how they might act in an environment that has not been fully designed.

Straw man/JAD: This synthesis seeds a JAD session (ask) with an loose outline of a solution or set of potential solutions that are used to guide the discussion which are at the core of JAD. However, the seeding tactic can inhibit creativity. The technique is less constraining when a set of competing solutions is used as the conversation seed, however developing the range of solutions before the JAD session  increases the cost of the JAD.

Embedding: This techniques puts team member(s) into a department to actually perform the work (observe) alongside actual users and stakeholders. This generally requires the embedded team member to be trained and mentored to intimately see how the work is done. I have seen debrief sessions added to this technique to ensure that participants get a chance to discuss the nuances in the workflow.   As I have noted before, with any observation technique everyone needs to understand what is going on and why. This is not an episode of Undercover Boss.

Combining tactics from different categories of techniques that teams use to develop an initial backlog can fundamentally change the dynamics of the requirements definition session. A group of stakeholders will generally have a diverse range of learning and interaction styles that they favor. Combining backlog building techniques gives the project team a better chance at making a connection. Combining techniques should not be done randomly or an ad-hoc basis. Selecting which techniques to combine has four prerequisites:

1. Someone with experience and training (perhaps a business analyst).
2. A knowledge of the user community (knowledge the product owner can provide).
3. Planning (time and effort).
4. Involved users and stakeholders (call on the product owner and project sponsor to help with this prerequisite).

Developing an initial backlog is a step to get projects going and moving in the right direction. It is, however, only a first step. Backlogs will evolve. Teams, product owners, users and other stakeholders will gain knowledge and experience as the project move forward that will continually shape and reshape the backlog.

 

Adding #NoEstimates to the Framework

#NoEstimates . . .Yes or No?

 

Hand Drawn Chart Saturday!

When I published An Estimation Framework Is Required In Complex Environments, several people that I respect, including Luis Gonçalves (interviewed on the SPaMCAST 282 with Ben Linders), begged to differ with my conclusion that a framework was ever required.  Luis made an impassioned plea for #NoEstimates.  The premise of #NoEstimates is that estimates enforce a plan and plans many times are overcome by changes that range across both technology and business needs.

Vasco Duarte, a leading proponent of #NoEstimate describes the process as follows:

1. Select the highest value piece of work the team needs to do.
2. Break that piece of work down into small components.  Vasco uses the term risk-neutral chunks, which means pieces of work that if they don’t get delivered in the first attempt will not put the project at risk.
3. Develop each piece of work according to the definition of done. #NoEstimates makes a strong case that unless done means anything other than usable by the end customers, the project is not getting the feedback needed to avoid negative surprises.
4. Iterate and refactor. Continue until the product or enhancement meets the organization’s definition of done.

Estimates are part of a continuum that begins with budgeting, continues to estimating and terminates at planning.   Organizations build strategic plans based on bringing new or enhanced products to market.  For example, a retailer might commit to opening x number of stores in the next year.  If public, once publicly stated, the organization will need to perform to those commitments or face a wide range of consequences.  Based on experience gathered by working in several retailer’s IT organizations, I know that even a single store is a major effort that includes store operations, purchasing, legal and IT.  Missing an opening date causes embarrassment and typically, large financial penalties (paying workers who aren’t working, rescheduling advertising and possible tax penalties not to mention the impact to stock prices).  Organizations need to budget and estimate at a strategic level.

Where the #NoEstimates approach makes sense is at the planning level.  The #NoEstimates process empowers teams (product owner, Scrum Master/coach and development personnel) to work on the highest value work first and to develop a predictable capacity to deliver work.  The results generated by the team provide feedback to evaluate the promises made though organization-level budgets and estimates.

When performance is at odds with what has been promised business choices should be made.  Choices can range from involving other teams (when this makes sense) to accepting the implications of not meeting the commitments made by the organization.

Does #NoEstimates make sense?  Yes, the process and concepts embodied by #NoEstimates fits solidly into a framework of budgeting, estimating and planning.   Without a framework to codify the use of #NoEstimates and to govern organizational behavior, getting to the point of making hard business choices will generate pressure to fall back to command and control fashion.

Note:  I am working on scheduling an interview and discussion with Luis and Vasco on the Software Process and Measurement Cast to discuss #NoEstimates.

 

Myths of Outsourcing: People as an Asset, Part 2

 

People Are Critical

 

Hand Drawn Chart Saturday

Part 2 (Part 1)

Myth: “Change does not need to directly address culture.”  Considering culture as a black box into which sourcing changes can be inserted and functionality returned is a falsehood that most everyone recognizes, but very few directly address.  Culture refers to the cumulative deposit of knowledge, experience, beliefs, values, attitudes, meanings, hierarchies, religion, notions of time, roles, spatial relations, concepts of the universe, and material objects by a group of people in the course of generations through individual and group striving.  Bottom line, people are what they learn.  Each change is a learning opportunity.

Myth:  “Our outsourcers staffing issues are not our problem.”  Why?  One of attractions to outsourcing is the belief that the outsourcer is a black box composed of processes performed by interchangeable cogs.  The reality is that staffing headaches are yours regardless of where they occur.  Turnover immediately reduces productivity as jobs are re-learned.  Even in a fixed price contract, personnel turnover can have effect.  The loss of productivity that the arrangement was based on could require the outsourcer to take a loss or trim work that could be viewed as overhead (like testing or reviews).  Quality can and does suffer.  Other longer-term issues include the possible transference of knowledge capital and job knowledge.  These issues are not new; they exist even in a non-outsourced scenario. Unless addressed contractually, however, you will not have input into the safeguards of required for your piece of mind.  Safeguards to protect your knowledge and job-level continuity are important.  If turnover is pervasive, simple safeguards provide little value.  Include a measure of turnover in the monitoring portion of all agreements.  Explore how your outsourcer intends to safeguard your knowledge capital, then make sure it happens. In the hotbeds of offshore outsourcing, the level of growth has been phenomenal.  Competition has created an environment where job switching is the norm.  I performed a quick survey (non-scientific) at a recent speaking engagement to test this hypothesis.  I asked those in the audience from mainline outsourcing firms to stand.  Then I asked how many had changed firms in the last five years.  The sample size was approximately 60 people.  Twelve people in the sample had not changed firms in the last five years; further, five had been in the business less than one year.  Anticipate the pressure on the goals of your contract from turnover.

Myth:  “After we decide on a sourcing model and trim our staff, internal turnover is a backburner issue.”   Turnover is a vexing problem for all areas of an organization but particularly with IT organizations where learning curves are steep.  Turnover can sap the strength of an organization by allowing critical knowledge to escape or act as a vehicle for change.  It can open slots for new ideas and technologies to be integrated into an organization as new people are added.  Internal turnover always continues after outsourcing work.  Retained employees will feel threatened (re-read communication myths) and will consider leaving.  Plan for continued turnover.  Focus retention efforts on those within the organization that are thought leaders in the areas that are critical for your well-being.  Use the slots of those who leave to bring fresh ideas into the mix and to bolster knowledge where you need it.  A skills and knowledge inventory is best practice used in the transition process.

The organizational impact of internal turnover caused by sourcing decisions is an unknown.  The literature is replete with claims and counter claims.  It is easy to believe the impact of change (sourcing merely being one type of change).  Active management of who stays and who goes is relatively easy when the organization is choosing.  In scenarios of attempting to influence a bottom tier to leave, the impact is less well understood.  While there are some organizations that have used the process to continually reinvigorate their skill pool, the control over their over the process is far from certain.  For example, an organization annually force-ranks all IT members, earmarking the bottom 20% to an active process of being managed out of the organization.  The emptied slots are refilled, and Darwinian competition begins anew.  In late 2003, the organization announced that in 2004 they would fill the emptied ranks offshore.  The 2005 forced ranking will therefore come from the 80% that made the cut in 2004.  Turnover immediately jumped, and, as is typical, the majority was from the top performers.  Interestingly, HR and senior IT leaders of this organization were surprised. Focus groups with line project managers expressed that result was as they had predicted.  All sourcing actions must be viewed in terms of entire organizational culture to be in least bit predictable.

Myth:  “Turnover is an issue only when we use offshore outsourcing.”  All sourcing models are subject to turnover and will have an impact on the level of turnover in retained personnel.  Offshore sourcing vendors have as high (or higher) turnover rates spurred by stiff competition.  Staff acquisition models suffer above-average turnover rates; people always react to change with change.  The use of COTS packages has the least impact on turnover unless you have built your shop on the premise that developers are at the top of the food chain.  Spend time anticipating how change will impact your turnover rates and focus on how you can ensure business and technical knowledge continuity.

Myth:  “Outsourcing work and staff helps avoid the responsibility to keep our staff trained.” Outsourcing options have long been used as a tool to mitigate organizations’ need to train (cost avoidance) or build potentially transitory skill sets.  When a need to address a specific method or technology is identified as urgent (where or when did planning occur), sourcing choices become an effective method for addressing the need.  Organizations providing sourcing options can very specifically identify the expertise they can bring to the table.  Most track training and expertise at a granular level as if they were code modules.  The goal is to bring the best solution to bear (and deliver it in the most efficient manner therefore driving up the profit margin).  The use of outsourcing as tool to avoid planning the migration of skills needed to support your IT needs is a strategic mistake and will lock you into using outsourcing models.  Being locked into any model puts you at risk that you will not be able to react to change.

Training is a significant component of most IT budgets.  The size of the line item in the IT budget is driven by many factors ranging from the rate of change in the software portfolio, the age of the technological platforms, the rate of internal turnover and corporate policies.  Shifting from an internal sourcing model to an external does not dissolve the need to be involved all together.  If you are using a model that is going to use a single or stable group of outsourcers, you must define your expectations and make sure they are followed by your outsourcer.  You may not directly bear the cost (or savings) or responsibility; however, if your outsourcer’s personnel gets stale, your solutions will become stale, the turnover will increase, potentially negatively impacting all of the reasons you originally had for the decision.

Myth: “IT workers must continually retool to avoid outsourcing.” This myth is both true and false at the same time.  It almost goes without saying that the fast pace of change in the IT world does not seem to be slowing.  Skills age and unless replaced the person holding them becomes less employable (this is true in almost all professions).  At an individual level, continued retooling will not cause anyone to avoid being outsourced.  The need to change sourcing options is a macro-level decision driven by globalization rather than any individual.

 

Teams and Overly Self-interested Behavior

Overly Self-interested Behavior Is Bad For Teams!

Hand Drawn Chart Saturday

Teams are an important concept in most IT organizations, regardless of their development philosophy. Philosophies like Agile may put more emphasis on teams, but even in organizations that do not embrace Agile philosophies, teams are important. Dan Ariely in his Ted Talk, “What Makes Us Feel Good About Our Work” suggested that overly self-interested, cynical behavior can negatively impact organizations by reducing their ability to communicate and innovate. The same problem can occur, albeit on a small scale, at the team level. In a recent presentation, a fellow Agile coach described a team engaged in overly self-interested behavior. He described a scenario in an organization that cuts the bottom 10% of all groups annually and stated vision that IT should maximize the value it deliverers to its customers. After losing a popular team member the previous year, the team had decided to make sure that his replacement was given the worst assignments in order to ensure he stayed on the low end of the performance scale in the coming year. Their goal was to ensure that the core team stayed intact during the next review cycle. In their mind, keeping the core team together ensured that they would deliver more value to their internal customers. The behavior of the team attempted to circumvent the idea that adding new and more highly qualified personnel would lead to improved performance. Viewed from the point of view of organizational policy, the whole team was acting in an overly self-interested behavior manner, but from the point of view of core team they are acting rationally and within their interpretation of the rules as seen through IT’s vision of value delivery. The team did not believe that their behavior was at odds with the behavior the organization wanted to incent.

What we perceive as overly self-interested at a team level is based on collective cognitive biases. Biases are powerful psychological filters that affect how both individuals and teams perceive the world around themselves and then guide how they behave. Biases reflect shortcuts in how we interpret and react to stimulus. In many cases, these reactions are valuable, however they can also cause problems (as many shortcuts occasionally can). Understanding how biases impact how individuals and teams perceive the world around them can help teams make better decisions and therefore deliver value more effectively. In the example, the core team had decided to protect itself by defining the new person as an outsider, which allowed them to hold them at arm’s length. In-group favoritism is a typical team level bias that causes teams to favor those inside the team’s boundaries over those perceived to be on the outside. This type of bias negatively affect how outsiders are perceived to perform. Negative perceptions of outsiders will effect whether we listen to their ideas and whether we trust them to deliver value.

Teams need to break overly self-interested patterns of behavior by striving ensure that they are pursuing a goal that is greater than team’s own self-interest. At a project level, product owners need to clearly identify and communicate the overall value proposition, so the team has something greater than themselves to pursue. When behavior goes off track coaching can help to identify issues that the team can’t see and diagnosis themselves. However, in many cases overly self-interested behavior at the team level can be a reflection of poor philosophies at the organization level. Organizational philosophies, like decimation or objectives that foster individual competition rarely support intergroup communication and innovation.