Tag Archives: IFPUG

GDPR, Forget Me and Human Connection


Last week, the first of many sweeping data privacy laws went into effect in Europe:  The General Data Protection Regulation or GDPR.  If you’ve ever traveled abroad or given your email address to a company that does business in Europe, you’re likely to be peripherally familiar with the legislation that has far-reaching implications globally and regulates what types of identifying data that companies can keep about you.  Without going in to detail, (a reasonable read on the subject is found at https://tinyurl.com/ycw8ec3z among others,)  people must explicitly renew and opt-in to continue to receive emails from corporations and services. Companies have spent hundreds and thousands of hours pulling together new policies about how they store and keep data about customers/subscribers.

Individuals under GDPR can also ask to “Be Forgotten” – to which corporations must remove ALL DATA EVER STORED ABOUT AN INDIVIDUAL (including previous names, email addresses, and other data.)  GDPR will change how the world at large views and saves personal data, and, that’s a good thing.

This falls on the heels of the latest issues with Facebook and Data Privacy Breaches where Mark Zuckerberg faced the US Congress, and later  revised their privacy practices (which, hopefully will cause other social media sites to also change.)

With the rise of identity theft and other wrongdoing based on negligent (and sometimes fraudulent) handling of personal data, these new requirements are good provisions. Corporations and their officers should be safeguarding the data they collect at our expense or face financial penalties for non-compliance. It’s going to be interesting to watch in the coming months as lawsuits start to amass… just speculating.

Sidenote: On a related topic, the regulations don’t help to allay the fear about what ‘Big Brother’ (government and corporations) do with the video and audio they collect on me (and everyone else) as we go about our everyday lives.

Am I the only one who finds it a little too intrusive when Google asks me “Have you recently been to Starbucks on xxx St ?” and then asks me to rate the experience to help out other visitors? (Note to self: turn off the Location setting on my cell phone.)

is keeping in touch out of vogue – can we reconnect?

Personally, I think it is disconcerting to see how disconnected we truly are today — despite the seemingly increased digital connectivity of social (and other) media.

Over the past 30 years as a consultant and speaker, I’ve met tens of thousands of people whose email addresses are scattered across various pieces of hardware (some long obsolete!)  I have so many fond memories of people I’ve met and places I’ve traveled; the stories and snippets of life we’ve shared (part of what makes conferences and consulting so worthwhile!)

I wonder about the people I’ve met and lost touch with (maybe even you!) and regardless of whether we shared a moment or a month, there was a connection.  I recall warm handshakes at the end of a presentation, smiles and shared conversations over coffee and dinners, solving problems with strangers (with corporate challenges,) and, of course, the goodbyes at the end of a class or a contract.  (Yes, I love my work!)

Every email address in my databases equals at least one human being with whom I’ve crossed paths with, and most likely lost touch. I wonder about your news and your kids and your experiences since we last met (or correspondence or chatted) – and, if you’re interested, I’d love to reconnect.

I’ll go first (to give an update):  I’m still actively presenting new ideas about measurement, agile, and leadership at conferences, still consulting and teaching workshops on function points (the square foot measure of software size) in new environments (especially agile!), as well as developing new courses to enrich corporate health through leadership, project management and metrics.  I’m passionate about cultural diversity (Hofstede and Trompenaars), the Heart of Agile (thank you Allistair Cockburn!), EI (emotional intelligence) and transforming our workplaces/workforces to be inclusive of people, technology, and fresh ideas.

I’m still the same energetic, optimistic, curious female engineer and consultant you met somewhere on some occasion, and as with every consultant, I’m always open to new / renewed client engagements where I can help you to streamline your operations (with great leadership and Project Management initiatives) and add measurement to demonstrate your department’s value! (I hope you’re okay with this shameless plug, I am taking on new clients at this time. Call or email me…)

Forget me….

On the opposite side, the Forget Me concept is interesting… considering the high percentage of flawed and incorrect data stored about all of us.  (Case in point – have you ever done a vanity search of your name in Google and found your name associated with the current address of exes and family members at locations where you’ve never lived?  Or done a public records search where identity results show records of invalid and incorrect data?  Data are gathered from disparate and diverse public and private databases – with little data validation.)  I wonder how corporations will actually be able to guarantee data removal when so much of the stored information is flawed.

Compounding the situation are purposely errant data (mis-entered by applicants who mistype their email address or falsify identifying information to avoid later spam, when registering on a site) – I’m curious how companies will be able to make sure that all data are removed on request. “Forget me” – what an interesting concept in a world that wants to be appropriately connected.

It’s probably time for a full EMAIL dataBASE refresh

I read a perspective piece in this past Sunday’s Tampa Bay Times newspaper “One man is updating his own privacy policy” by Konstantin Kakaes – it was an  interesting article that opened with

“Dear everybody who has sent me an email since  April 23, 2004, the day I got a Gmail account…”

The three column, half page piece addressed every type of email communication (from family to friends to generic spam to subscriptions to group lists,) 13 different groups in all, and outlined how he plans (tongue-in-cheek) to use the various pieces of data he’s retained on his various laptop incarnations and storage devices.  An interesting approach to cleaning out (or at least contacting) everyone in his email database.

P.s., watch this space for news about an exciting Powerful Presentations and Corporate Engagement workshop (I’m developing it now) – set to launch in the autumn of 2018.  Interested in knowing more (we’re targeting Sept in Napa Valley, CA!) – drop me a quick note!

Blogging is the ultimate “broken telephone” so, if you’ve read this far, do me a favor and shoot me a quick email (dekkers@qualityplustech.com) or drop a comment and let me know that you’re out there…  

p.s. Is anyone there?  Did this post resonate with you? Was it too long/just right/boring/fun?  LMK (Let me know…)

Advertisements

Function Points (Software Size) come of Age: Mature, Stable, and Relevant


It is with pride and honor to share with you news about the upcoming Sept 13-15, 2017 celebratory (and educational) conference: ISMA14 (International Software Measurement and Analysis) – and its happening in just 4 weeks in Cleveland, OH, USA!

It’s the 30th anniversary of the International Function Point Users Group (IFPUG) – a not-for-profit user group I’ve been a part of for over 25 years.

We’re also celebrating 2017 as the International Year of Software Measurement (#IYSM).  It’s a great year for YOU to get involved (or more involved) and gain the benefits of measurement for software and systems projects!

As the Director of Communications and Marketing for IFPUG, I am excited that IFPUG is now mature (age 30!) and at the same time venturing in new directions with non-functional sizing (SNAP.)  We have much to celebrate, AND we also have more work to do (to publicize how Function Points and SNAP points provide objective measures of software size!)

The time is now!

No longer does your organization need to “fumble around in the dark” to find standard, reliable and objective software sizing measures.  Certainly there is an abundance of available units of measure (story points, use case points, source lines of code, hybrid measures, etc.) — BUT, only Function Points are supported by  ISO/IEC world standards and provide consistent, objective and technologically independent assessments of software size based on “user” requirements.  (Soon, the Software Non-functional Assessment Process – SNAP points for non-functional size will also become an international standard.)

Isn’t it time that your company adopts function points as a universal standard for software size?  YOUR timing is perfect because in less than 5 weeks, International Software Measurement and Analysis (#ISMA14) will be in Cleveland and you will have the opportunity to learn from industry experts in an intimate (less than 200 people) setting. (p.s., I’m one of the main conference speakers so you’ll know at least 1 person there!)

FUNCTION POINT proof is “in the pUDDING” (so to speak)…

We have an English proverb “the proof is the pudding”

The modern version of “The proof is in the pudding.” Implies that there is a lot of evidence that I will not go through at this moment and you should take my word for it, or you could go through all of the evidence yourself. Source:  http://tinyurl.com/5uc7eq3 

I can espouse the benefits of function points, as can IFPUG insiders and supporters such as the world-respected author/guru Capers Jones (whose 17 published books use Function Points as a universal software sizing measure). But, when the mainstream media features articles on Function Points – it’s a call to action for senior executives and IT professionals to take note! Here’s a recent example: (click on the image to read the full story!)

Need help selling your boss on the benefits?

I’ve written up the top 10 reasons to attend ISMA14 with us- won’t you join me (and a ton of other measurement professionals) in Cleveland on Sep 13?

Carol Dekkers, CFPS (Fellow), AEC, PMP, P.Eng.
President, Quality Plus Technologies, Inc.
IFPUG Director of Communications and Marketing

 


As part of ongoing writings on software sizing and function point analysis, I recently posted the following article on the QSM blog.  Enjoy!

FP as mousetrap

Latest installment of Ask Carol: No matter What… in Project Management, Size Matters


Just wanted to share with you my latest installment on the QSM website blog – My Dear Carol advice column.  Enjoy!

Ask Carol - size matters

Here is the link to the rest of the article:  http://www.qsm.com/blog/2013/ask-carol-no-matter-what-project-management-size-matters

Fundamentals of Software Metrics in Two Minutes or Less


 

Fundamentals of SW Metrics in two minutes or lessTo read more click on the link:
http://www.qsm.com/blog/2013/fundamentals-software-metrics-two-minutes-or-less

Measurement and IT – Friends or Frenemies ?


I confess, I am a software metrics ‘geek’… but I am not a zealot!  I agree that we desperately need measures to make sense of the what we are doing in software development and to find pockets of excellence (and opportunities for improvement), but it has to be done properly!

Most (process) improvement models, whether they pertain to software and systems or manufacturing or children or people attest to the power of measurement including the CMMI(R) Capability Maturity Model Integration and the SPICE (Software Process Improvement Capability dEtermination) models.

But, we often approach what seems to be a simple concept – “Measure the Work Output and divide it by the Inputs” back asswards (pardon my French!)

Anyone who has been involved with software metrics or function points or CMMI/SPICE gone bad can point to the residual damage of overzealous management (and the supporting consultants) leaving a path of destruction in their wake.  I think that Measurement and IT are sometimes the perfect illustration of the term “Virtual Frenemies” I’ll lay claim to it!) when it comes to poorly designed software metrics programs.  (The concepts can be compatible – but you need proper planning and open-minded participants! Read on…)

Wikipedia (yes, I know it is not the best source!) defines “Frenemy (alternately spelled “frienemy“):

is a portmanteau of “friend” and “enemy” that can refer to either an enemy disguised as a friend or someone who’s both a friend and a rival.[1] The term is used to describe personal, geopolitical, and commercial relationships both among individuals and groups or institutions. The word has appeared in print as early as 1953.

Measurement as a concept can be good. Measure what you want to improve (and measure it objectively, consistently, and then ensure causality can be shown) and improve it.

IT as a concept can be good. Software runs our world and makes life easier. IT’s all good.

The problem comes in when someone (or some team) looks at these two “good” concepts and says, let’s put them together, makes the introduction, and then walks away.  “Be sure to show us good results and where we can do even better!” is the edict.

Left alone to their own devices, measurement can wreak havoc and run roughshod over IT – the wrong things are measured (“just measure it all with source lines of code or FP and see what comes out”), effort is spent measuring those wrong things (“just get the numbers together and we’ll figure out the rest later”), the data doesn’t correlate properly (“now how can we make sense of what we collected”), and misinformation abounds (“just plot what we have, it’s gotta tell us something we can use”).

In the process, the people working diligently (most of the time!) in IT get slammed by data they didn’t participate in collecting, and which often illustrates their “performance” in a detrimental way.  Involvement in the metrics program design, on the part of the teams who will be measured, is often sparse (or an afterthought), yet the teams are expected to embrace measurement and commit to changing whatever practices the resultant metrics analysis says they need to improve.

This happens often when a single measure or metric is used across the board to measure disparate types of work (using function points to measure work that has nothing to do with software development is like using construction square feet to measure landscaping projects!)

Is it any wonder that the software and systems industries are loathe to embrace and take part in the latest “enterprise wide” measurement initiative? Fool me once, shame on you… fool me twice, shame on me.

What is the solution to resolving this “Frenemies” situation between Measurement and IT?  Planning, communication, multiple metrics and a solid approach (don’t bring in the metrics consultants yet!) are the way.

Just because something is not simple to measure does not make it not worth measuring – and measuring properly.

For example, I know of a major initiative where a customer wants to measure the productivity of SAP-related projects to gain an understanding of how the cost per FP tracks on their projects compared to other (dissimilar) software projects and across the industry.

Their suppliers cite that Function Points (a measure of software functionality) does not work well for configurations (this is true), integration work (this is true), and that it can take a lot of effort to collect FP for large SAP implementations (can be true).  However, that does not mean that the productivity cannot be measured at all!  (If all you have is a hammer, everything might look like a nail.)

It will require planning and design effort to arrive at an appropriate measurement approach to equitably and consistently track productivity across these “unique” types of projects. While this is non-trivial, the insight and benefits to the business will far exceed the effort.  Resistance on the part of suppliers to be measured (especially in anticipation of an unfair assessment based on a single metric!) is justified, but a good measurement approach (that will fairly measure the types of effort into different buckets using different measures) is definitely attainable (and desired by the business.)

The results of knowing where and how the money is “invested” in these projects will lead to higher levels of understanding on both sides, and open up discussions about how to better deliver!  The business might even realize where they can improve to make such projects more productive!

Watch my next few posts for further details about how to set up a fair and balanced software measurement program.

What do you think?  Are measurement and IT doomed to be frenemies forever? What is your experience?

Have a good week!
Carol

Estimating Before Requirements with Function Points and Other Metrics… Webinar Replay


On June 7, 2012, I conducted an hour-long webinar on “Estimating Before Requirements with Function Points and Other Metrics” before a worldwide audience spanning a myriad of software development specialties/industries and across many countries.

In the event that you missed the live webinar or would like to listen/view the replay, it is available (at no charge) at http://www.qsm.com/Webinars/Estimating-before-Requirements

At the end of the webinar, I offered to send attendees several papers (also downloadable from this link) as well as a Scope Management primer.  If you are interested, please send an email to me at: dekkers (at) qualityplustech (dot) com.

Let me know what you think of the concepts and the webinar!

Carol

Trust and Verify are the (IT) Elephants in the room


As a party involved in some aspect of software development, why do you think projects are so hard?  Millions of dollars in research work to solve this question, with the result being new models, agile approaches and standards, all intended to streamline software development.

What do you think is the core reason for project success or failure?  Is it the people, process, requirements, budgets, schedule, personalities, the creative process or some combination?

Sure, IT (information technology) is a relatively new industry, plagued by technology advances at the speed of light, industries of customers and users who don’t know what they want, budgets are preset, schedules are imposed, scope is elusive, and, ultimately computer scientists and customers still speak their own language.  Some people argue that it boils down to communication (especially poor communication).  After all, isn’t communication the root cause of all wars, disputes, divorces, broken negotiations, and failed software projects?

I disagree.

I believe that TRUST and VERIFY are THE TWO most important factors in software development

These two elements are the IT elements in the room (so to speak!) I could be wrong, but it seems like the commonly cited factors (including communication) are simply symptoms of the elephants in the room – and no one is willing to talk about them.  Instead, we bring in new methodologies, new tools intended to bring customers and suppliers together, new approaches, and new standards – and all of these skirt the major issues: TRUST and VERIFY.

Why are these so critical?

Trust is the difference between negotiation and partnership – trust implies confidence,  a willingness to believe in (an)other, the assurance that your position and interests are protected, and the rationale that when life changes, the other party will understand and work with you. A partnership means that there is an agreement to trust in a second party and to give trust in return.  Trust is essential in software development.

BUT… many a contract and agreement have gone wrong with blind trust, and that is why VERIFY is as important as trust. Verify means to use due diligence to make sure that the trust is grounded in fact by using knowledge, history, and past performance as the basis.  Verify grounds trust, yet allows it to grow.

President Ronald Reagan coined the phrase “Trust, but Verify” – but I believe it is better stated as “Trust and Verify” because the two reinforce each other.  This also suggests the saying:  “Fool me Once, Shame on You… Fool me Twice, Shame on Me.”

Proof that Trust and Verify are the Elephants in the Room

Software development has a history of dysfunctional behavior built on ignoring that Trust and Verify are key issues. It is easier for both the business (customers) and the engineers (suppliers) to pretend that they trust each other than address the issues once and for all.  To admit to a lack of trust is tantamount to declaring war and accusing your “partners” of espionage.  It simply is not done in the polite company of corporate boardrooms.  And so we do the following:

  • Fixed price budgets are set before requirements are even known because the business wants to lower their risk (and mistrust);
  • Software development companies “pad” their estimates with generous margins to decrease their risk that the business doesn’t know what they want (classic mistrust);
  • Deadlines are imposed by the business based on gut-feel or contrived “drop dead” dates to keep the suppliers on track;
  • Project scope is mistakenly expressed in terms of dollars or effort (lagging metrics) instead of objective sizing (leading metrics);
  • Statements like “IT would be so much easier if we didn’t have to deal with users” are common;
  • Games like doubling the project estimate because the business will chop it in half become standard;
  • Unrealistic project budgets and schedules are agreed to to keep the business;
  • Neither side is happy about all the project meetings (lies, more promises, and disappointment).

Is IT doomed?

Trust is a critical component of any successful relationship involving humans (one might argue that it is also critical when pets are involved) – but so too is being confident in that trust (verify).  Several promising approaches address trust issues head on, and provide project metrics along the way to ensure that the trust remains.

One such approach is Kanban (the subject of this week’s Lean Software and Systems Development conference LSSC12 in Boston, MA).

Kanban for software and systems development was formalized by David Anderson and has been distilled into a collaborative set of practices that allow the business and software developers to be transparent about software development work – every step of the way.  Project work is prioritized and pulled in to be worked on only as the volume and pace (velocity) of the pipeline can accommodate.  Rather than having the business demand that more work be done faster, cheaper and better than is humanly possible (classic mistrust that the suppliers are not working efficiently), in Kanban, the business works collaboratively with the developers to manage (and gauge) what is possible to do and the pipeline delivers more than anticipated.  Trust and verify in action.

Another promising approach is Scope Management (supported by a body of knowledge and a European based certification) – a collaborative approach whereby software development effort is done based on “unit pricing”.  Rather than entertaining firm, fixed price, lose-lose (!!!) contracts where the business wants minimum price/maximum value and the supplier need to curtail changes to deliver within the fixed price (and not lose their shirts), unit pricing actually splits a project into known components can are priced similarly to how home construction can be priced by square foot and landscaping priced by the number of trees.

In Scope Management (see www.qualityplustech.com and www.fisma.fi for more details or send me an email and I’ll send you articles), the business retains the right to make changes and keep the reins on the budget and project progress and the supplier gets paid for the work that the business directs to be done.  Project metrics and progress metrics are a key component in the delivery process.  Again TRUST and VERIFY are key components to this approach.

What do you think? 

Please comment and share your opinion – are TRUST and VERIFY the IT elephants in the rooms at your company?

P.s., Don’t forget to sign up for the SPICE Users Group 2012 conference in 2 weeks in Palma de Mallorca, Spain. See www.spiceconference.com for details!  I’m doing a 1/2 day SCOPE MANAGEMENT tutorial on Tuesday May 29, 2012.

Function Points for Mere Mortals… Part 1: NOT Rocket Science


Does this sound familiar?  Your project completed under the “radar” (no major mishaps) and management wants more, more, more!  As part of the quest for faster, better, cheaper, someone in management decides that you ought to be reporting metrics and suggests that everything be built around “Function Points.”  A sponsor (the VP) appoints you the project manager for the Metrics Implementation (aka Function Points) and everything you thought you knew simply vanishes as soon as he walks out the door.

The Internet is Schizophrenic

If you are like most people, your first step is to ask your network (social media, peers, friends, etc.) what these “function points” are all about.  I have written about the simplicity and straight forward nature of Function Points for over 15 years (see downloadable articles below) and yet confusion still abounds in the IT industry!

As you begin to research the topic, thousands of internet links come up offering “Function” or “Points” or variations thereof. Once you find “Function+Points”, the filtered results create confusion as some sources elevate function points to a scientific treatise with the complexity to match.  This is simply not the case – Function Points are a unit of measure used to size the “functionality” of a piece of software that can be used to normalize measurement.  While certain consultants want to elevate Function Points to a mystical religion where only a handful of elders can do a count – this is not the case at all.  (These consultants seek to create an exclusive club where you have to hire them to count – this is utter hogwash!)

This is the point of this post:

Part 1: FUNCTION POINTS ARE not Rocket Science

As I mentioned, I and others publish (and continue to publish) articles and books about function points, yet software metrics is not yet a mainstream practice.  Confusion, disdain, and even downright misinformation abounds about this simple concept – creating a size of software that can be used as a basis (like square feet in a building) for estimating.  This is not Rocket Science!

In Project Management terminology, Function Points are the size of the overall work product for a project whose product is Software.  The WBS (work breakdown structure) for a software project includes all of the software deliverables, and function points is one way of sizing the functionality of the delivered software.  While there are additional things to be considered when doing a project estimate (such as quality, how the software will be built, critical path, resource constraints, risks, etc.) but a fundamental item is the scope.

Function points provides us with a measure of the scope of the software project.  Furthermore, the fundamentals of function points or FP (like the fundamentals of measuring square feet) have not changed in 15 years and counting methods are stable!  Certainly how we implement software has changed, but the functionality and scope have not – so why have FP not become maintream?

Capers Jones published a primer on function points (“Sizing up Software“)  in the December 1998 issue of Scientific American for which the abstract is below:

Modern society has become increasingly reliant on software–and thankfully so. Computer programs routinely execute operations that would be extraordinarily laborious for an unaided person– handling payrolls, recording bank transactions, shuffling airline reservations. They can also complete tasks that are beyond human abilities–for example, searching through massive amounts of information on the Internet.

Yet for all its importance, software is an intangible quantity that has been devilishly tricky to measure. Exactly how should people determine the size of software?

Want more basic information?  Here are four downloadable articles (PDF format) to further introduce you to function points:  (The content is still timely!)

Long and short oN function points? 

They are NOT rocket science and can be fundamental building blocks to a successful software estimating and metrics program.

Was this post useful?  Let me know!

Stay tuned for Part 2:  Getting started with Function Point basics.

Have a productive week!

Carol

Whose job is IT anyways?


The title was a purposeful play on the acronym “IT” (information technology) because there is often no one person who takes responsibility for failed IT projects. In addition, it is not as if there are not project failures everywhere.

Notwithstanding one of my least favorite (but often quoted) research studies, the Chaos Report cites that about one-third of projects are successful when it comes to IT.  What gets in the way of project success?  Lots of circumstances and lots of people!

When a software intensive project fails, there is no lack of finger-pointing and blame sharing – yet seldom do teams stand up and confess that the failure (over budget and behind schedule and failing to meet user needs) was due to a combination of over and under factors, along with fears:

  • overzealous and premature announcements (giving a date and budget before the project is defined);
  • over optimistic estimates of how quickly the software could be built;
  • under estimation of the subject complexity;
  • assumptions that the requirements were as solid as the customer professed;
  • under estimation of the overall scope;
  • under estimation of how much testing will be needed;
  • under estimation of how much time it takes to do a good job;
  • under estimation of the learning curve;
  • under estimation of the complexity of the solution;
  • under estimation of the impact of interruptions and delays;
  • over anticipation of user participation;
  • over optimism about the availability of needed resources;
  • over optimism about hardware and software working together;
  • over optimism about how many things one can do at once;
  • risk ignorance (“let’s not talk about risk on this project, it could kill it”);
  • over optimism of teamwork (double the team size doesn’t half the duration);
  • fear of speaking up;
  • fear of canceling a project (even if it is the right thing to do);
  • fear of pointing out errors;
  • fear of being seen as making mistakes;
  • fear of not being a “team player”;
  • fear of not knowing (what you think you should);
  • fear of not delivering fast enough;
  • fear of being labeled unproductive;
  • fear of being caught for being over or under optimistic.

Therefore, I ask you, on a software intensive IT project, whose job is it to point out when there are requirements errors, or something is taking longer than it should, or it is costing more than anticipated. In traditional waterfall development because there’s so much work put into the planning and documenting of requirements, pointing out errors are  either no one’s job or the team’s (collective) job which really relates to no one’s job.

Often it is easier (and results in less conflict) to not say anything when the scope or schedule or budge go awry on a software project. Yet it is this very behavior that results in so much rework and so many failed projects.

Agile and Kanban projects are different

Several of the advantages to using Kanban and Lean and Agile approaches to software and systems development is that the methods address the very items outlined above.  Building better software iteratively becomes every developer’s job rather than no one’s:

  • Fear of pointing out errors is removed because the time that goes into a scrum is days and weeks not months (so participants don’t get defensive about change);
  • Over and under optimism remains but is concentrated on smaller and less costly components of work (i.e. days instead of months or years);
  • Risk is not avoided or ignored because we are no longer dealing with elongated and protracted development cycles (spanning seasons);
  • Assumptions come out with better and more frequent discussions;
  • Over optimism about how many things one can do at once is removed because Kanban limits the amount of work-in-progress;
  • Under estimation of the impact of interruptions and delays is minimized because such factors are addressed in Kanban;
  • Over anticipation of user participation is managed through direct user involvement.

What do you think?  Join us at the Lean Software and Systems Consortium conference LSSC11 from May 3-6, 2011 as participants and speakers address the best ways of advancing software and systems methods including Lean, Kanban, Agile and other exciting new ways to deliver high quality software more efficiently and effectively.

These newer approaches make it easier for everyone in IT to make it their job to build better software.

Wishing you a productive week!

Carol
@caroldekkers (twitter)

Share