Barry Boehm on the CRACK Customer
Dr. Barry Boehm, a noted software methodologist with a long and illustrative career at TRW, DARPA, and USC, and author of the COCOMO model and Sprial methodology, writes about the ideal customer for agile projects. They are:
-- Collaborative: they will engage with their customer peers and with the development team
-- Representative: they know the product or system requirements and can represent their constituents accurately
-- Authorized: they can make the decisions needed to keep velocity up, and their decisions stick!
-- Committed: they take their job seriously and make every effort to advance project success
-- Knowledgeable: they can understand what the developers are telling them in the context of the business or market situation.
Take a look at other Boehm'isms on agile in his book, with Richard Turner, "Balancing Agility and Discipline: a guide for the perplexed", published by Addison-Wesley in 2004
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
Sunday, June 14, 2009
Monday, June 8, 2009
Quotations worth a moment
I enjoy a bit of wit and humor. Here are a few of my favorite quotes:
Instead of trying to make the trains run on time, it might be better to do away with the trains!Anonymous
There is no undo button for our oceans of time.
Tom Pike
Brooks Law Adding manpower to a late software project will make it later!
Fred P. Brooks
About sequencing:
Nine women can't have a baby in one month
Anonymous
Nine women can't have a baby in one month
Anonymous
Somebody's sitting in the shade today because someone planted a tree a long time ago
Warren Buffett
Lies, damn lies, and statistics!
Benjamin Disraeli
There are no facts about the future
David Hulett
Value increases when the satisfaction of the customer augments and the expenditure of resources diminshes
Robert Tassinari
We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten.
Bill Gates
If the customer is not satisfied, he may not want to pay for our efforts. If the customer is not successful, he may not be able to pay. If he is not more successful than he already was, why should he pay?
Niels Malotaux
It is very difficult to make a vigorous, plausible, job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers
Fred P. Brooks
A requirements paradox:
Requirements must be stable for predictable results
However, the requirements always changeNiels Malotaux
Requirements must be stable for predictable results
However, the requirements always changeNiels Malotaux
Saturday, June 6, 2009
Agile Virtual Teams
Somebody asked: can a virtual team do Agile? Of course, with some adjustments. Here are my thoughts on this.
The communications channel:
Virtual teams often begin by emulating the behavior and circumstances of real teams. The first thought is communications. Real teams can handle a much greater N2 communication intensity because much of person-to-person communication is non-verbal.
What is N2? It's really N-squared. It's the approximate number of ways objects can communicate. The real formula is N(N-1). There are 5*4 ways 5 people can talk among themselves.
Non-verbal is a very high bandwidth channel, capable of communicating a large information message instantly, although the messages are often highly encoded and subject to inaccurate decoding. It's much easier to sort out the cacophony of discussion if you can put face and voice and context together.
Consequently, when planning for virtual teams, bear in mind that virtual teams don't have the luxury of infinite bandwidth
Velocity impacts:
Some teams relish the hub-bub of real time communications, and others do not. Good practice is to benchmark the virutal velocity before beginning the first iteration.
Assigning team work:
Assigning work to virtual teams should follow this simple rule: partition work according to its natural boundaries that minimize and simplify interfaces. Albert Einstein has been quoted to the effect: "Make everything as simple as possible, but not too simple". But over simplification is hazardous also. The solution can lose cohesion and the bigger picture becomes so obscured that effective solutions are not possible to build from the too-small parts.
Iteration Planning and tracking:
The iteration planning meeting is the agile mechanism for assigning work. All the team's complement attends. The same applies to a virtual team.
Tracking progress and identifying problems:
Only the daily stand-up meeting is affected by the communications unique to virtual teams. The less efficient electronic channels may have to be compensated by extending the time-box of the daily stand-up.
The burn-down and trending data is part of the team scorecard posted electronically as opposed to marking a whiteboard in a team space.
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
The communications channel:
Virtual teams often begin by emulating the behavior and circumstances of real teams. The first thought is communications. Real teams can handle a much greater N2 communication intensity because much of person-to-person communication is non-verbal.
What is N2? It's really N-squared. It's the approximate number of ways objects can communicate. The real formula is N(N-1). There are 5*4 ways 5 people can talk among themselves.
Non-verbal is a very high bandwidth channel, capable of communicating a large information message instantly, although the messages are often highly encoded and subject to inaccurate decoding. It's much easier to sort out the cacophony of discussion if you can put face and voice and context together.
Consequently, when planning for virtual teams, bear in mind that virtual teams don't have the luxury of infinite bandwidth
Velocity impacts:
Some teams relish the hub-bub of real time communications, and others do not. Good practice is to benchmark the virutal velocity before beginning the first iteration.
Assigning team work:
Assigning work to virtual teams should follow this simple rule: partition work according to its natural boundaries that minimize and simplify interfaces. Albert Einstein has been quoted to the effect: "Make everything as simple as possible, but not too simple". But over simplification is hazardous also. The solution can lose cohesion and the bigger picture becomes so obscured that effective solutions are not possible to build from the too-small parts.
Iteration Planning and tracking:
The iteration planning meeting is the agile mechanism for assigning work. All the team's complement attends. The same applies to a virtual team.
Tracking progress and identifying problems:
Only the daily stand-up meeting is affected by the communications unique to virtual teams. The less efficient electronic channels may have to be compensated by extending the time-box of the daily stand-up.
The burn-down and trending data is part of the team scorecard posted electronically as opposed to marking a whiteboard in a team space.
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
Wednesday, April 22, 2009
An Old Question Revisited: How do you manage cost?
I was asked recently in a way that begged for an 'elevator speech' reply: "How do you manage cost?" My goodness! How much time do I have to reply? Isn't that question even older than project management itself? Is there any more to be said?
The best way to answer is to have a conversation, because the response is all tied up in values: is cost the dominant leg in the cost-schedule-scope-quality trade space? Or, is the proposition to always manage to a 'best-value' formulation? If value is what we are willing to pay for, then presumably best-value is also lowest-buck for what we get, but it may not be the lowest cost solution for the minimum requirements. So, we need to get the value thing decided straight away.
The mistake most made is to manage cost like it is an input, rather than a result. Managing at the input means watching the cash flow in comparison to the budget plan for cash consumption. This will provide comfort to the CFO, but it does little for the other stakeholders. The cash flow could be right on plan, cash consumed exactly as planned, and yet the project could be churning pointlessly and producing nothing. There is no value proposition at the input, so continuing to focus on the input side of the project process is strictly a CFO task.
Value is produced at the output. By now, everyone should know this. To manage cost is to manage three variables: budgeted cash flow at the input, actual cost in the process, and value of the actual outcomes.
> The budget is managed with the requirements process and the estimating skills of the team. Each of these, the requirements and estimates, are independent sources of error, and then there are co-variances between them that stretch the errors.
> The actual cost is managed by attention to effective practices, efficient procedures, and look-ahead risk management. Effectiveness is a measure of impact, efficiency is a measure of effort to produce impact, and risk management is foreseeing problems in time to reduce their impact
> Value is managed by insisting on an outcome that meets the quality standards of the stakeholders, but does not overreach on attributes that aren't valuable, to wit: better is the enemy of good!
If you are into an earned value management mind-set, then you recognize the EVM concepts in the foregoing:
> the budgeted cost of the work scheduled, aka BCWS, aka the Budget or Planned Value [PV],
> the actual cost of the work performed, aka ACWP, aka Actual Cost [AC], and
> the budgeted cost of the work performed, aka BCWP, aka Earned value [EV].
There are several ratios and other formulas that you can make out of these four parameters to explain history and forecast the future, but the one that is missing from all the EVM systems is AC/PV. This is the infamous input view we spoke of before. It carries no value; it only measures adherence to a spending plan.
By the way, forecasts are the weakest link! Does history ever repeat? Milton Friedman, distinguished economist, opined: "if you are going to predict, then predict often!" Meaning: hey, things change.
It's a lucky project manager that actually gets to control the labor AC to only that which is needed to produce the EV. This is another of those conversations we need to have. How many times have people been placed on projects because they would otherwise be on overhead and vulnerable to release? How many times have people been retained on projects, the so-called marching army, because PM's have been told they can't get them back if they release them? Smart management anticipates labor redundancies, but also labor losses that might impact the EV: vacation, sick leave, other duties as assigned!
It's a lucky project manager that actually controls the overhead expenses of their project. In point of fact, many projects are encumbered with liquidating enterprise expenses disproportionately to use. It's part of the game, so smart cost managers anticipate the impact of changing overhead positions.
Now the challenge remains to get this all into 30 seconds so that it will sound good on the elevator!
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
The best way to answer is to have a conversation, because the response is all tied up in values: is cost the dominant leg in the cost-schedule-scope-quality trade space? Or, is the proposition to always manage to a 'best-value' formulation? If value is what we are willing to pay for, then presumably best-value is also lowest-buck for what we get, but it may not be the lowest cost solution for the minimum requirements. So, we need to get the value thing decided straight away.
The mistake most made is to manage cost like it is an input, rather than a result. Managing at the input means watching the cash flow in comparison to the budget plan for cash consumption. This will provide comfort to the CFO, but it does little for the other stakeholders. The cash flow could be right on plan, cash consumed exactly as planned, and yet the project could be churning pointlessly and producing nothing. There is no value proposition at the input, so continuing to focus on the input side of the project process is strictly a CFO task.
Value is produced at the output. By now, everyone should know this. To manage cost is to manage three variables: budgeted cash flow at the input, actual cost in the process, and value of the actual outcomes.
> The budget is managed with the requirements process and the estimating skills of the team. Each of these, the requirements and estimates, are independent sources of error, and then there are co-variances between them that stretch the errors.
> The actual cost is managed by attention to effective practices, efficient procedures, and look-ahead risk management. Effectiveness is a measure of impact, efficiency is a measure of effort to produce impact, and risk management is foreseeing problems in time to reduce their impact
> Value is managed by insisting on an outcome that meets the quality standards of the stakeholders, but does not overreach on attributes that aren't valuable, to wit: better is the enemy of good!
If you are into an earned value management mind-set, then you recognize the EVM concepts in the foregoing:
> the budgeted cost of the work scheduled, aka BCWS, aka the Budget or Planned Value [PV],
> the actual cost of the work performed, aka ACWP, aka Actual Cost [AC], and
> the budgeted cost of the work performed, aka BCWP, aka Earned value [EV].
There are several ratios and other formulas that you can make out of these four parameters to explain history and forecast the future, but the one that is missing from all the EVM systems is AC/PV. This is the infamous input view we spoke of before. It carries no value; it only measures adherence to a spending plan.
By the way, forecasts are the weakest link! Does history ever repeat? Milton Friedman, distinguished economist, opined: "if you are going to predict, then predict often!" Meaning: hey, things change.
It's a lucky project manager that actually gets to control the labor AC to only that which is needed to produce the EV. This is another of those conversations we need to have. How many times have people been placed on projects because they would otherwise be on overhead and vulnerable to release? How many times have people been retained on projects, the so-called marching army, because PM's have been told they can't get them back if they release them? Smart management anticipates labor redundancies, but also labor losses that might impact the EV: vacation, sick leave, other duties as assigned!
It's a lucky project manager that actually controls the overhead expenses of their project. In point of fact, many projects are encumbered with liquidating enterprise expenses disproportionately to use. It's part of the game, so smart cost managers anticipate the impact of changing overhead positions.
Now the challenge remains to get this all into 30 seconds so that it will sound good on the elevator!
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
Saturday, April 18, 2009
Quality thinker Fredrick Taylor is a lean machine
The ideas of F.W. Taylor
How many project managers are still laboring with the aftermath of Fredrick Winslow Taylor, more popularly known as F.W. Taylor? You might ask: Who was Taylor? F.W. Taylor was one of the first to study business systematically. He brought 'Taylorism" into the business culture in the years leading up to World War I. By 1915, his ideas were considered quite advanced, and they had significant impact well into the mid-20th century.
Taylor was a mechanical engineer who worked early-on in a metal products factory. Appalled at the seemingly disorganized and informal management of the time, and equally distressed by the costly throughput of poorly motivated workers laboring at inefficient processes , Taylor set about to invent "scientific management", a revolutionary movement that proposed the reduction of waste through the careful study of work.
Taylor came up with the original 'time-and-motion' studies, perhaps one of the first attacks on non-value work. Peter Drucker, a management guru par excellence who coined the term 'knowledge worker', has ranked Taylor, along with Darwin and Freud, as one of the seminal thinkers of modern times. ["Frederick Taylor, Early Century Management Consultant", The Wall Street Journal Bookshelf, June 13, 1997 pg. A1].
The essence of Taylorism is an antithesis to agile principles but nonetheless instructive. Counter to what we know today, Taylor believed that workers are not capable of understanding the underlying principles and science of their work; they need to be instructed step-by-step what to do and how to do it; and nothing is left to chance or decision. Rigid enforcement is required.
However, Taylor was close to the mark with his doctrine about value-adding work. According to Taylor, managers must accept that they have responsibilities to design efficient and effective process and procedures. Waste must be eliminated! Every action requires definition and a means to measure results.
Taylor was not well like by workers and it's not hard to see why. But Taylor's ideas and practices brought great efficiencies and profitability while providing customers with products of predictability of quality. Taylor most important legacy is perhaps his ideas of scientific management and the importance of process definition and process management as a means to control product and productivity.
I like what Steve McConnell says about quality and the software relationship. Building off Taylor's ideas of 'do it once right', though he does not mention Mr. Taylor, McConnell, author of the respected book "Code Complete" states the " general principle of software quality is .. that improving quality reduces development costs .... the best way to improve productivity is to reduce the time reworking..."
Kent Beck, writing in his book "Extreme Programming Explained - Second Edition" has a pretty strong idea about the legacy of Taylorism and its lingering effects on the knowledge industry. He says of Taylor that he brought a social structure we continue to unconsciously apply, and warns against the message that Taylorism implies: workers are interchangeable; workers only work hard enough to not be noticed; quality is an external responsibility
A project management tip
Fredrick Taylor was the first to study and quantify non-value work and put emphasis on eliminating wasteful and time consuming processes, procedures, and environmental impediments.
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
How many project managers are still laboring with the aftermath of Fredrick Winslow Taylor, more popularly known as F.W. Taylor? You might ask: Who was Taylor? F.W. Taylor was one of the first to study business systematically. He brought 'Taylorism" into the business culture in the years leading up to World War I. By 1915, his ideas were considered quite advanced, and they had significant impact well into the mid-20th century.
Taylor was a mechanical engineer who worked early-on in a metal products factory. Appalled at the seemingly disorganized and informal management of the time, and equally distressed by the costly throughput of poorly motivated workers laboring at inefficient processes , Taylor set about to invent "scientific management", a revolutionary movement that proposed the reduction of waste through the careful study of work.
Taylor came up with the original 'time-and-motion' studies, perhaps one of the first attacks on non-value work. Peter Drucker, a management guru par excellence who coined the term 'knowledge worker', has ranked Taylor, along with Darwin and Freud, as one of the seminal thinkers of modern times. ["Frederick Taylor, Early Century Management Consultant", The Wall Street Journal Bookshelf, June 13, 1997 pg. A1].
The essence of Taylorism is an antithesis to agile principles but nonetheless instructive. Counter to what we know today, Taylor believed that workers are not capable of understanding the underlying principles and science of their work; they need to be instructed step-by-step what to do and how to do it; and nothing is left to chance or decision. Rigid enforcement is required.
However, Taylor was close to the mark with his doctrine about value-adding work. According to Taylor, managers must accept that they have responsibilities to design efficient and effective process and procedures. Waste must be eliminated! Every action requires definition and a means to measure results.
Taylor was not well like by workers and it's not hard to see why. But Taylor's ideas and practices brought great efficiencies and profitability while providing customers with products of predictability of quality. Taylor most important legacy is perhaps his ideas of scientific management and the importance of process definition and process management as a means to control product and productivity.
I like what Steve McConnell says about quality and the software relationship. Building off Taylor's ideas of 'do it once right', though he does not mention Mr. Taylor, McConnell, author of the respected book "Code Complete" states the " general principle of software quality is .. that improving quality reduces development costs .... the best way to improve productivity is to reduce the time reworking..."
Kent Beck, writing in his book "Extreme Programming Explained - Second Edition" has a pretty strong idea about the legacy of Taylorism and its lingering effects on the knowledge industry. He says of Taylor that he brought a social structure we continue to unconsciously apply, and warns against the message that Taylorism implies: workers are interchangeable; workers only work hard enough to not be noticed; quality is an external responsibility
A project management tip
Fredrick Taylor was the first to study and quantify non-value work and put emphasis on eliminating wasteful and time consuming processes, procedures, and environmental impediments.
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
Sunday, March 29, 2009
A bit about Governance
Governance and agile methods may seem like an oxymoron. But not so. A means to govern is essential for orderly project functioning.
Without the elements of governance in place, at the moment of need there is only a vacuum which sucks in ad hoc solutions. Agile methodologists would not argue that governance is unnecessary or without value. Agile methodologists have gone so far as to build some governance practices into the process, although the not-Agile COBIT and ITIL programs are a bit over the top for agile projects.
As an example, at the team level, the daily time-boxed stand-up meeting is a governance mechanism. This meeting regulates the daily activity and points resources to problem areas where matters need resolution. And another: once a requirements set drawn from the backlog has been assigned to a team and to a sprint, that requirements set isn't allowed to change. This practice regulates the requirement drivers for the sprint and stabilizes the scope for the duration of the sprint.
When designing a governance program, two principles guide an effective implementation:
--Every process step is lean, meaning it is as efficient of resources as possible and it is as conservative of inventory as practical, inventory being the decisions to be made.
--Each step or activity adds some value to the outcome for both those that govern and those that are governed. Adding value means bringing the decision elements into focus and then deciding.
Consider a couple of points: first, governance can be the vehicle to lift the hand of top-down supervision by conveying rights to make the call to those close to the issues; second, good governance can be the reward system for disciplined behavior, for with discipline trust follows. Trust is an absolutely necessary condition for lean governance. Without a faith in the actions of others, many resources and steps will be added to check and inspect. And think about this: the best leaders are trusted by their followers, and the best teams are trusted by their leaders. Leadership inspires inquisitive minds to question the status quo, to search for a better way, and motivates action to turn opportunity into business and organizational value. A trusting organization is a 'safe' organization. Safety to go about doing really innovative and interesting tasks is a real benefit of trustfulness and discipline.The concept of a safe organization is an important concept in the so-called human powered methodologies called Crystal Methods. Alistair Cockburn has written much about safe organizations. See the link to his material in the link list on this blog site. In the agile space 'safety' translates into more generous boundaries, and this generosity often provides the stimulus to find challenging and competitive returns from opportunity.
Although governance can be the containment mechanics for downside risks, and is very often used just to constrain actions, even going so far as putting risk management somewhat on auto-pilot by means of work flow, having a governing framework in-place and operating does put a tool in the hands of the project manager. This tool, skillfully employed, can be the process to unleash actions to find new and better means to accomplish goals, provide some degree of risk management, and bring orderly and timely decisions to bear on priorities and alternatives.
I've encapsulated some ideas for a governance program in the slideshow below. Take a look
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
Without the elements of governance in place, at the moment of need there is only a vacuum which sucks in ad hoc solutions. Agile methodologists would not argue that governance is unnecessary or without value. Agile methodologists have gone so far as to build some governance practices into the process, although the not-Agile COBIT and ITIL programs are a bit over the top for agile projects.
As an example, at the team level, the daily time-boxed stand-up meeting is a governance mechanism. This meeting regulates the daily activity and points resources to problem areas where matters need resolution. And another: once a requirements set drawn from the backlog has been assigned to a team and to a sprint, that requirements set isn't allowed to change. This practice regulates the requirement drivers for the sprint and stabilizes the scope for the duration of the sprint.
When designing a governance program, two principles guide an effective implementation:
--Every process step is lean, meaning it is as efficient of resources as possible and it is as conservative of inventory as practical, inventory being the decisions to be made.
--Each step or activity adds some value to the outcome for both those that govern and those that are governed. Adding value means bringing the decision elements into focus and then deciding.
Consider a couple of points: first, governance can be the vehicle to lift the hand of top-down supervision by conveying rights to make the call to those close to the issues; second, good governance can be the reward system for disciplined behavior, for with discipline trust follows. Trust is an absolutely necessary condition for lean governance. Without a faith in the actions of others, many resources and steps will be added to check and inspect. And think about this: the best leaders are trusted by their followers, and the best teams are trusted by their leaders. Leadership inspires inquisitive minds to question the status quo, to search for a better way, and motivates action to turn opportunity into business and organizational value. A trusting organization is a 'safe' organization. Safety to go about doing really innovative and interesting tasks is a real benefit of trustfulness and discipline.The concept of a safe organization is an important concept in the so-called human powered methodologies called Crystal Methods. Alistair Cockburn has written much about safe organizations. See the link to his material in the link list on this blog site. In the agile space 'safety' translates into more generous boundaries, and this generosity often provides the stimulus to find challenging and competitive returns from opportunity.
Although governance can be the containment mechanics for downside risks, and is very often used just to constrain actions, even going so far as putting risk management somewhat on auto-pilot by means of work flow, having a governing framework in-place and operating does put a tool in the hands of the project manager. This tool, skillfully employed, can be the process to unleash actions to find new and better means to accomplish goals, provide some degree of risk management, and bring orderly and timely decisions to bear on priorities and alternatives.
I've encapsulated some ideas for a governance program in the slideshow below. Take a look
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
Sunday, March 22, 2009
The Wicked Problem
Thinking about the unreasonable problems
I've been thinking about some unreasonable problems. Some call them 'wicked'. The wicked problem is one where the issues interlock and become interdependent, perhaps even circular, as in Catch 22. There's no definitive statement of the problem. In fact, until the problem is resolved, you may not know what the problem is -- it takes hindsight to see --
Some get at this problem with the IBIS, the issue based information system. You can learn more by viewing my slide share below or at http://www.slideshare.net/jgoodpas/slideshows.
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
I've been thinking about some unreasonable problems. Some call them 'wicked'. The wicked problem is one where the issues interlock and become interdependent, perhaps even circular, as in Catch 22. There's no definitive statement of the problem. In fact, until the problem is resolved, you may not know what the problem is -- it takes hindsight to see --
Some get at this problem with the IBIS, the issue based information system. You can learn more by viewing my slide share below or at http://www.slideshare.net/jgoodpas/slideshows.
Are you networked on LinkedIn? If so, share this article with your network by clicking on the link.
Subscribe to:
Posts (Atom)