Archive for October, 2015

We have grand aspirations for this portion of the site. We provide a review of Value Transformation’s growing Product Development University. This online training area will have many topics on product development explained, such as agile, project management, product testing and many more. Everything from the idea (cradle) through manufacturing and finally the end of product life cycle will be addressed here.

I have been reading some Twitter and LinkedIn post from numerous, but especially Mario Lucero, about multiple product owners, and product owners and scrum masters with multiple projects and the like. I have not seen any studies on this, but experience tells me a significant obstacle to project success is the diffusion of the available talent. This is not just an agile obstacle to success, but from my perspective a significant source of failure in conventional projects. In the organizations endeavor to do more with less, we put our people and our projects at risk. We thrust project loads on team members so we do not have to say “not now to our product sponsors or stakeholders”.

This is not the only failure mode we can see. For example, project managers, line managers and executives that are working to maximize the amount of output from their respective areas push ever higher expected output or volume of work while not improving efficiency nor adding head count. That is not so much a problem if the content were contiguous, but when the tasks or objectives are disparate we find the multiple projects that people carry can become serious distraction and add risk to success. Experience suggests this to be a significant source of failure in conventional projects.

Project managers or scrum masters that do not contest situations in which the talent is spread thin, are just as culpable. Rather than work to ensure the highest probability of success, the choice is to go along with the organizations diffusion of the talent. This is not a fix.

Are we not making the agile methods the new conventional when we adopt the bad habits of diffusion of the available talent across too many projects? This is not solely a conventional project phenomenon and we run the risk of diluting this benefit that comes with employing an agile approach.

We have discussed the Failure Mode Effects technique a few times in the past. Though Failure Mode Effects and analysis seems to be a powerful tool, the problem is you do not know if the FMEA is effective and perhaps you will never know. The Failure Mode Effects Analysis tool, theoretically, allows us to critique the product before we test. How do we prove something did not happen because of a well conducted FMEA? I have seen failures arise in testing and post launch. In both instances I found it difficult to believe we missed the issue in the development or testing work as the failure seemed obvious. I would later discover the FMEA was either missing or performed with a check box mentality, both of which are poor execution and not necessarily a testimonial of the apropos of the technique. Of course this is only anecdotal evidence.

For me the real benefit is when we wed the FMEA to our testing. We theorize something in the FMEA, a particular failure will have a specific set of consequence, but we may not really know. We set about testing the more egregious failures. The severity of the failure may not be what we have attributed. The same is true for the occurrence. Perhaps what we thought was going to be an insignificant probability of occurrence, upon testing; we find the failure to be much more common. We are now in a position to take action based upon this evidence.

As Kim Pries say, it takes sound design and harsh testing. However, I would add harsh critiquing goes along with sound design and harsh testing. Unfortunately, that is tough to come by and FMEA’s can descend into what I call a bunch of glad handing due to poor execution.

It is certain if there are benefits from doing an FMEA, if you do not them or do them poorly those probably benefits disappear.

The product owner impacts the sprint set up through the business case. This person is responsible for ensuring the input to the scrum actually makes business sense, and by sense we are talking about economic sense. The product owner is responsible for ensuring there is business value, without that, there will be no sprint. The product owner is also responsible for the product backlog which often consists of more than one or two items, and can include much more. The product owner will also prioritize the product backlog often along those same value propositions. That is, the most favorable business value will be their highest priority items. They will not present a lengthy list of items that all have the same level of priority – give this all to me now approach. One of the roles of the scrum master is to ensure that the product backlog meets some level of acceptability. That means value proposition by the product owner and the list of items are prioritized so the scrum team can determine what best fits in the sprint.

The sprint team has the greatest influence on the sprint. They are the ones that will say what from the prioritized product backlog can fit into the sprint. This will happen in the sprint planning meeting. The sprint planning meeting is a time boxed event (between 4 – 8 hours). We do not want our team to spend in inordinate amount of time planning.

The Sprint Planning Meeting is the first meeting to kick off the sprint. It is attended by the Scrum Master, Development Team and the Product Owner, along with interested and invited stakeholders. The meeting is time boxed to 8 hours, so it’s important to gather first thing, usually on a Monday morning. The Product Owner comes prepared to the meeting with the Product Backlog organized and ordered. These can be in the form of user stories and tasks, or just a list of requirements.[1]

While this article indicates a single duration of 8 hours, like most agile applications or any project management application we will find variation in the application.

Sprint velocity or speed, is a calculation based upon a series of sprints and the estimating technique that employs story points. The sprint duration or available hours for work to produce a single iteration is the multiplication of the number of team members, the hours, and number of work days. This is not velocity, but tells the team, scrum master and product owner how many available work hours for the sprint.

Unlike conventional project, where executives may dictate the amount of time to accomplish some objective, the team decides how many hours are required for the tasks to achieve the objective and thus the hours for the objective.

[1] What Happens At A Sprint Planning Meeting? (2011, August 15). Retrieved October 24, 2015.

The Learning Organization

We are developing an online class at Value Transformation titled Learning Organization and Project Management. In this class we wed the discipline of project management with the learning organization and motivation. As we work and develop the material we consider opportunities that are available for an organization to grow and become more capable through the talent growth. We are talking about an organization level learning, the process of creating, retaining and transferring knowledge throughout the enterprise making the organization more capable. One of the topics often glossed over in project management and the organization learning discussions are assumptions.

The Old Saying about Assume

My dad was in the military, so I know the obvious saying that goes with the word assume. Since this is so cliché I prefer not to use that here, but will only say that making assumptions ends poorly for everybody – or so says the saying.

Personally

Personally, most assumptions I make are either based upon experience or playing out the scenario in my head thinking not only at the immediate detail level, but from a systems perspective. This is done by thinking forward, what past experiences can help me make sense of this situation that I can bring to bear to allow me to predict or estimate for example. Project teams work though these every day. Wide Band Delphi and Planning Poker both work to understand underlying assumptions as part of the process. The team members or experts make their estimates, after which we discuss the reasons for any disparity of estimates by asking why somebody answered the way they did, thus starting a discussion about the assumptions and perspectives that influenced their answer.

Assumptions Unsaid

Unarticulated assumptions do not put the project team in a position to clarify or establish the veracity of the assumption in context of this project. Unchallenged assumptions are nearly as bad as unarticulated. A team that is not in a position to set up an experiment, investigation, or provide additional supporting or contrasting perspective are not in a position to learn about the assumption. Unarticulated and unchallenged assumptions therefore are not much different and likely end the same way. We have learned nothing about the validity of the underlying assumptions. We may learn something in retrospect as we miss an opportunity or worse make a disaster of our project.

Assume Conclusion

Assumptions are not the problem in and of themselves. Left unarticulated or critiqued for validity, we can find our team going off in a poor direction based upon assumptions of which the most of the team were unaware. The mere discussing assumptions aides organization learning by providing an interaction over a perspective held by some portion of the team. These various perspectives can help determine if the assumption is valid in this instance, or perhaps find reasons why in this case the assumption is errant. The discourse and the sharing of perspectives are part of the learning organization, a concept developed by Peter Senge and his colleagues in the book The Fifth Discipline.

Processes and Procedures

Words mean things, and words can have many meanings. This meaning can change due to context. For example, consider if a person asks you to go to the boot of their car and retrieve their suitcase. You can be pretty confident that there are no shoes on the wheels or hubs of the car from which you will retrieve the suitcase, so there must be some other meaning behind it. If you have experienced some other variants of the English language, you will know it is the trunk of the car.

A good start will be to review some definitions for process and procedure.

Process

A series of actions that produce something or that leads to a particular result[1]

Procedure

The sequence of actions or instructions to be followed in solving a problem or accomplishing a task[3]

A particular way of accomplishing something or of acting. A series of steps followed in a regular and definite order[4]

So Agile Is…..

This brings us to the reason for the post. We assert that the description of agile is a high level process. We have inputs into the system that can vary greatly – that we can call the product backlog. Through a series of actions we will turn the product backlog into a sprint backlog, we will turn the sprint backlog into product, and demonstrate that product. We will learn from the work via the retrospective. This is a high level process that provides structure and our team will think about the situation and determine the best approach to the objective or task with guidance from the scrum master.

Even the drawing looks like a process or even a machine. We see inputs and outputs feeding other actions.

http://www.toolshero.com/nl/scrum-agile/ last accessed 10/22/2015

Even the drawing looks like a process or even a machine. We see inputs and outputs feeding other actions. Whatever you call it, it describes a series of steps, though not exhaustive nor prescriptive.

Miles also identified the concept of basic and secondary functions. Basic functions are the fundamental reason the customer is willing to buy the product or service. The basic function of an automobile is to transport the customer. The basic function of a shoe is to “protect foot.” Secondary functions are those functions for which the designer has the flexibility to find an effective solution. A secondary function supports the basic function. Miles discovered that secondary functions are often a huge component of the total cost of the product.

A simple plan for proceeding through the Miles approach is as follows:

1. Separate the functions (we can use a spreadsheet format to capture our preliminary ideas).
2. Work and rework the two-word descriptions with particular attention being paid to those we might be able to measure
3. Analyze each function for methods, materials, measurements, manpower, and machines as well as environmental considerations.
4. We can build an Ishikawa diagram for each function. The depth of labor we put into this project will be dependent on the expected cost savings.
5. Estimate the cost of each function.
6. Roll-up the costs of the functions to calculate an overall cost for the product or service.
7. Prepare work in a spreadsheet format for cost comparisons.
8. Be patient and diligent

Miles also recognized that a given product or service might have functions that are dependent on other functions. The solution approach chosen here was list the functions in an appropriate order, which is easy to say and often difficult to execute.

1. Evaluate each function as if it were a simple function.
2. Move on to a dependent function and continue to evaluate.
3. Complete the list by following the logic of the dependencies.

Miles was also highly concerned with accurate cost analyses of products and services. He suggested that function-property relationship (e.g., nomograms and other plots of performance) were readily available to designers. Usually the designer could also find the property-material relationships as well (e.g., tensile strength). Some catalogues provide material-cost information. He declared that we can then work our way back to functional cost from the material cost information.

Finally, Miles stated that costs were really based on comparisons, since “value” is an ambiguous term with no absolute measure. This concept implies that we must understand what is valuable to the customer. In some cases, the aesthetics may be of more importance to a given customer (e.g., they might like the way the painting looks in their house). In cases where the product is not seen by the end customer, the aesthetics of the product may have minimal importance.

Miles provide a straightforward algorithm for working through the value analysis problem, using the following steps:

1. Identify the functions.

2. Separate functions.

a. Start with the total or basic function.

b. Proceed to sub consciousness.

3. Group functions into assemblies with well-defined purposes (somewhat similar to what we do when we create an affinity diagram).

4. Recognize the problem at hand.

5. Capture required information (e.g., materials cost).

6. Explore new solutions creatively.

7. Select the best choices, with especial attention on cost.

8. Assess the disadvantages of the best solutions and minimize these, much as we do with robust design.

9. Execute the new set of improved solutions.

10. Eliminate any “show stoppers.”

11. Push the project to a decisive conclusion

Miles used the term “results accelerators,” which included:

1. Information from the best source
2. Dropping of assumptions sufficient to annihilate preconceptions and permit real refinement.
3. Use real creativity rather than copying the previous solution or only “tweaking” the previous solution.
4. Push through “show stoppers.”
5. Feel free to use industry specialists (e.g., supplier experts, customer experts, consultants, and contractors).
6. All tolerances should have a cost associated with them (once again, this relates well with robust engineering, where tolerance design occurs at the end of the process).
7. If commercial-off-the-shelf products meet the requirements, then use them in the solution.
8. Be willing to pay the supplier for their knowledge; after all, they are then functioning as a consultant to our firm.
9. Use the appropriate standards—it makes no sense to ignore a standard and lose money subsequently because we must recall the existing product and redesign the product and production process.
10. Personalize the spending; after all, money spent on wasted time is money that won’t be used for a bonus, profit sharing, or any other reward system.

Miles’s concepts were brilliant and provided the underpinning for the functional analysis system technique. Snodgrass and Kasi provided further theorizing on the approach. Other individuals have contributed to the body of knowledge related to FAST: Charles Blytheway (Sperry Corporation), Wayne Ruggles (Value Analysis, Inc.), and Theodore Fowler (Value Standards, Incorporated).

Snodgrass and Kasi broke their process into discrete phases:

1. Information

2. Creativity

3. Evaluation

4. Planning

5. Implementation

As with Miles, Snodgrass and Kasi realized that a large part of the problem with our products and services lay within the way people coded their expectations of the functionality of the product or service. They used the same verb-noun concept proposed by Miles. One of their epiphanies occurred when they realized that users of a product often do not understand the constraints of the product. Again, agreeing with the insight of Miles, they felt that the key concept was the determination in unambiguous terminology of exactly what a product/service was supposed to do.

We can take a look at function identification, which may be the single most difficult step in the process of determine exactly what the product is supposed to do. One issue lies with assumptions that a given function or group of functions must be present, much like the situation with human beings—they don’t pay a doctor a prescription; they pay the doctor in order to feel better. These kinds of assumptions can become limiting concepts; that is, they are illusory constraints. An example of this issue in school counseling occurs when we try to define what a counselor does.

1. Do they provide psychotherapy for students?

2. Do they reassign students to different classes?

3. Do they inform students of poor scholastic performance?

We suggest that the counselor’s basic function is to “champion students” even though this sounds like hand-waving

FAST Introduction

FAST is an acronym for functional analysis system technique. FAST allows us to reduce ambiguity in the definition of a functional product or a functional process (and probably fro some dysfunctional one also!). Value of a product is interpreted differently by different customers. Characteristics that are common to value are high level of performance, capability, emotional appeal, and style relative to its cost (see figure below). Value is generally expressed in terms of maximizing the function of a product relative to its cost:

Value = (Performance + Capability) / Cost

Value = Function / Cost

Our FAST diagram thus far.

Value is not minimizing cost. Though, for some cases, we can influence the value of a product by increasing its function (performance or capability) and cost as long as the added function increases more quickly than its added cost. The concept of functional worth is important, which is, the lowest cost to provide the given function.

Lawrence D Miles[1] is the father of modern value analysis and value engineering. His first key concept was the idea of “use function.” A product could have us functions or aesthetic functions. Use functions require and action to occur while aesthetic functions please the end customer.

Miles Identified three steps related to initial investigation into functions:

Identification

Clarification

Naming

He required functions to be stated in exact sentences. In order to make the process ostensibly simpler, he required a verb and a noun, producing short phrases that look like miniature sentences written in the imperative mood. For example, we might use:

Generate torque

Control vibration

Fasten panel

Bill customer

The first example is particularly valuable because we can measure torque with appropriate devices, which suggests that we want to choose nouns we can measure, for example:

Volts

Amperes

Ohms

Length

Any scalar value is a good candidate for a functional noun and simplifies the process of measuring cost. Verbs must be precise and describe an action, making the exercise more difficult than it might appear at a first glance. With FAST, all functions must be in a verb-noun format.

Mile’s second key concept was that of the aesthetic function. Aesthetic functions are specified the same way we specify use functions. For example:

Reduce noise

Improve Visibility (might also be a use function)

Minimize duration (in other words, reduce time it takes)

Use of verb-noun becomes quite difficult as we dig more deeply.

With both use functions an aesthetic functions, we provide that for which the customer is willing to pay. We might guess that we have some cost opportunities in the aesthetic area, with higher end automobiles being an example of aesthetic function for profit.

In Project Management One size does not fit all.

Product development and project management can be very complex and complicated with variations and permutations that make a prescriptive approach impossible to produce successful results. That goes for any brand or type of project management. What is important is to have an arsenal of skills, tools and techniques and use what is needed based upon the situation. Couple this with a bit of creative thinking to allow you to adapt and find other ways. This is the technical or project management version of Situational Management or Situational Leadership.

For any approach to be successful we should take a system’s view and approach. We need to know our organization and the operating environment. We should know the objectives and what our organization is willing to do to meet this objective. The areas of technical concern are also of interest. For example, I once heard an agile team say they did not need configuration management because they were using agile. Apparently their interpretation of agile allowed them to dispense with this product management area. However, the product was software, and iterations were planned, and the product interfaced with a number of other components. All of these things made the idea of eliminating some form of configuration management risky and without merit. Perhaps a scaled down version, but dispensing of this management area associated with product development for this specific project was not a path to success. There will be limitations to any prescriptive approach. There will be limitations of an open system as well. We are agile so we do not need other project management areas, that are not…well, project management areas. That is like saying I do not need tires for my car because I have an engine.

Project Management techniques and tools independent of origin

Believing a process or a framework or set of procedures will always be helpful or save your project and your product is perhaps never a long term approach. Only if the project scope, organization and expected results have limited variation can we think that one set of steps and procedures will most of the time. Consider instead that agile and conventional project management approaches offer an array of tools and techniques that can be employed in a variety of ways. Perhaps what is required is a mash up of the offerings for each of these approaches. The truth is either approach poorly executed will likely produce poor results, only luck will save you. Rather than disdain either of the approaches as inferior, look at the benefits that lay in each and decide the approach based upon the situation, available resources, objectives and willingness to accept risk. Pause, think and be willing to go beyond these artificial boundaries, take the best and use

Technical Talent Move and it is bad

I would like to credit this blog post to Tony DaSilva, since his tweet a day or so ago. As I read it, I had instant reactions. That is right, reactions as I could see a range of ideas radiating from his post.

My first reaction, because I know him to be a person of significant capability, I agreed with him. Taking technical talent and moving them up into management or working them into management or project management positions can serve little to perpetuate the technical excellence in an organization. That was my first reaction. Followed closely by, if technical talent would like their compensation package to at least keep up with inflation, they will at some point have to leave the strictly technical path.

Technical Talent as Managers

Then I thought a little deeper about this. Perhaps it is not an anathema to technical excellence. Let us consider the manager position first, by defining manager. There are many different organization structure types and different manager types as well. For this post, let us consider a manager is the person responsible for overseeing the work in a particular area or discipline. These people are responsible for the work within the department, the quality of the output and any perhaps even associated processes. In some organization, the manager is responsible for coaching the team and the individuals to get the most out of their innate skills and cultivate even more skills and capabilities that will improve the department’s capability. If the department’s particular area or discipline is that of the technically prodigious person, then it is possible to see how this persons skill level can be used to transfer this capability in as much as can be done, to the employees of the department. In this way, we are building upon their talent by using it to build the other talent in the department – effectively growing the competency of the group. This is predicated on the instance where the technical talent, now manager, is moved into a management position commensurate with the technical talent. They must be able to disseminate their knowledge to the team or department members. That is not possible if we take say software or product testing talent and move them to a marketing management position. Then it is an anathema of technical excellence.

Technical Talent as Project Managers

Let’s consider the project manager role. We take technical talent, skilled well in some domain and then move them to a project management position. The skills required to be a good or successful project manager are varied. From the position of project manager, it would be difficult to build the technical competency in others, in a specific domain. The project manager must divide their time among the various disciplines that are in the project’s employ. If the technical expertise is in embedded code, there will be little opportunity to coach or build those remaining in the department. Additionally, we have seen project managers who were once technical hyper focus on their technical domain to the exclusion of the myriad other areas of the project.

It is not necessarily a technical sacrifice to move a person from the details of a technical domain to a management position. We can perhaps gain some benefit by careful consideration of where we employ the talents of the technical individual.