Discipline and GNGB Introduction Part 2

Plan Based, Agile or Just Doing ‘Stuff’:

There seems to be confusion in the some corners of the software development world. Those afflicted with ‘the confusion’ have concluded that plan based methods can be replaced with random activity, ‘winging it’. Winging it can not the means to address problems in the real world. Discipline is required to consistently address real problems. Real problems means someone is watching. Discipline requires saying what you will do then being able to execute (whether promising to pick up the kids or finger paint the Mona Lisa). The how is a discussion point whether you use plan based methods or function based methods is a market choice not a discipline choice.

Good Numbers Go Bad – Introduction Part 2

The impact of measures and metrics is dependent on how closely they are linked to business goals and organizational strategy. The closer the linkage between business goals and measures and metrics the higher the probability that value will be derived. Metrics that are specifically tailored to address the organizations business context must not only deliver information as well as add value (information does not equal value). For example, if the business’s goal is to reduce cost, the metrics must measure the reduction of cost of production and the attributes that drive cost. Measuring other areas might be more appealing intellectually (for example quality and productivity) however they will not produce the value that is sought. Identifying and ensuring proper linkage helps ensure the value of measurement thought support of the ultimate business goals

Realistically business goals are typically not as cut and dry as reducing cost. Goals of market leaders (or aggressive newcomers) are typically targeted on towards expanding opportunities (creating disruptive innovation) and/or sales (expansion). Linking metrics to these types of goals can be addressed a two levels. The first is a macro view, measuring output (innovations or sales) and at a micro level, measuring the critical steps that lead to innovation or sales. If you are going to use the micro level strategy, focus only on measuring the most (most critical = small number) critical steps in the process. Measuring too many items can lead to death by measurement, an affliction that can be avoided. The goal of measurement is actionable information not death by numbers even though the later might be tempting.

Measurement programs represent the scaffolding for the analysis and presentation of data. The basic goal of a measurement program is organizing data so it can be interpreted more easily. Frameworks bring structure and organization to an overloaded information worker with allows them to first notice the data then to extract its information content. The quality of the framework will act as a governor on the level and speed of information extraction. The choice then becomes not whether a framework is needed but rather the efficiency of structure and the filters that will be applied. A viable framework of structure and discipline provides an anti-structure. Lack of a frameworks or an anti-structure belief is a will cause a large number of measurement problems, a prescription for making “Good Numbers Go Bad”.

 

Involvement Versus Focus; That Is The Question

Involvement Versus Focus; That Is The Question
Thomas M. Cagley Jr

Most process improvement programs extol the virtue of focusing on the needs of the organization or a specific class of users (usually senior or middle management). All said and done the virtue of focus is important but it is no longer sufficient to make change actually happen. The “organization” is being taken over by the World of Warcraft generation. This new crowd is beginning to believe they need to be involved if they are going to be asked to change how they are going to work. An example of that new expectation of involvement is reflected in the agile movement. Teams control how they do work and to an extent the work they will accept into the sprint. To the new generation, focus without involvement has come to mean big brother. Telling this new generation what to do whether you have their best interest in mind is deemed a paternalistic action, and for those with an expectation of being involved in their future, paternalism is at best grating and perhaps degrading. What does involvement mean? What is the new requirement to help an organization mature in terms of discipline and capability?

The American Heritage Dictionary defines involvement as “the act of sharing in the activities of a group”. At its core, I would suggest the concept boils down to collaboration between involved parties to achieve a common goal. I think we can all agree upon the ideal of using collaborative groups to conquer many types of projects. Workers acting in a concerted manner in real life leads to pressure on several organizational fronts in order to achieve this ideal. In a future essay we will explore another of my simple checklists (see www.tcagley.wordpress.com) to implementing involvement but in this essay I would like to discuss the impact of a common goal. In many organizations the management structure in use is the command and control methodology. In this method decisions are made at the top of the management pyramid then get transmitted to line management and then to project teams at the epicenter of work. In this model, management knows best because of experience, advanced degrees, having gone to a seminar or just divine right. To those being affected it doesn’t matter. The collaborative model suggests a different model in which management sets forth the goal then engages all parties to chart the course forward. Would the classic waterfall implementation of the CMMI survive a collaborative approach or would a more interesting approach to the discipline of software engineering emerge? I suggest that in combination the structure of the CMMI and the collaborative nature of AGILE methods are the natural outcome in today’s methodological environment. Note, I would suggest the pressure of the economy would add the philosophy of lean to the mix yielding a three legged stool of the CMMI as a framework and Agile and lean philosophies as the implementation techniques.

Change without involvement might work in the short run if you are bent on using a management philosophy of command and control but if you can step away from that model to embrace a more collaborative approach a better solution will be generated. A solution that yields discipline, collaboration, effectiveness and efficiency. Focus is a good thing but consider focusing on involvement rather than on using focus as a tool to speak for others.

 

Agile Estimation Using Functional Metrics, Part 1

Agile Estimation Using Functional Metrics, Part 1
by Thomas M. Cagley Jr.

The term agile has come to mean many things to many people.  The definitions and connotations range from how work is organized within a project to a description of the speed at which work is completed or alternately a radical rethinking of organizational culture.   Regardless of how you define agile I would suggest that we all would agree that agile methods are now maturing.  Part of the process of maturing is the incorporation of best practices from other methods and frameworks creating a hybrid.  The fringe is influencing the center and the center is influencing the fringe.  The hybrid is at once better than any of the absolutes and threatening to those who believe in absolutes.

Estimation has been a lightning rod for the discussion all methods (agile, waterfall, iterative or water fountain) with the issues of predictability and standardization radiating outward.  Because of the controversy this is an area where a wide range of hybridization has always occurred.  Organizations adjust techniques to fit governance structures, culture and risk profiles.  There is no one size fits all solution.   This paper provides a path for incorporating the use of function points into agile estimation techniques.  The process will yield an estimation process that combines one part functional metrics, one part parametric estimation techniques with two parts agile estimation (heavily influenced by Mike Cohn).   I would suggest that functional metrics provide a path for incorporating the best practices of robust software sizing with the collaborative techniques championed by the agile community in a manner that increase standardization without ignoring the principals of the Agile Manifesto.

Budgeting, Estimation and Planning

I’d like to begin this discussion by challenging your preconceived notion of estimation as compared to the activities of budgeting and planning .  These three concepts are sometimes thought of as being synonymous however I believe it is important to understand just how different these concepts are.  Each has different inputs and outputs, uses different tools and techniques and is generally used by different groups within the organization.

A quick overview of the macro differences are:
•    Budgeting
o    Defines how much we have to spend based on the influence of scope
o    Tends to ignore the cone of uncertainty
•    Estimation
o    Presents an approximation of effort and duration based on size and project nature
o    Focused by the cone of uncertainty (a range based on knowledge)
•    Planning
o    Defines tasks and allocates resources
o    Focused on the narrow part of the cone of uncertainty (a much smaller range)

Estimation, planning and budgeting might be related but they are certainly not the same.  The use of functional metrics in agile estimation is targeted at the estimation layer of this three layer cake but provides support for planning.  Developing a basic understanding of the components of estimation (we are going to ignore budgeting as bastion of guesses) and its relationship to sizing is critical to using these techniques.

Estimation

Estimation is several parts science and a least one part magic.  This strange confluence of science and magic defines the transformation of requirements size, skills, people and equipment into how much the project will cost and how much effort it will take .  The whole process of transformation is bound by a cone of uncertainty.  Uncertainty builds boundaries around the false precision of the estimate providing a range around the estimate based on what is known and unknown.  Collaborative estimation techniques are good at increasing team knowledge while reducing the amount of self-deceit that can occur when knowledge is discussed.

The amount of art increases as the estimation discipline is replaced by the planning discipline.  The art of planning matches specific tasks with people thru a process of assignment.  In a perfect world estimates and planning would be able to be done together in seamless workflow but estimates happen generally earlier in the project lifecycle before you can decompose work into tasks which is required for planning.

The simplest form of any estimation model, human or tool based is a mathematical mash-up of size (implied or counted), team and organizational behavioral attributes and degree of difficulty (technical complexity) applied to a productivity signature.  As the level of sophistication in the mathematics increases tools SEER, SLIM or KnowledgePlan make sense.  Other methods raise level of collaboration and do any of the required math in the heads of the participants.  These techniques include Delphi, analogy or planning poker. The process in this paper splits the difference leveraging collaboration to increase participation and self knowledge while suggesting the use of a simple spreadsheet based parametric models to increase consistency and standardization.

Sounds simple, right?  Estimation has been a nagging pain in every IT manager’s backside since a user asked how much a project would cost and when it would be done.   We have gotten pretty good at budgeting using techniques like “x number of people times 20 hours in a day and you’ll get something next year” methods.  It’s when we try to figure out how much functionality will be delivered in real life that  things start to break down or least get very, very complicated.

There are three main categories of problems that cause estimation to be problematic in the real world.
1.    Uncertainty: how much do you know about what you’re building?
2.    Self knowledge: what you do really know about yourself and your team?
3.    Consistency of method: do you have a process for estimating?

 

Relevance

Essay from SPaMCAST 58 (short and sweet)

Relevance is power

Irrelevance is desperation

Relevance is perceived

So is Irrelevance.

 

Models, Models Everywhere

CMMI, ITIL, Six Sigma, agile, waterfall, software development life cycle and extreme programming . . .what do all of these terms have in common?  They are models.  In a perfect world, models are abstractions that we find useful to explain the world around us.  Models work by rendering complex ideas more simply.  For example, both a road map and picture rendered in Google Earth are models.  Two very different types of models:   an abstraction of a set roads, buildings, parks and plants that exhibit can provide more information than rendering.  Real life is complex, Google Earth is less complex and the road maps are the least complex.  Simplifying a concept to a point allows understanding while too much simplification renders the concept as a pale reflection.  Oversimplification can lead to misunderstandings or misconceptions, for example the conception that agile methods are undisciplined or that waterfall methods are bureaucratic.  Both of these are misconceptions (individual implementations are another story).  According to Kenji Haranabe, software development is a form of communication game.  Communication requires that groups understand a concept so that it can be implemented.  Communication and understanding requires finding a level where common understanding based on common words can occur.  Words provide the simplification of real life into a form of model.  Unfortunately it is difficult to determine when enough simplification is enough.  Oversimplification of ideas can create scenarios where trouble can creep in.  Oversimplification can water down a concept to the point that it can not provide useful information to be used operationally.  An example of a very simple model is the five maturity levels commonly connected to the CMMI.  The maturity levels build awareness but provide little operational information.  I do not know how many times I have heard people talk about an individual maturity level as if the name given to that level was all you needed to know about a maturity level.   The less simplified version with process areas, goals and practices provides substantial operational information.  ‘Operationalizing’ an overly simplified model will yield unanticipated results and that is not what we want from a model.  I once built a model of the battleship Missouri that had horrible directions (directions are a model of a model), I used three firecrackers to remodel the thing I ended up with (which was not a very good model).

Models abound in the world of information technology.  If we don’t have a model for it t we at least have TLA (three letter acronym) for it and are working on a model that will incorporate it.  The models that have lasting power provide structure, discipline and control.  They’re also used as a tool to guide work (tightly or loosely depends on the organization) and as a scaffold to define improvements in a structured manner.  Models are powerful; molding, bending and guiding legions of IT practitioners.  The dark side of this power is that the choice of models can be definitional statement for a group or organization.  Selecting a model can elicit all of the passions of politics or religion.  Just consider the emotions you feel when describing Six Sigma, CMMI, eXtreme Programming, waterfall or agile.  One of those words will probably be a hot button.  The power of models can become seductive and entrenched so as to reduce your ability to change and adapt as circumstances demand.  A model is never a goal!  Define what your expectations are for the model or models that you are you using in business terms.  Examples of goals I would expect are of increased customer satisfaction, improved quality or faster time-to-market rather than attaining CMMI Maturity Level 2 or implementing daily builds.  Know what you want to accomplish then integrate the models and tactics to achieve those goals.  Do not let the tool be the goal.

Models are powerful, useful tools to ensure understanding, they provide structure and discipline.  Perform a health check.  Questions to ask about the models in your organization begin with:

1. Is there is a deep enough understanding of the model being used? – With knowledge comes the background to operationalize the model.
2. What are your expectations of value from the model? – Knowing what you want from a model helps ensure that the model does not become the goal and that you retain the ability to be flexible.

There are many other questions you can ask on your heath check however if you can’t answer these questions well stop and reassess, re-evaluate, re-train and re-plan your effort.

CMMI, ITIL, Six Sigma, agile, waterfall, software development life cycle and extreme programming. . . powerful tools or a straight jacket which is it for you?

 

Multitasking Yourself Away From Efficiency

Multitasking Yourself Away From Efficiency
by Thomas M. Cagley Jr

(Originally posted on the Software Process and Measurement Cast 57 – www.spamcast.net)

Increasing efficiency has been the clarion call for organizations in earnest for at least the past six months. Efficiency has a simple technical definition, the ratio work done to the energy required to do that work. The definition is similar to that of productivity however in normal usage efficiency is held to relate to how productive a machine or process is. Taking the more general usage it easy to see why efficiency is important. In the software development world efficiency and its relative productivity are rarely managed rather the discussion tends to be on cost. Cost and efficiency are different attributes, related but they are not the same.

Increasing the level of efficiency in a person, process or organization will require some kind of change. You do not get a different result by doing the same thing over and over. Using the manufacturing industry as a reference we know that in order to change efficiency, we need to change the process that transforms an input into a product or the environment the transformation occurs inside or the input such as people or raw materials or some combination of these areas.

While it might be too obvious for most people listening to the Software Process and Measurement Cast, the first place to look when you want to improve efficiency is the process being used. Removing process deadwood, simplifying the flow, adding tools and automation whether through frameworks like CMMI or agile or through techniques like Six Sigma, lean or others is a philosophy choice that needs to fit organizational culture. Unfortunately process changes are not instantaneous which is causing many organizations to jump over the process improvement step and go right to the cutting people as an option.

The thought process around the cutting people option goes something like this:

We will cut some percentage of people because we have gotten ‘fat’. When we cut people those that are left will pick of the slack through working a little harder and by multitasking. They should just be happy to have jobs. Tasks that we just can’t cover anymore probably didn’t need to be done anyway. I have thoughts on this last sentence that I will share in a few weeks.

Multitasking is in general thought of doing more than one thing at a time. The silver bullet of the 21^st Century. Relying on multitasking steals efficiency. Unfortunately multitasking is a common tool we are being asked to use in order to manage the world around us. According to René Marois, a neuroscientist and director of the Human Information Processing Laboratory at Vanderbilt University, “trying to do two things at once can be disadvantageous.” Now I will readily admit that I have not been able to put aside multitasking all of the time. Humans do most of their multitasking in an unconscious mode (breathing, pumping blood and other mostly autonomic tasks). I have tested conscious multitasking personally trying to text or talk on the cell phone while driving; no one has died, yet although my wife has threatened divorce. Unfortunately humans aren’t good at multitasking! Humans do not really multitask, what we do typically is fast switch shuffling between tasks quickly focusing on each slice for a brief period of time. It is during the switch and reorientation that we loose efficiency. In an article published in the “The Journal of Experimental Psychology: Human Perception and Performance” reported in a 2001 a study by Joshua Rubinstein, David Meyer, and Jeffrey Evans on the brain’s executive control process found that “at best, a person needs to be aware that multitasking causes inefficiency in brain function.”

Focus is required for efficiency. Doing one thing at a time correctly has an appeal both in terms of logic and science. We are faced with the issue that most workplace cultures do not seem to support focus with action. As evidence I suggest you count the number of interrupters in your environment (cell phones, email, twitter, instant messengers and pagers to name a few). Our work culture is sending a strong message that you are not expected to be cut off from the information flow at any time. The ability to deal with continual partial attention is a career success factor in many instances. Quite time for concentration tends to happen outside of core hours or at home when we are tired. The question we must ask is when the does the cost of interruptions and multitasking ever outweigh the benefit of focus? How can we construct processes or environments that allow connection and collaboration to happen while providing an atmosphere where focus is not the odd man out of the equation?

 

A Friend In Need . . .

A friend in the IT Consultant / IT Project Management world is looking for work. The summary on her resume reads as follows:

Results-oriented Manager with exceptional customer service and leadership skills. Extensive experience with:

• Project & Program Management

• Enterprise SW Development & Deployment

• Business Process Definition & Improvement

• Six Sigma Quality Improvement Initiatives

• SDLC and CMMi

• Sarbanes-Oxley IT Compliance

Roanoke, VA Area. Send me an email if you’d like to have a chat with her and I will act the matchmaker.

 

Interested or Interesting?

I recently heard the suggestion that it was more important to focus on being interested rather than being interesting. The rational for the suggestion was that being interested would be helpful in at least two ways. The first was that being interested will cause you to be a sponge, continually expanding your horizons. The second was that by being interested you tend to be quite and listen making the first point easier. Listening allows one to make sense of and understand what another person is saying.

I would suggest that the attribute of being interested is a reflection of an outward rather than an inward focus. Being interested will require searching continually for new inputs. Inputs are the building block from which knowledge can be built. Another impact of being interested is that an outward focus improves memory because being interested means you are paying attention and paying attention allows you to remember what you are paying attention to.

The acquisition of information and knowledge is not a simple linear process. All human beings filter inputs. The process of decoding color is one of those simple interpretations that can have more than one outcome based on the filter applied, just ask any color blind person you know to describe the world around them to you. The difference between your interpretation and his (most color blind people are male – trust me I know as I am one of them) can be eye opening. It is important to realize that the effectiveness of your input process is dependent on your individual filters. Some are permanent like color blindness while some can be controlled. One of the most important controllable filters is your perspective on life. I would suggest that those with a positive view of the world will filter inputs differently than those that have a negative point of view. Our perspective on the world informs our attitudes. An attitude is “a process of individual consciousness which determines real or possible activity of the individual in the social world”*. In my opinion a positive view of the world will tend increase the scope of inputs available therefore making it easier to be interested in the world outside of specific sphere of influence. A larger sphere of interest yields more inputs and more to be interested in.

I see the line between positive and negative perspectives as a dichotomy. It is something I battle within myself. However I do not see the attributes of being interested and interesting as a strict dichotomy. The dichotomy comes when you focus on being interesting as a goal and curtail your journey as a seeker of knowledge. I suggest that being interested makes it far easier to be interesting at a deeper level. It is a common misconception that you must be an interesting person to get people to like you. Rather it comes down to your ability to make the other person feel special and make them feel that you really connect with them. These are acts of being interested. Which brings us back to the choices we make on how we approach the world around us. Having a positive perspective only makes it easier to be interested and to connect with the world.

* THOMAS, W. T., & ZNANIECKI, F. The Polish Peasant in Europe and America. New York: Knopf, 1927.

 

Gary Gack has posted a survey

Gary Gack (whom I know and have interviewed on the Software Process and Measurement Cast – www.spamcast.net) has posted a survey. Please take the time to fill it out!

Hope this finds you well and prospering. I’m conducting a survey on defect containment practices and metrics. I’m in hopes you or someone in your team (or maybe among your clients) will respond to the survey with either current or earlier data – it’s quite short. I’ll share a summary of the results with you when I get a reasonable # of responses (4 so far, since Friday). Please feel free to refer the link to anyone you think might participate – I plan to keep it live for an extended period.

http://www.surveymonkey.com/s.aspx?sm=v9v4RBH9fe4Mu8M9Pw97VQ_3d_3d

 

Software Process and Measurement Cast – Metacast Year 3

Software Process and Measurement Meta Cast
Thomas M. Cagley Jr.

This blog entry was included in the Software Process and Measurement Cast 55 (http://bit.ly/ulZBQ)

Year Two has come and gone. The third year of the Software Process and Measurement Cast is well underway. Let’s start with the bottom line the state of the SPaMCAST is good and getting better. One of my goals for the SPaMCAST was to talk to all of interesting people in the IT industry. Let’s just say\there are a lot more people whom I want to interview.

I’ve been asked many times why I created the SPaMCAST (more than just my wife). The words I use to explain why I do the Cast have evolved over the last two plus years, at least in my head. I started doing the Software Process and Measurement Cast for three basic reasons.
The primary reason was as a vehicle to pay back the industry I make my living from by paying information forward. I’m the Vice President of the David Consulting Group which is a consulting firm specializing in helping organizations increased their IT efficiency and effectiveness (www.DAVIDCONSULTINGGROUP.com). The interviews and essays are the tools I use to pay information forward.

I will admit that altruism is not the only reason I do the SPaMCAST. I readily admit that I learn from every interview. I learn both from doing the research prior to the interview and from the conversation with the interviewees. I decide who is to be interviewed by watching the software development market, focusing on how people work and how they measure their work. The criteria I have to put someone on the list is simple, “be an interesting person, doing interesting things”. Once a person is on the list the chase to book the interview begins. The chase is my form of hunting. To date I have had two people say “no” (one for a good reason and one for no apparent reason). The interviewee list is long in getting longer almost on a daily basis. Regardless of the length of the list I am interested in your suggestions on whom to interview and in what order. I could also use your help running some of the people on the list down. If you have ideas or want to help, contact me by e-mail (spamcastinfo@gmail.com).

The final reason I have for doing the SPaMCAST is that I’m a fan of radio. I was a broadcast personality in the far distant past and I have been a ham radio operator most of my adult life. My six world story for this part of my life might read, “have microphone, have ideas, will speak.”

The cast is in good shape. I’ve a number of ideas for pushing the Cast forward into new areas, lots of people left to interview and talk with and finally a lot of content and advice to share. The rate of change will be driven by both of our interests and by your participation (the more participation, the better). Want to help? Want to do a guest essay? Want to create a periodic segment on the happenings of associations and conferences you are involved with? Or do you have other ideas that will keep the SPaMCAST vibrant? Let me know and we’ll find a way to make it happen.

One final note and I considering soliciting and accepting donations to offset bandwidth and other administrative costs. I have not made a decision on this topic and would like your thoughts to help frame the decision.

Thank you for listening! Thanks for the comments! I hope to share the software process and measurement cast with you for a long time to come.